Subject: [MMUSIC] Re: SDP Capability Negotiation to address multiple RTP profiles and other issues

From: Randell Jesup <[email-masked]>
Date: Fri, 23 Jun 2006 12:58:49 -0400

>I have submitted a draft on adding capability negotiation to SDP which you
>can retrieve from (abstract below):
>
>http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-capability-negotiation-00.txt
>
>The primary motivation for this is to address the proliferation of RTP
>profiles and the associated problem of negotiating which of possibly
>several supported RTP profiles to use for a given media stream.
...
>Feedback is hereby solicited. In particular, it would be very helpful if
>people could take a look at the requirements and see if they agree with
>them (too much, too little, anything wrong/missing, etc.) before we get
>into detailed discussion around the proposed solution. Having said that,
>all comments are welcome.

REQ-10: there are other ways to deal with the example issue, especially
involving re-INVITE in SIP - though re-negotiation may not be possible in
some uses of SDP.  You may want to mention here or better in the Existing
Work section how re-INVITE/re-negotiation fit in (which applies to a lot of
the requirements, not just this one).

REQ-110: (ability to receive media immediately) and REQ-120 - see below.
These two seem redundant.

Overall, I find it interesting, if complex.  There is a major issue (see
below) to resolve.  The complexity may be such that getting interoperable
implementations may be a challenge.  An effective test suite and set of
examples will be critical.  The problem is a very real one.

It appears to not deal with two issues dealt with by the grouping spec,
which are defining valid combinations of media lines, and defining valid
combinations of codecs (on one media line or between lines).  This would
mean that those particular requirements would still need grouping or SDPng
or ???.  Perhaps at least the first (valid combinations of media lines)
can be worked into this approach?  As you mention, grouping (and even more
so multipart-alternative) have significant compatibility issues.

General issue with the approach:

It's dependant on the offerer receiving the answer in order to decode the
media.  For example, if the transport protocol can be RTP/AVP or RTP/SAVP
(regardless of which is the "actual" offer and which is potential), how
does the receiver process incoming media packets if it hasn't seen the
answer?  Especially if the packet types can't be intuited from something
like size (an example would be SRTP with encryption but no auth tag).  In
some cases this would cause static, could cause potential crashing or
problematic actions.  So the answerer may not be able to send media until
they see ACK (in SIP) if they accept a potential configuration.

This can cause clipping - you pick up the phone and start talking, but if
the answer is lost or delayed, or if the ACK is lost or delayed, your
"hello?" might be lost.

Now, this might be ok, though clipping is to be avoided where possible,
since people assume through experience that media channels are open as soon
as they answer.  Also, if the configuration accepted is the actual one,
the answerer can send media immediately.

Potential solutions:
a) Use different transport addresses for incompatible media/protocols.
   Could be problematic when combined with ICE/TURN/etc - more ports.
   Could cause some combinatoric expansion (especially with ICE/TURN).
b) Use alternative payload types to distinguish incompatible media types
   so that some level of decoding (or at least knowing to ignore packets) 
   can be done before the answer arrives.  This might tell the offerer
   enough to fully decode, though they still can't send until they get
   the answer (which is normal).  It may not tell enough in all cases
   without expansion, and perhaps there are backwards compatibility
   issues.  Also, there may be issues with the number of payload types
   listed (though perhaps the values could be inferred instead of
   explicit) and how that affects the size of the offer.

Discussion of clipping, when and how media is sent, and how packet
loss/delay affect this will be critical.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

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

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Jun 2006 17:53:41 -0400

Thanks for the feedback Randell

Some comments below....

>the requirements, not just this one).
It's a band-aid, not a full solution since as soon as you issue an 
offer, you are supposed to be prepared to receive media encoded with any 
of the codecs offered. I can add some words to that effect.

>These two seem redundant.
They describe two different things. REQ-110 talks about actual 
configurations, e.g. one or more codecs you are prepared to receive at 
this point in time. This is that we currently put in the "m=" line in an 
offer (if we are spec complicant at least). REQ-120 on the other hand 
talks about potential configurations, which would be alternatives we are 
not prepared to receive at this point in time. This could for example be 
things like RFC 3407 simple capability declarations. What REQ-120 adds 
on top of that is that you must be able to negotiate use of those 
potential configurations and be prepared to receive media accordingly 
once (but not before) you actually receive the answer.

>Overall, I find it interesting, if complex.  
>
Thanks. I'm certainly open to other suggestions. What seems most 
important at this point though is agreeing on the requirements. I 
personally think we need to look out for feature creep (don't want to 
replicate SDPng or H.245) so it will be a challenge to figure out where 
to draw the line. More discussion around requirements will be helpful here.

>There is a major issue (see
>examples will be critical.  
>
Good point. I'll make sure to add more examples.

>The problem is a very real one.
>
>which are defining valid combinations of media lines, 
>
Right - there is currently no such requirement in the document, but if 
can of course be added if people believe it is important. Were you 
looking for just saying e.g. "can do audio and video", actual 
combinations of audio of video codecs, or something different ?

>and defining valid
>combinations of codecs (on one media line or between lines).  
>
You can define valid combinations of codecs within a media line with the 
current mechanism. REQ-10 probably needs to be  tighthened up to make it 
clear that allowable combinations within a media stream have to be 
supported as well. There is currently no similar requirement between 
media lines, but again, it can be added if people believe it is important.

>This would
>can be worked into this approach?  
>
Certainly (again if the group is interested in doing so).

>As you mention, grouping (and even more
>answer?  
In general that is true if one of the potential configurations are 
accepted, however it is possible to use different transport addresses 
for each alternative (not that I recommend it). You could envision other 
ways of addressing this as well (all you need is to communicate the 
actual capability information back to the offerer's media part which is 
made somewhat easy by the use of scoped integers as references) .

>Especially if the packet types can't be intuited from something
I'd rather say the offerer may not be able to process such media 
correctly until the answer is received.

>the answerer can send media immediately.
Correct.

>   Could cause some combinatoric expansion (especially with ICE/TURN).
Agreed.

>   explicit) and how that affects the size of the offer.
Right - this is another approach that may help in some cases. You could 
imagine ICE extensions, preconditions (sigh) and other potential 
solutions as well.

>loss/delay affect this will be critical.
Agreed.

Thanks for the comments.

-- Flemming