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

[Emil Ivov <[e-mail]>]

On Wed, Oct 9, 2013 at 7:30 PM, Bernard Aboba <[e-mail]> wrote:
> [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.

Well, at least you'd get to establish an RTP/AVP call with no
encryption. The same goes for endpoints that have SDES support and
tolerate RTP/AVP as transport when they detect the crypto attributes
(without supporting RFC5939).

I agree that legacy endpoints with no 5939 support that insist on
having RTP/SAVP, would reject it but at least we would limit those
cases.

> 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.

True.

>> 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" :(

Well, not even that. I'd be happy with a story that allows us to
generate offers in a way that would allow for an RTP/AVP call to be
established with standards compliant legacy and an RTP/SAVPF call with
modern endpoints (including gatewayed WebRTC).

> 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.

OK, this does sound reasonable but it would also mean that a
SIP-2-WebRTC gateway would *always* need to modify the first offer
from the SIP UAs even if they are perfectly interoperable otherwise.
Not that this is that much of a big deal but I was still hoping we
could have at least one case where gatewaying SIP to WebRTC would only
be a matter of extracting the SDP and sending it down to the browser.

Emil


--
https://jitsi.org