Jump to content

Incoming TLS on Snom 370


Sara
 Share

Recommended Posts

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

Link to comment
Share on other sites

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]

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 months later...

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 3 months later...

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...