Brian West

w00t finally... I have a conference call next week with the CEO of Snom. Hopefully we can get most of these issues resolved. /b

The two crypto lines are fine its two crypto suites so you can use strong crypto if the other end supports it. 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

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.

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