RE: alternate RTP profiles in SDP offer/answer

["Dan Wing" <dwing@xxxxxxxxx>]

Joerg Ott wrote:

> > There's an SDP parser (and application) that understands 
> > and handles RFC 3388?
> > 1/2 :-)  Seriously, I'm sure there are some, and I'm also 
> > pretty darn certain
> > they're rare.  I'd love it if I was wrong.
> 
> :-)
> 
> (acutally, I think this is the right starting point)
> 
> Well, looking at what we currently have, let me try some
> constructive discussion here (yes, we have a potential issue
> here in terms of inconsistency; but, hey, we have had those
> before and I believe they are much more "potential" than many
> others).
...
> So, we have 9 permutations of who can call whom
...
> 3. UA_G -> UA_P: If UA_G includes a grouped description
>    UA_P will not understand it and interpret the m=
>    lines independently.  This is plain RFC 3388 without
>    any overloading of any sort.  Since UA_P does not
>    understand the secure alternative, it will simply
>    reject it.

Agreed.

But this does require obtaining a UDP port for every RTP profile in the
offer, which adds to ICE processing and adds another NAT pinhole for every
RTP profile that is negotiated.  I don't know how grouping would work with
ICE's current architecture.

We need the ability to select RTP profiles independant of selecting
transport address.

>    UA_G -> UA_S: In this case, UA_S may get confused
>    because it receives a secure and an insecure m= description
>    (not using the same port number because UA_G will be aware
>    and not do this).
>
>    If UA_S accepts both (would probably be the first IP phone
>    to accept two audio streams at least I have seen),

The problem is more nuanced if an offerer wants best-effort SRTP.  Near as I
can tell, RFC3388 implies that the offerer's first grouped media line is the
offerer's most-preferred media line in that group (but I can't see where it
outright states this (*)).  

Let's assume that we required SAVP-capable endpoints to support RFC3388bis
(as you described later; see below).  An offerer that wants best-effort SRTP
is still in a dilemma:  should SAVP or AVP appear first in the SDP?  In
order to get SRTP with an SRTP-capable UA_G, the offerer needs to place SAVP
first; but in order to get RTP with a UA_P, the offerer will place AVP
first.

    (*) The identification-tag might be able to express this in
        RFC3388bis; in RFC3388, however, the value of the
        identification-tag appears to only provide a label.  I 
        don't find text in RFC3388 that says that a media 
        stream with "1" is more-preferred than a media stream 
        with "2".  RFC3388bis could fix this.

...
> I hope I did not miss too much but I guess you will tell me :-)
> It's only meant as a starting point to get some systematic
> approach into the whole discussion.

Thanks for the detailed email.  It helped me grasp the situation.


I sincerely believe we need the ability to use the same transport address
for different RTP profiles.  To do this with grouping, we would have to
revise RFC3388 to allow port overloading; let's call that RFC3388bis, whose
only change would be to eliminate RFC3388's prohibition of port overloading.
If we created RFC3388bis, we could mandate that RFC3388bis be used to
negotiate RTP profiles.  But that still won't get non-RFC3388bis-aware
endpoints to know what they're supposed to do when they see port-overloaded
media lines.  I suppose we could declare them to be broken.  But that's a
lot of endpoints.

-d