Re: alternate RTP profiles in SDP offer/answer

[Joerg Ott <jo@xxxxxxxxxxxxx>]

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

Here is a proposal to beat up (which I am making specifically for
the AVPF-SAVPF or AVP-SAVP cases, since this triggered the whole
discussion):

We are concerned about peers having to figure in an O/A exchange
how to agree in an ideally backward-compatible fashion on a common
mode of operation.  We have RFC 3388, RFC 4566, RFC 4585, the SAVPF
draft and some yet unspecified grouping format; let's call this
latter thing AP (= alternative proflie) just for the sake of
brevity).

We can have UAs supporting secury (UA_S) and other not doing
so (UA_P, P = plain).  We also may have future UAs that support
the "AP" grouping scheme and RFC 3388 (UA_G).  They clearly do
not exist at this point because we do not have AP define.

Let me make the assertion that we do not have currently so many
deployed UA_S.  We have also no UA_G type endpoints.

So, we have 9 permutations of who can call whom

1. Whenever a UA_P initiates a dialog, this is straightforward:
   no secure profile will show up and we are done.  This covers
   the first three cases: UA_P -> *

2. A UA_S does not know about grouping and so it will send
   either only AVP or SAVP but not both.  A receiving UA_S
   will always accept, a UA_P only accept AVP and reject
   everything else as not supported, and a UA_G will also
   accept a simple non-grouped thing.  This covers the
   next three cases: UA_S -> *

   In detail:

   UA_S -> UA_P: even if the disallowed port grouping
   was used, UA_P would not understand it and reject the
   SAVP session because it does not support security.

   UA_S -> UA_S: I tend to assert that Even if UA_S exist,
   they will not have gotten the strange idea of offering two
   media session descriptions with the same port number
   simply because this is not defined according to RFC 4566.
   If they have, they are simply non-compliant to SDP and
   we can't help them.

   UA_S -> UA_G: According to the rule "be conservative in
   what you send and liberal in what you accept" a UA_G
   would follow guidance---to be written up in the "AP"
   spec---and would thus even be able to notice the
   wrong implementation on the other side and react
   accordingly.

   Most importantly, for the latter two cases, note that
   there is a logical difference between offering to
   compatible profiles such as AVP and AVPF on a single
   port (which could be legimate as I mentioned earlier)
   and offering two incompatible profiles such as AVP
   and SAVP.

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.

   UA_G -> UA_G: Both will understand the "AP" grouping
   semantics and everything is fine.

   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
   UA_G would figure this out quickly because the answer
   will not contain the grouping attributes, so it can
   re-INVITE and leave just the secure session active.

   If UA_S accepts just one, this also solves the problem.
   UA_G can tell from the SDP description that the grouping
   attributes were not properly returned.

   The worst case that can happen is that UA_S choses the
   unsecure session even though it would support the secure
   variant as well.  After the initial call setup, UA_G might
   probe whether renegotiation to the secure secure is possible.

So, the only problematic cases are the ones where UA_S receive
calls from other UA_S (which want to do port-based grouping even
or from UA_G.  The latter issue exists independent of the port
grouping discussion since no endpoint is required to understand
RFC 3388.

The next step would be to write the "AP" grouping spec, suggest
that endpoints wanting to support SAVP* also support RFC 3388
and make people aware of this.  The corner cases appear to be
acceptable for an interim period and proper grouping should be
implemented in any case.

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.

Joerg