Re: [MMUSIC] RTP/AVP vs RTP/AVPF vs RTP/SAVPF vs .... how to pick a default?

[Bernard Aboba <[e-mail]>]

[BA] Comments below. 
 
Emil said: 
 
Oops, hit sent a bit too early. I wanted to add that that the least
painful option would obviously be to add tcap attributes as per 5939
and then keep RTP/AVP in the m= line but that would still be rejected
by a WebRTC endpoint (right?) so do we need to adjust JSEP to allow
RTP/AVP if the m= line contains the necessary transport capabilities?
 
[BA] Unfortunately the legacy endpoints whose behavior is the cause of this issue are unlikely to support RFC 5939, so I can't see how that would help. 

Emil

On Wed, Oct 9, 2013 at 5:44 PM, Emil Ivov <emcho at jitsi.org> wrote:
> Hey all,
>
> We've recently implemented support for DTLS/SRTP and a question that
> we had somehow avoided in the past with SDES and ZRTP is now back on
> the table:
>
> By default, which profile would a SIP UA use in an outgoing offer?
>
> Until recently recently we were offering RTP/AVP by default, which is
> ok for ZRTP and tolerated by most of the endpoints that support SDES.
 
[BA] I would add that RTP/AVP is also tolerated by endpoints that support feedback. 

> We also had a couple of config options that allowed Jitsi to (A)
> create offers with RTP/SAVP(F) in case someone turned out to be picky
> about the transport or (B) duplicate all m= lines and offer them with
> every supported transport so that the remote endpoint would pick what
> it likes.
 
[BA] In my experience option B doesn't work that well, because implementations that do not support RTP/SAVPF will not always respond by setting the port to zero on those m lines, as they should.   Instead they may respond with an error.  So you're likely to have problems, "unified" not withstanding. 

> Obviously option (A) is not a suitable default for a generic SIP UA
> because that would make it incompatible with the majority of the
> endpoints that exist today. (B) could have worked but now that we are
> going for "Unified", having the same "m=" line appear with RTP/AVP and
> then again with RTP/SAVPF would have to be interpreted as two
> independent streams rather than the same stream being available over
> two different transports.
>
> So, do we have a story here or do we need to create one?

[BA] If by "have a story here" you mean "have a standards-based way of reliably interoperating with non-standards compliant legacy UAs", I think the answer is  unfortunately "no" :(
 
In practice you might try substituting the following for your option B: 
 
By default, offer RTP/AVP with a= lines describing the crypto and feedback features you support.    If the answerer is legacy, you'll have the highest chance of backward compatibility this way.  You may even get back an answer with a profile of RTP/(S)AVPF, indicating that the answerer understands what you are really offering.  If that happens you can offer RTP/(S)AVPF in re-invites or other subsequent exchanges.