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

From: Emil Ivov <[email-masked]>
Date: Wed, 9 Oct 2013 17:44:10 +0200

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.

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.

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?

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Wed, 9 Oct 2013 18:00:26 +0200

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?

Emil

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 11 Oct 2013 17:36:50 +0000

Theory: Obviously the standards say to do RTP/SAVPF 

Practice: Experimental evidence show that RTP/AVP along with feedback and fingerprint attributes works best 

If you think it is sad that theory does not match practice, submit a draft on best way to resolve that. 

On Oct 9, 2013, at 10:00 AM, Emil Ivov <[email-masked]> wrote:

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 11 Oct 2013 13:35:32 -0700

> If you think it is sad that theory does not match practice, submit a draft on best way to resolve that. 

[BA] The best way to resolve that would be for implementations to properly handle RTP profiles they don't support (by setting the port to zero, rather than returning an error).   Then at least it would be clear what the issue was and one could offer RTP/SAVPF and then if that doesn't work, do the "practical" thing. 
 
There are enough really basic things that aren't widely supported in SIP implementations (like multi-part MIME support) that I suppose we could write a document saying "you really ought to do this.  It was a requirement before, but we REALLY mean it this time.  That means you!".    Unfortunately I don't know it would make a difference :(

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 11 Oct 2013 23:12:29 +0000

> [BA] The best way to resolve that would be for implementations to properly handle RTP profiles they don't support (by setting the port to zero, rather than returning an error).   Then at least it w…

+1

(thought looking at some test results, lots of them do that)

> There are enough really basic things that aren't widely supported in SIP implementations (like multi-part MIME support) that I suppose we could write a document saying "you really ought to do this.…

I given up hope of ever seeing widespread support for multi-part MIME