jlumby

I have the same version of PBXnSIP running on 2 different independant servers. If I setup the tapi client on my laptop to connect to one of them, everything works fine, however if I set it up to connect to the other one, then when my extension rings, I pick it up, and the call immediately terminates. The PBX logs the following [5] 2008/07/09 17:02:20: Not setting dialog state of non-existing call port (call-id=b9578b47@pbx#4049) [5] 2008/07/09 17:02:22: BYE Response: Terminate 86837862@pbx Can you tell me what I might have configured wrong/different on the second system.

Just wondering if there is a way to get the PAC to remember it's position on the desktop, as well as size between closing/opening the program

I received the files to upload to the CS410 to enable it to be a DHCP Server (saves tons of $ in hardware for small installs since most small business grade routers will not send options 66 and 150) I edited/uploaded the files, set the server to run automatically, and changed the permissions all as per the readme file, however the CS410 is not responding as a DHCP server to requests on the LAN port, and I do not know what diagnostic commands to use to see what might be going wrong. Any suggestions would be appreciated.

I was wondering if there was a folder I could put files into so that they would be accessible by all phones via HTTP. I am trying to make images available to phones. Currently I need to install IIS on an alternate port to do so. I need to leave PBXnSIP running on 80 for the few snom phones on my network since they will not get their info via https. I have tried putting my files in the html folder, however if I am not already logged in, it redirects to the login screen, and does not give the graphic.

I just downloaded 1.9.2.12 and it is less stable than 1.9.1 that I was running before. Now not only do extensions hang up, I have to forcibly end task to close, and re-open it.

I am aware of the registry changes that should be made in order to set DSCP on outgoing packets, however microsoft also installs a QOS packet scheduler by default, and binds it to the NIC. Is this good, bad, or indiferent from the PBXnSIP point of view? Just wondering if I should leave it, or not.

It would need to be automatic since this is an afterhours emergency notification mailbox

I have noticed that if you promote an extension to a Domain Administrator, they loose the extension specific tab that allows them to listen to their voicemails across the web page, as well as other extension specific features. Am I just missing something?

Does anyone know of a way to do a cell phone notification to multiple different cell phones? I have a customer that would like to be able to have multiple techs notified if a message is left on their after hours emercency mailbox. I have tried to do a huntgroup of cell phones, however that did not work.

I have noticed that when creating new extensions in bulk if you select a dial plan, when you go into the extension after creation, the extension is still set to default. Am I doing something wrong? I have tried multiple different versions of software, and they all seem to have the issue. If I change it in the specific extension after creation, then it sticks.

I have been demoing the Beta version of the PAC, and have noticed some issues. The first is that the download link says it should be version 1.9.2.0 however when I install it I get 1.9.1.0 Beyond that I have found that it often gets out of sync with what the extensions are actually doing. It will show that extensions, as well as trunks are in use when they are not, and transfering to an extension will often light up the wrong extension. The longer it is running, the worse it gets. Closing, and reopening the application always clears up the issues. I have also found that when registering the PAC to certain extensions it fails with a long error message (see attached file for error message). I cannot figure out why registering to other extensions is not a problem

Would it be possible to add a company name field to the address book?

After meeting with a potential customer, and discussing how to assign a limited number of buttons they have on their phones, I came to the realization that you would not need to use nearly as many buttons if the PBX was able to prompt you for additional input. The problem is most models of phones initiate the call as soon as you press the button, and do not wait for additional input. Since I do not seem to know of a phone vendor that has the option not to do this, it seems like it could be easily worked around on the softswitch side. If a radio button was added next to each of the feature codes, and the radio button could be labeled "extended prompting" on or off. If the radio button was turned on, then when the star code was dialed, then the PBX would respond by asking for the extension number. For example, if extended prompting was turned on for intercom, and you pressed a speed dial button that was set to dial *90, the system would respond by asking for the extension number, and as soon as you enter the extension number, it would complete the intercom.

It would be fine for a temp fix, however I would really like to see the conferernce bridge number show up in the extension field. The call accounting software I am using gets confused if a value is missing, and then everything shifts forward, and the date gets recorded as the extension. I would also like to see the specific bridge number so if we had a large install with more than one bridge, you would know what conference they went into. I also noticed that other values such as the direction of the call were missing from the output string. Not a big deal to a human looking at the string, however the call accounting software will not take well to it.

I am sure they took it out. I even found documentation confirming it on their web site. I have been using the * code for now, I would just like something a little better since the customers love the look, sound quality, and stability of the phones.

I have found a problem with transfering calls in the newer style cisco phones (verified on 7941 7961 7970 and 7971). The problem starts out as they do not have a blind transfer button like the 7960s do. So as a result to transfer to an extension, you press transfer, talk to the person, and if they want to accept the call, then you press transfer again, and the call goes through to them. The problem arrises if you try to make it work like a blind transfer. The following is what happens: Situation 1: If you have the call, press transfer, dial the extension, and then once the extension starts to ring press the transfer button again the call will be transfered to the extension. However the following problems arrise. If the person is not at the extension, it will ring forever, and not go to voicemail, the caller that is being transfered does not hear a rinback tone, and the call does not fork to a cell phone. Situation 2: If you want to transfer the call directly to voicemail, if you press transfer dial 8 plus the extension number, and then transfer as soon as the greeting beginds to play, it hangs up in the person being transferred. Let me know if I need to gather log files, or packet captures.

Just looking for an easy way to transition a small office that is used to a system where they can just tell the other person that the call is holding on line 2. The more we can mimic what people are used to, plus add new features of VoIP, the easier the systems are to sell.

I am trying to setup call accounting, and I am having a problem seeing the extension of the conference bridge if a call comes in, goes through an auto attendant, and then into the conference bridge. My CDR format is: $m $e $b $B $d $o $c $f $t The output I am getting is: voip.office.twincitytelephone.com 20080604 163107 42 <sip:4193922384@voip.office.twincitytelephone.com> conference I would expect to see the conference bridge extension number right between the domain, and the date. Any Suggestions?

Here is the situation Call comes in on CO line 701 and is answered by a SNOM phone. The call is put on hold. I want to do whatever is necessary to take the call on a NON snom phone. (without parking or transfering) This can currently be achieved if the second phone IS a snom, and you press the button corrisponding with the co line.

On snom phones if you have a button monitoring the CO lines, you can put a call on hold, and the CO line will blink on the other snomes. If you go to another snom phone, you can pick up the call by pressing the CO line that the call is holding on. My question is if you want to pickup the call holding on the CO line from a non snom phone, or one that does not have buttons associated with the CO line, can you do it? I have my CO lines numbered 701 and up. I cannot dial *87701 to pickup the call from another phone.

The phone always expects GMT, and it adjusts it based upon the timezone specified in the xml config file that the phone downloads from the pbx at bootup.

I have discovered through Cisco's documentation that the 79x1 phones first tries to set the date and time off of the SIP registration responce, and then they fine tune it off of the NTP server that is listed in their config file. I am having an issue that since the date, and time is not sent in the SIP messaging to the phone, that the clock never gets close enough to use the NTP server. Is there a way to make PBXnSIP send the date, or does anyone know of a workaround? Below is a copy of how a Cisco sends the date from their callmanager. No. Time Source Destination Protocol Info 229 70.598879 192.168.5.199 192.168.5.138 SIP Status: 200 OK (1 bindings) Frame 229 (650 bytes on wire, 650 bytes captured) Ethernet II, Src: CompaqHp_af:1a:24 (00:0b:cd:af:1a:24), Dst: Cisco_84:61:80 (00:1b:d5:84:61:80) Internet Protocol, Src: 192.168.5.199 (192.168.5.199), Dst: 192.168.5.138 (192.168.5.138) Transmission Control Protocol, Src Port: sip (5060), Dst Port: 50294 (50294), Seq: 639, Ack: 1716, Len: 596 Source port: sip (5060) Destination port: 50294 (50294) Sequence number: 639 (relative sequence number) [Next sequence number: 1235 (relative sequence number)] Acknowledgement number: 1716 (relative ack number) Header length: 20 bytes Flags: 0x18 (PSH, ACK) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...1 .... = Acknowledgment: Set .... 1... = Push: Set .... .0.. = Reset: Not set .... ..0. = Syn: Not set .... ...0 = Fin: Not set Window size: 9684 Checksum: 0x4de6 [correct] [sEQ/ACK analysis] [This is an ACK to the segment in frame: 228] [The RTT to ACK the segment was: 0.495541000 seconds] Session Initiation Protocol Status-Line: SIP/2.0 200 OK Status-Code: 200 [Resent Packet: False] Message Header Via: SIP/2.0/TCP 192.168.5.138:50294;branch=z9hG4bK47aff438 From: <sip:1009@192.168.5.199>;tag=001bd584618000022a3003a8-470cfe78 SIP from address: sip:1009@192.168.5.199 SIP tag: 001bd584618000022a3003a8-470cfe78 To: <sip:1009@192.168.5.199>;tag=436104038 SIP to address: sip:1009@192.168.5.199 SIP tag: 436104038 Date: Tue, 20 May 2008 22:04:19 GMT Call-ID: 001bd584-61800003-92fe3868-3a9464b8@192.168.5.138 CSeq: 101 REGISTER Sequence Number: 101 Method: REGISTER Expires: 120 Contact: <sip:00857d4c-4c71-4a69-8590-2714e50f8c3c@192.168.5.138:50294;transport=tcp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-001bd5846180>";+u.sip!model.ccm.cisco.com="30018";x-cisco-newreg Contact Binding: <sip:00857d4c-4c71-4a69-8590-2714e50f8c3c@192.168.5.138:50294;transport=tcp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-001bd5846180>";+u.sip!model.ccm.cisco.com="30018";x-cisco-newreg Supported: X-cisco-srtp-fallback,X-cisco-sis-2.0.0 Content-Length: 0

The problem is they might not come back for hours, or might not make a call for hours/days, and by the time the callback happens, the person forgets that they ever requested the camp in the first place.

No one has answered my other post about not being able to autoprovision the phone's buttons since doing so knocks it off of my voice vlan, so I am forced to manually provision the phone.

I am running 2.1.8 The Cisco is POS3-8-9-00 Here is the packet No. Time Source Destination Protocol Info 15 1.467275 75.146.173.69 192.168.3.134 SIP/SDP Request: INVITE sip:211@192.168.3.134:5060;transport=udp, with session description Frame 15 (979 bytes on wire, 979 bytes captured) Arrival Time: May 2, 2008 16:11:18.720178000 [Time delta from previous captured frame: 0.008953000 seconds] [Time delta from previous displayed frame: 0.008953000 seconds] [Time since reference or first frame: 1.467275000 seconds] Frame Number: 15 Frame Length: 979 bytes Capture Length: 979 bytes [Frame is marked: False] [Protocols in frame: eth:ip:udp:sip:sdp] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: SoyoComp_a3:b7:df (00:50:2c:a3:b7:df), Dst: Cisco_3d:de:64 (00:15:c6:3d:de:64) Destination: Cisco_3d:de:64 (00:15:c6:3d:de:64) Address: Cisco_3d:de:64 (00:15:c6:3d:de:64) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: SoyoComp_a3:b7:df (00:50:2c:a3:b7:df) Address: SoyoComp_a3:b7:df (00:50:2c:a3:b7:df) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 75.146.173.69 (75.146.173.69), Dst: 192.168.3.134 (192.168.3.134) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 965 Identification: 0x108d (4237) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 128 Protocol: UDP (0x11) Header checksum: 0x6995 [correct] [Good: True] [bad : False] Source: 75.146.173.69 (75.146.173.69) Destination: 192.168.3.134 (192.168.3.134) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Source port: sip (5060) Destination port: sip (5060) Length: 945 Checksum: 0x1b58 [correct] [Good Checksum: True] [bad Checksum: False] Session Initiation Protocol Request-Line: INVITE sip:211@192.168.3.134:5060;transport=udp SIP/2.0 Method: INVITE [Resent Packet: False] Message Header Via: SIP/2.0/UDP 75.146.173.69:5060;branch=z9hG4bK-f4f5c3c6421d1bc173750b474eb7a674;rport Transport: UDP Sent-by Address: 75.146.173.69 Sent-by port: 5060 Branch: z9hG4bK-f4f5c3c6421d1bc173750b474eb7a674 RPort: rport From: "210" <sip:210@voip.office.twincitytelephone.com>;tag=14907 SIP Display info: "210" SIP from address: sip:210@voip.office.twincitytelephone.com SIP tag: 14907 To: <sip:211@voip.office.twincitytelephone.com;user=phone> SIP to address: sip:211@voip.office.twincitytelephone.com Call-ID: 4258dfdb@pbx CSeq: 18541 INVITE Sequence Number: 18541 Method: INVITE Max-Forwards: 70 Contact: <sip:211@75.146.173.69:5060;transport=udp> Contact Binding: <sip:211@75.146.173.69:5060;transport=udp> URI: <sip:211@75.146.173.69:5060;transport=udp> SIP contact address: sip:211@75.146.173.69:5060 Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: PBXnSIP-PBX/2.1.8.2463 Alert-Info: <http://127.0.0.1/Bellcore-dr2> Content-Type: application/sdp Content-Length: 265 Message Body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): - 48598 48598 IN IP4 75.146.173.69 Owner Username: - Session ID: 48598 Session Version: 48598 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 75.146.173.69 Session Name (s): - Connection Information ©: IN IP4 75.146.173.69 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 75.146.173.69 Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Media Description, name and address (m): audio 50752 RTP/AVP 0 8 18 101 Media Type: audio Media Port: 50752 Media Proto: RTP/AVP Media Format: ITU-T G.711 PCMU Media Format: ITU-T G.711 PCMA Media Format: ITU-T G.729 Media Format: 101 Media Attribute (a): rtpmap:0 pcmu/8000 Media Attribute Fieldname: rtpmap Media Format: 0 MIME Type: pcmu Media Attribute (a): rtpmap:8 pcma/8000 Media Attribute Fieldname: rtpmap Media Format: 8 MIME Type: pcma Media Attribute (a): rtpmap:18 g729/8000 Media Attribute Fieldname: rtpmap Media Format: 18 MIME Type: g729 Media Attribute (a): fmtp:18 annexb=no Media Attribute Fieldname: fmtp Media Format: 18 [g729] Media format specific parameters: annexb=no Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute Fieldname: rtpmap Media Format: 101 MIME Type: telephone-event Media Attribute (a): fmtp:101 0-16 Media Attribute Fieldname: fmtp Media Format: 101 [telephone-event] Media format specific parameters: 0-16 Media Attribute (a): sendrecv