fred2k3
asked on
Setting up a SIP trunk on a snom 300
Hello,
I'm trying to set up a SIP line on a snom 300 phone but have hit a wall.
"Identity1" on the phone has been set up and is working fine as an extension on our PBX (Asterisk). "Identity 2" has been set up to communicate directly with Gamma (the SIP line provider) rather than going through the PBX.
If I go to System Information on the phone I can see that Identity 2 has been given the "ok" suggesting that it has registered ok, but if I try and ring the number it doesn't connect (I either get a message saying the number is not available, or just silence after I've dialled, depending what sort of phone I dial from).
I'm sure I'm missing something very simple here.. anyone have any ideas?
Thanks
I'm trying to set up a SIP line on a snom 300 phone but have hit a wall.
"Identity1" on the phone has been set up and is working fine as an extension on our PBX (Asterisk). "Identity 2" has been set up to communicate directly with Gamma (the SIP line provider) rather than going through the PBX.
If I go to System Information on the phone I can see that Identity 2 has been given the "ok" suggesting that it has registered ok, but if I try and ring the number it doesn't connect (I either get a message saying the number is not available, or just silence after I've dialled, depending what sort of phone I dial from).
I'm sure I'm missing something very simple here.. anyone have any ideas?
Thanks
ASKER
SIP trace from the phone attached as Code.
Caller and Destination numbers have been replaced.
Caller and Destination numbers have been replaced.
Received from udp:88.215.60.40:5060 at 6/7/2010 10:04:59:480 (1077 bytes):
INVITE sip:[***Destination Number***]@109.204.46.178:11752 SIP/2.0
Record-Route: <sip:88.215.60.40;ftag=2e01f46d6324b043;lr=on>
Via: SIP/2.0/UDP 88.215.60.40;branch=z9hG4bK-d8754z-d23d62792d304233-1---d8754z-ser
Via: SIP/2.0/UDP 88.215.60.41:5061;branch=z9hG4bK-d8754z-d23d62792d304233-1---d8754z-;rport=5061
Max-Forwards: 16
Contact: <sip:[***Caller Number***]@88.215.60.41:5061>
To: <sip:[***Destination Number***]@88.215.60.40>
From: <sip:[***Caller Number***]@gw3.theiptele.com:5061>;tag=2e01f46d6324b043
Call-ID: NTlkNzc5ODZjMTE3NmRkNTY5YzZhMTMxN2JhZTBiYzM.
CSeq: 102 INVITE
Content-Type: application/sdp
P-Asserted-Identity: <sip:[***Caller Number***]@gw3.theiptele.com>
Remote-Party-ID: <sip:[***Caller Number***]@gw3.theiptele.com>;party=calling;id-type=subscriber;screen=yes;privacy=off
Content-Length: 287
Reg-Proxy: 0001542306325
v=0
o=GASb2bua 6566 1900 IN IP4 88.215.60.41
s=SIP Call
c=IN IP4 88.215.60.33
t=0 0
m=audio 20950 RTP/AVP 18 8 0 101
c=IN IP4 88.215.60.33
a=fmtp:18 annexb=yes
a=fmtp:101 0-16
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
________________________________________
Sent to udp:88.215.60.40:5060 at 6/7/2010 10:04:59:487 (589 bytes):
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 88.215.60.40;branch=z9hG4bK-d8754z-d23d62792d304233-1---d8754z-ser
Via: SIP/2.0/UDP 88.215.60.41:5061;branch=z9hG4bK-d8754z-d23d62792d304233-1---d8754z-;rport=5061
From: <sip:[***Caller Number***]@gw3.theiptele.com:5061>;tag=2e01f46d6324b043
To: <sip:[***Destination Number***]@88.215.60.40>
Call-ID: NTlkNzc5ODZjMTE3NmRkNTY5YzZhMTMxN2JhZTBiYzM.
CSeq: 102 INVITE
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Content-Length: 0
________________________________________
Received from udp:88.215.60.40:5060 at 6/7/2010 10:04:59:559 (475 bytes):
ACK sip:[***Destination Number***]@109.204.46.178:11752 SIP/2.0
Max-Forwards: 10
Via: SIP/2.0/UDP 88.215.60.40;branch=z9hG4bK-d8754z-d23d62792d304233-1---d8754z-ser
Via: SIP/2.0/UDP 88.215.60.41:5061;branch=z9hG4bK-d8754z-d23d62792d304233-1---d8754z-;rport=5061
To: <sip:[***Destination Number***]@88.215.60.40>
From: <sip:[***Caller Number***]@gw3.theiptele.com:5061>;tag=2e01f46d6324b043
Call-ID: NTlkNzc5ODZjMTE3NmRkNTY5YzZhMTMxN2JhZTBiYzM.
CSeq: 102 ACK
Content-Length: 0
Reg-Proxy: 0001542306325
On the SIP tab of Identity 2, try turning on the option "Support broken Registrar". Then force the phone to re-register with Gamma and try again.
By way of explanation: When your phone registers with Gamma, it sends an extra parameter line=<random_id_tag> at the end of the Contact header. The Snom phone expects to get the same value sent back to it on the INVITE. However, many IP phone servers fail to send the line=<tag> value which causes the Snom phone to reject the Invite. By setting the "broken Registrar" option on, you are telling the Snom phone to ignore the missing line tag value and just accept the call anyway.
By way of explanation: When your phone registers with Gamma, it sends an extra parameter line=<random_id_tag> at the end of the Contact header. The Snom phone expects to get the same value sent back to it on the INVITE. However, many IP phone servers fail to send the line=<tag> value which causes the Snom phone to reject the Invite. By setting the "broken Registrar" option on, you are telling the Snom phone to ignore the missing line tag value and just accept the call anyway.
ASKER
Thanks for your suggestion feptias, unfortunately it didn't solve the problem in this instance.
I've asked Gamma to run a trace when we dial the number and they've found SIP response "404 - Not Found"
This has to be the key to this problem but I don't know what to do about it. This is what I've found out about the 404 error:
404 Not Found - This server has definitive information that the user does not exist at the domain specified in the request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request.
But on the snom phone itself, I can see that when I dial the number it's showing up in the SIP trace (also with SIP/2.0 404 Not Found" message). So if the data is getting to the end point, how can the URI be incorrect?!
I've asked Gamma to run a trace when we dial the number and they've found SIP response "404 - Not Found"
This has to be the key to this problem but I don't know what to do about it. This is what I've found out about the 404 error:
404 Not Found - This server has definitive information that the user does not exist at the domain specified in the request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request.
But on the snom phone itself, I can see that when I dial the number it's showing up in the SIP trace (also with SIP/2.0 404 Not Found" message). So if the data is getting to the end point, how can the URI be incorrect?!
I had already seen the "404 not found" in the sip trace that you posted earlier. That was why I thought it must be the broken registrar problem. I know that this will cause a 404 response. Also, the INVITE sent to your Snom phone did not contain a "line=<tag_id>" value. Everything was pointing to this being the problem. Are you sure that the phone has re-registered with Gamma since you changed the broken registrar setting?
If it is not the broken registrar setting, then the most likely explanation would be a mismatch on the number it is registering with and the number that is being dialled to call the phone.
If it is not the broken registrar setting, then the most likely explanation would be a mismatch on the number it is registering with and the number that is being dialled to call the phone.
Please can you confirm the following:
On the login tab of the Identity, are the "Account" and "Authentication Username" both set to a number that is the same as the destination number you are dialling (assuming that the number you are dialling is the same as the destination number you masked out in the SIP trace). If not, please explain what these settings are and how they differ from the destination number - scramble the actual numbers a bit if you want, but please try to be as precise as possible in describing how they differ.
On the QoS/Security tab of the Advanced options form, try setting the parameter "Filter Packets from Registrar" to off. Reboot the phone and try again.
On the login tab of the Identity, are the "Account" and "Authentication Username" both set to a number that is the same as the destination number you are dialling (assuming that the number you are dialling is the same as the destination number you masked out in the SIP trace). If not, please explain what these settings are and how they differ from the destination number - scramble the actual numbers a bit if you want, but please try to be as precise as possible in describing how they differ.
On the QoS/Security tab of the Advanced options form, try setting the parameter "Filter Packets from Registrar" to off. Reboot the phone and try again.
ASKER
I hit the re-register button and then restarted the phone after enabling the "Support broken registrar" option.
Tried the "Filter Packets from Registrar" option too, also to no avail (after re-registering & rebooting).
The Account and Authentication Username are both the Gamma "account number" rather than the number dialled (which seems to be correct - the identity displays "Unauthorized" with anything else),
I have just checked the SIP trace on the phone after restarting it and noticed a number of Send & Receive transmissions to Gamma. At first there is a send "REGISTER", followed by a receive "SIP/2.0 100 Trying" and then a receive "SIP/2.0 401 Unauthorized". A second later there is another send "REGISTER" but this time it's followed by a receive "SIP/2.0 100 Trying" then "SIP/2.0 200 OK"
I don't know if that 401 - Unauthorized is important or not (since it received a "200 ok" on the 2nd attempt, and the phone does appear to be registered). I've attached the 401 reference in any case:
88.215.60.40 = gw3.theiptele.com (i.e. Gamma)
4412******56 = partially masked phone number (we dial starting 012... rather than 4412...)
00015*******5 = partially masked Gamma extension ID
Tried the "Filter Packets from Registrar" option too, also to no avail (after re-registering & rebooting).
The Account and Authentication Username are both the Gamma "account number" rather than the number dialled (which seems to be correct - the identity displays "Unauthorized" with anything else),
I have just checked the SIP trace on the phone after restarting it and noticed a number of Send & Receive transmissions to Gamma. At first there is a send "REGISTER", followed by a receive "SIP/2.0 100 Trying" and then a receive "SIP/2.0 401 Unauthorized". A second later there is another send "REGISTER" but this time it's followed by a receive "SIP/2.0 100 Trying" then "SIP/2.0 200 OK"
I don't know if that 401 - Unauthorized is important or not (since it received a "200 ok" on the 2nd attempt, and the phone does appear to be registered). I've attached the 401 reference in any case:
88.215.60.40 = gw3.theiptele.com (i.e. Gamma)
4412******56 = partially masked phone number (we dial starting 012... rather than 4412...)
00015*******5 = partially masked Gamma extension ID
Received from udp:88.215.60.40:5060 at 7/7/2010 13:32:16:999 (687 bytes):
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.76.201:2090;branch=z9hG4bK-xs11id9lke01;rport=11888;received=109.204.46.178
From: "4412******56" <sip:00015*******5@gw3.theiptele.com>;tag=syzbrc55q6
To: "4412******56" <sip: 00015*******5@gw3.theiptele.com>;tag=f402f6743e9d1abe62785b2653c63db2.7957
Call-ID: 3c26701c3a07-o34qs8j7kfw1
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="gw3.theiptele.com", nonce="4c3473d64d8c9a0af12844c7d8518724f6165215"
Server: SER (i386/linux)
Content-Length: 0
Warning: 392 88.215.60.40:5060 "Noisy feedback tells: pid=5299 req_src_ip=109.204.46.178 req_src_port=11888 in_uri=sip:gw3.theiptele.com out_uri=sip:gw3.theiptele.com via_cnt==1"ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Ah, Halleluiah! Yes that seems to have done the trick... I could have sworn I tried that twice already (maybe that was before the "Support broken registrar" & "Filter Packets from Registrar" settings - will have to experiment).
Anyway, many thanks for your help and perseverance.
Anyway, many thanks for your help and perseverance.
Check that it works even after rebooting the phone - and after waiting for an hour. Registrations can be remembered for up to 1 hour and so you need to make sure the current setup works beyond that period of time.
Once you have it working, I recommend that you test if you can re-enable "Filter packets from Registrar". It is better, if possible, to filter out SIP packets that do not come from the Registrar.
Once you have it working, I recommend that you test if you can re-enable "Filter packets from Registrar". It is better, if possible, to filter out SIP packets that do not come from the Registrar.
Can you post a copy of the SIP Trace output just after trying to make a call.