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

From: Bernard Aboba <[email-masked]>
Date: Wed, 9 Oct 2013 10:30:08 -0700

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

---

From: Emil Ivov <[email-masked]>
Date: Wed, 9 Oct 2013 19:52:22 +0200

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

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

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

> 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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 14 Oct 2013 21:54:25 +0000

Hi Emil,

You may interested in the recommendation provided in the IMTC SIP Security
best practice document. This document was shared with the IETF via the
following liaison statement.
https://datatracker.ietf.org/liaison/1248/

It provides recommendations to negotiated "best effort" security in the
presence of legacy endpoints that support a mix of AVP and SAVP. The logic
it follows is similar to that for AVP/AVPF, as mentioned by Bernard.

Cheers,
Charles

On 10/9/13 10:52 AM, "Emil Ivov" <[email-masked]> wrote:

>> [BA] I would add that RTP/AVP is also tolerated by endpoints that
>>support
>> feedback.
>>
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic