We support method 2 right now in FreeSWITCH, but we 488 method 1, and don't do method 3. What behavior could we change on the freeswitch side to support the most possible devices transparently?
Mike On Oct 5, 2010, at 7:20 AM, Jean-Hugues Royer wrote: > Hi, > > In fact they are right about that: > > RFC4568 - The "crypto" attribute MUST only appear at the SDP media level > RFC4568 - SRTP security descriptions MUST only be used with the SRTP > transport (e.g., "RTP/SAVP" or "RTP/SAVPF"). > > The problem was the need to tell the remote that we optionally support > RTP & SRTP. > > Two methods were usually used, the first one was to use a crypto > attribute in a RTP/AVP media like snom does and funnily asked you to > refuse, and the second was to use two media lines in the SDP one with > RTP/AVP and the other with RTP/SAVP with the crypto attribute. The > later one being totally legit but creating big SDP with redundant > information. > > A third method (involving new SDP attributes called tcap/pcap) has now > been recently (September 2010) officially accepted as RFC5939 and is > available for reading here: http://tools.ietf.org/html/rfc5939 > > Regards. > > -------------- > funny story about this one, the guys at snom filed a bug in freeswitch a > while back complaining that we accepted a=crypto in an m=audio RTP/AVP > section, saying we should always 488 that call as a=crypto should only > be in SAVP. Turns out their default config is to send it wrong, and the > only device we have issues with on this is the Snom phones. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
