Jump to content

Brian West

Members
 View Profile  See their activity

  • Posts

    4

  • Joined

  • Last visited

 Content Type 

Posts posted by Brian West

  2. Incoming TLS on Snom 370

    in snom Phones

    Posted

    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

  3. Incoming TLS on Snom 370

    in snom Phones

    Posted

    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.

  4. Incoming TLS on Snom 370

    in snom Phones

    Posted

    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

×
×
  • Create New...