Sara Posted September 18, 2007 Report Share Posted September 18, 2007 SNOM 370 can connect ok with 5061;transport=tls but cannot get any calls passed from pbxnsip to extensions. The calls come in ok to pbxnsip but as soon as the user enters the extension pbxnsip cant pass the call, all they hear is white noise. I have been shooting off emails to every man and their dog trying to work this out but Im stumped, can someone please help me set up incoming TLS connections that actually work, I have attached a Snom 370 pcap which clearly shows TLS is working and the other pbxnsip file shows that it clearly doesnt do anything, it goes straight to voice mail. When I use pbxnsip with VPN then call just does not go anywhere. The files are .txt so you will need to change them to .pcap? Regards, Sara Donald Australia. pbxnsipwithoutvpn.txt Snom370TLS.txt Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted September 18, 2007 Report Share Posted September 18, 2007 What did you use for outbound proxy? Something like "sip:192.168.1.2:5061;transport=tls"? The transport=tls is important because otherwide the phone will use UDP. Do you have a SIP trace from the phone's web interface? PCAP are useless, due to the nature of TLS we will not be able to see too much... Quote Link to comment Share on other sites More sharing options...
Sara Posted September 18, 2007 Author Report Share Posted September 18, 2007 mmmmm, in outbound proxy on the phone I used 192.168.1.3:5061;transport=tls - this works fine for outgoing calls. I did notice that when using the vpn calls come in as udp and there is no RTP at all but it still connects to the PBX ok, it is only when I enter the extension number that I get nothing but voice mail or white noise. Here is the sip trace within SNOM 370. Sent to udp:192.168.1.3:5061 at 19/9/2007 07:46:25:866 (536 bytes): REGISTER sip:192.168.1.3 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.6:1025;branch=z9hG4bK-tfcna53qu529;rport From: "PBX Gateway [Out]" <sip:200@192.168.1.3>;tag=hkswm4jdf0 To: "PBX Gateway [Out]" <sip:200@192.168.1.3> Call-ID: 46f04e1c2aa3-uxatyp7ztyq1 CSeq: 37 REGISTER Max-Forwards: 70 Contact: <sip:200@192.168.1.6:1025;line=lhieczq4>;flow-id=1;q=1.0;+sip.instance="<urn:uuid:0b939f13-3359-43f4-b5a2-104dbfd43e44>" User-Agent: snom370/ Supported: gruu Allow-Events: dialog X-Real-IP: 192.168.1.6 Expires: 0 Content-Length: 0 [Repetitions deleted] Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted September 19, 2007 Report Share Posted September 19, 2007 Try "sip:192.168.1.3:5061;transport=tls" as outbound proxy. If you see "Sent to udp:192.168.1.3:5061" then the phone uses the wrong transport layer. I guess you should also reboot the phone after that. And try to use version 7.1.19 or higher on the snom 370, previous versions might be buggy. See http://wiki.snom.com/Snom370/Firmware. Quote Link to comment Share on other sites More sharing options...
Sara Posted September 20, 2007 Author Report Share Posted September 20, 2007 Hi thanks I think that has actually done the job and the firmware appears to be better as I had a beta version. I will test the incoming calls now to see if they actually can get transfered and let you know. Sara. -------------------------------------------------------------------------------- Sent to tls:192.168.1.3:5061 at 20/9/2007 22:15:33:929 (547 bytes): REGISTER sip:192.168.1.3 SIP/2.0 Via: SIP/2.0/TLS 192.168.1.6:1025;branch=z9hG4bK-tml41bj696i3;rport From: "PBX Gateway" <sip:200@192.168.1.3>;tag=ezdw7g6xl2 To: "PBX Gateway" <sip:200@192.168.1.3> Call-ID: 3c26702ac79f-0h495mvgwdbu CSeq: 1 REGISTER Max-Forwards: 70 Contact: <sip:200@192.168.1.6:1025;transport=tls;line=zq5p1hzm>;q=1.0;flow-id=1;+sip.instance="<urn:uuid:38070bbf-d2cf-4420-90d0-b950ac8255f3>" User-Agent: snom370/7.1.19 Supported: gruu Allow-Events: dialog X-Real-IP: 192.168.1.6 Expires: 86400 Content-Length: 0 -------------------------------------------------------------------------------- Received from tls:192.168.1.3:5061 at 20/9/2007 22:15:34:391 (462 bytes): SIP/2.0 401 Authentication Required Via: SIP/2.0/TLS 192.168.1.6:1025;branch=z9hG4bK-tml41bj696i3;rport=1029 From: "PBX Gateway" <sip:200@192.168.1.3>;tag=ezdw7g6xl2 To: "PBX Gateway" <sip:200@192.168.1.3>;tag=41c8826e02 Call-ID: 3c26702ac79f-0h495mvgwdbu CSeq: 1 REGISTER User-Agent: pbxnsip-PBX/2.0.3.1715 WWW-Authenticate: Digest realm="192.168.1.3",nonce="b21e2d2e47efc0d2102367c4c8f04ee3",domain="sip:192.168.1.3",algorithm=MD5 Content-Length: 0 -------------------------------------------------------------------------------- Sent to tls:192.168.1.3:5061 at 20/9/2007 22:15:34:407 (726 bytes): REGISTER sip:192.168.1.3 SIP/2.0 Via: SIP/2.0/TLS 192.168.1.6:1025;branch=z9hG4bK-p5hy1m7sj0xp;rport From: "PBX Gateway" <sip:200@192.168.1.3>;tag=ezdw7g6xl2 To: "PBX Gateway" <sip:200@192.168.1.3> Call-ID: 3c26702ac79f-0h495mvgwdbu CSeq: 2 REGISTER Max-Forwards: 70 Contact: <sip:200@192.168.1.6:1025;transport=tls;line=zq5p1hzm>;q=1.0;flow-id=1;+sip.instance="<urn:uuid:38070bbf-d2cf-4420-90d0-b950ac8255f3>" User-Agent: snom370/7.1.19 Supported: gruu Allow-Events: dialog X-Real-IP: 192.168.1.6 Authorization: Digest username="200",realm="192.168.1.3",nonce="b21e2d2e47efc0d2102367c4c8f04ee3",uri="sip:192.168.1.3",response="1e0c846356a4845d892ec6a27cb325a2",algorithm=MD5 Expires: 86400 Content-Length: 0 -------------------------------------------------------------------------------- Received from tls:192.168.1.3:5061 at 20/9/2007 22:15:34:471 (436 bytes): SIP/2.0 200 Ok Via: SIP/2.0/TLS 192.168.1.6:1025;branch=z9hG4bK-p5hy1m7sj0xp;rport=1029 From: "PBX Gateway" <sip:200@192.168.1.3>;tag=ezdw7g6xl2 To: "PBX Gateway" <sip:200@192.168.1.3>;tag=41c8826e02 Call-ID: 3c26702ac79f-0h495mvgwdbu CSeq: 2 REGISTER Contact: <sip:200@192.168.1.6:1025;transport=tls;line=zq5p1hzm>;q=1.0;flow-id=1;+sip.instance="<urn:uuid:38070bbf-d2cf-4420-90d0-b950ac8255f3>";expires=360 Content-Length: 0 -------------------------------------------------------------------------------- EDIT: Nope it did not work. I have to setup two connections one with TLS and one without and this creates a subscription but I am able to receive incoming calls in the clear and make outgoing calls secured. This is a very strange situation indeed. Quote Link to comment Share on other sites More sharing options...
Brian West Posted January 18, 2008 Report Share Posted January 18, 2008 This is a bug in the snom when dealing with TLS. Example the phone registers and says contact sip:1.2.3.4:2053;transport=tls.. when infact that is NOT true. The contact port is not the true TLS port. I have tried for over a week to get this resolve with snom but nobody responds to me. The subscriptions are also done with the wrong port in the contact. I have run into this while making the tls workwith FreeSWITCH (http://www.freeswitch.org) If anyone knows how to get in touch with Snom so we can get this resolved it would be great. In addition they have a bug with SRTP related to the SDP. When they have SRTP on they should send both RTP/AVP and RTP/SAVP to interop as per the RFC. Right now if you enable SRTP they ignore stuff sent to the phone in the sdp that has SAVP in it. That is invalid. /b Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 19, 2008 Report Share Posted January 19, 2008 Example the phone registers and says contact sip:1.2.3.4:2053;transport=tls.. when infact that is NOT true. The contact port is not the true TLS port. I have tried for over a week to get this resolve with snom but nobody responds to me. The subscriptions are also done with the wrong port in the contact. Check out the discussion about outbound (http://www3.tools.ietf.org/html/draft-ietf-sip-outbound-11). That is practically what everybody is doing today. This is a defacto must, because otherwise you don't get TLS working behind NAT. In addition they have a bug with SRTP related to the SDP. When they have SRTP on they should send both RTP/AVP and RTP/SAVP to interop as per the RFC. Right now if you enable SRTP they ignore stuff sent to the phone in the sdp that has SAVP in it. That is invalid. Well, the problem is if you indicate RTP/SAVP then the other side will reject it if it does not support SRTP. Using RTP/AVP means "tentative" SRTP. The PBX does the same thing. Quote Link to comment Share on other sites More sharing options...
Brian West Posted January 22, 2008 Report Share Posted January 22, 2008 Check out the discussion about outbound (http://www3.tools.ietf.org/html/draft-ietf-sip-outbound-11). That is practically what everybody is doing today. This is a defacto must, because otherwise you don't get TLS working behind NAT.Well, the problem is if you indicate RTP/SAVP then the other side will reject it if it does not support SRTP. Using RTP/AVP means "tentative" SRTP. The PBX does the same thing. RTP/SAVP issue means you offer both AVP and SAVP with two m lines in the sdp. Polycom does this. Example(Grandstream requires SAVP if SRTP is on and not required): Guess everyone needs to look at rfc3711 again. It says that RTP/SAVP is to be used for SRTP. v=0 o=- 1201012745 1201012745 IN IP4 10.0.1.240 s=Polycom IP Phonec=IN IP4 10.0.1.240 t=0 0 m=audio 2266 RTP/SAVP 9 0 8 18 101 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=crypto:127 AES_CM_128_HMAC_SHA1_80 inline:uydNNjszDIFqPcybssMOVqhF4mreoqZbMuSz4gty a=crypto:128 AES_CM_128_HMAC_SHA1_32 inline:lQ5FsO9tvyej9hjU1JKotlRZa1voerKep1DCMvVc m=audio 2266 RTP/AVP 9 0 8 18 101 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 As for TLS that is not true. Polycom doesn't do this. The same issue applies to every subscription. In addition TLS doesn't have NAT issue due to a constant connection to the server its TCP and not UDP. Example: tcp 0 0 10.0.1.250:5061 10.0.1.241:2049 ESTABLISHED Call-ID 3c275e6e7456-20752zlwccx8 User 1000@10.0.1.250 Contact "Snom 300" <sip:1000@10.0.1.241:2048;transport=tls;line=mmp6aa8s> Agent snom300/7.1.30 Status Registered(unknown) EXP(2008-01-22 09:02:00) This is 100% broken. If you are on port 2049 then you MUST register and say you're on port 2049... I have seen these ports 20-30 ports apart in my test. For example I have seen it say 2048 in the contact but actually be on 2069. How am I to contact the phone when it lies about where it actually is? I can use the src port but then that is broken also due to subscriptions being wrong too. The phone shouldn't lie. And NAT isn't involved in my testing... so someone is broken and I feel its Snom. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 22, 2008 Report Share Posted January 22, 2008 RTP/SAVP issue means you offer both AVP and SAVP with two m lines in the sdp. Polycom does this. Example(Grandstream requires SAVP if SRTP is on and not required): Guess everyone needs to look at rfc3711 again. It says that RTP/SAVP is to be used for SRTP. We probably have to accept this way of proposing SRTP, that's true. As for Polycom, good luck with the interoperability. It is simple not backward compatible with most of the stuff that is out there. Just adding two crypto lines sounds much more backward compatible to me. If everything goes well, the IETF will use DTLS on the RTP connection to negotiate the keys "end to end" anyway soon. Maybe that will solve the problems that we have with the key negotiation depending on the transport layer soon. Hopefully this will not increase the setup time too much. The phone shouldn't lie. And NAT isn't involved in my testing... Well, if you are behind NAT you have no other choice than to lie. Or how else would you find out what port the router is using? Is STUN the answer here? Or Turn (LoL)? The PBX has no other choice than to deal with this. Actually the PBX does not even look at the contact. You can write there "0.0.0.0" or just "have.a.nice.day". The only thing that counts for the PBX is the TCP connection, this is stored in the internal registration database. When the PBX wants to send something to the phone, it just used the existing connection. Simple. I know that is not what the IETF envisioned. But in a lack of sense for reality, the IETF requires that there is no NAT for using SIP. If we want to sell a product today, we cannot listen to such bright ideas. Maybe the answer is that everybody should use Cisco Call Manager. The CCM does not have any of such problems, it just works on a persistent TLS connection for Skinny through anything. Sometimes I have the feeling that Cisco sends engineers to the IETF that have nothing better to do than propose standards that are impossible to roll out. Like the idea on how SIP should use TCP and TLS. Quote Link to comment Share on other sites More sharing options...
Brian West Posted January 23, 2008 Report Share Posted January 23, 2008 We probably have to accept this way of proposing SRTP, that's true. As for Polycom, good luck with the interoperability. It is simple not backward compatible with most of the stuff that is out there. Just adding two crypto lines sounds much more backward compatible to me. The two crypto lines are fine its two crypto suites so you can use strong crypto if the other end supports it. If everything goes well, the IETF will use DTLS on the RTP connection to negotiate the keys "end to end" anyway soon. Maybe that will solve the problems that we have with the key negotiation depending on the transport layer soon. Hopefully this will not increase the setup time too much.Well, if you are behind NAT you have no other choice than to lie. Or how else would you find out what port the router is using? Is STUN the answer here? Or Turn (LoL)? The PBX has no other choice than to deal with this. Actually the PBX does not even look at the contact. You can write there "0.0.0.0" or just "have.a.nice.day". The only thing that counts for the PBX is the TCP connection, this is stored in the internal registration database. When the PBX wants to send something to the phone, it just used the existing connection. Simple. I know that is not what the IETF envisioned. But in a lack of sense for reality, the IETF requires that there is no NAT for using SIP. If we want to sell a product today, we cannot listen to such bright ideas. Maybe the answer is that everybody should use Cisco Call Manager. The CCM does not have any of such problems, it just works on a persistent TLS connection for Skinny through anything. Sometimes I have the feeling that Cisco sends engineers to the IETF that have nothing better to do than propose standards that are impossible to roll out. Like the idea on how SIP should use TCP and TLS. Well this isn't related to using snom phones with your product. I'm seeing contacts with someone at Snom to report these bugs. (and they are bugs). When you use SIP you must honor the contact and port in the registration or use stun to not lie about it. If you try to do it via any other method you will run into issue. My biggest drive is the interop with FreeSWITCH as I'm one of the core developers of the project. http://www.freeswitch.org Thanks, Brian West Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 23, 2008 Report Share Posted January 23, 2008 My biggest drive is the interop with FreeSWITCH as I'm one of the core developers of the project. That's no problem... Interoperability is what drives this industry! Quote Link to comment Share on other sites More sharing options...
Brian West Posted January 26, 2008 Report Share Posted January 26, 2008 That's no problem... Interoperability is what drives this industry! w00t finally... I have a conference call next week with the CEO of Snom. Hopefully we can get most of these issues resolved. /b Quote Link to comment Share on other sites More sharing options...
Sara_Donald Posted May 8, 2008 Report Share Posted May 8, 2008 Can someone update what Snom have said regarding this bug. This is why I am getting multiple rtp streams. Voip Provider routes calls from Thailand to me on rtp but then Snom is registered on 1025 and the pbx and snom rtp is default. I have tested this by not allowing 1000 to 3000 udp and no more multiple rtp streams but an error in the pbx about rtp. I have tried to change the rport in snom but even when I set it to register on port 5061 it still registers on 1025 or 1029. I think for the sake of security this should be changed. Sara. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.