Re: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer

[Joerg Ott <jo@xxxxxxxxxxxxx>]

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

That would be desirable, indeed.

> >   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 (*)).  

Yepp.  I deliberately left the best effort part out of the
consideration since the mail already got too long.

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

At this point I would assume that not so many less SAVP-capable
SIP endpoints, so that putting AVP first would probably serve
interoperability.

I am afraid, we may have to made some tradeoff of this kind.
This does not go away if you offer SAVP in an attribute for
caps negotiation (see below).

We have many endpoints and some may need to be upgraded to
do secure RTP with all options as we want them to.  Given
my own experience with a small zoo of different SIP endpoints,
we should not rule out this option as this has been practice
in the past.  If we can hurt a bit more now and get something
solid finally sorted out, I would want to go for this.

>     (*) 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.

What I should have added here: while the above discussion assumed
some kind of grouping for UA_G, Flemming's capability negotiation
draft could serve as a baseline to achieve the same purpose.  It
may even not have some of the issues with plain grouping.

Yet, we have grouping and it would be nice to ultimately get
agreement on where the boundaries for the grouping framework
lie.  The earlier we define this (and what we expect to be
the future solution), the fewer issues with a huge installed
base we will have.

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

We'll have to do something here to fix this.  And I am afraid we won't
get around declaring some of them 'broken' in some respect.  But the
earlier we do this the better.  And of course, we need to pick our
mechanism of choice fairly quickly.

Joerg