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

From: Teodora Guenkova-Luy <[email-masked]>
Date: Mon, 26 Jun 2006 12:50:30 +0200

Hi,
I have also a comment to REQ-110 and REQ-120.
Since the potential configurations are pre-conditions for choosing and  
enforcing them as actual configurations, may be a better idea is to 
perform a negotiation with potential configurations in two stages: First 
the offerer and the anserer agree which potential configurations are 
applicable and secondly which are the chosen configurations to become 
actual (i.e. counter-offer and counter-answer). Solution for such 
behaviour can be RFC 3312.

-- 
-----------------------------------------
Teodora Guenkova-Luy

Dept. Distributed Systems, University of Ulm, 
Oberer Eselsberg, 89069 Ulm, Germany

Tel.: +49 (0731) 502-4148 
FAX: +49 (0731) 502-4142

e-Mail: [email-masked]

Home Page: http://www-vs.informatik.uni-ulm.de/dept/staff/guenkova/ 

-----------------------------------------

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

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

---

From: Randell Jesup <[email-masked]>
Date: Mon, 26 Jun 2006 10:05:49 -0400

Teodora Guenkova-Luy <[email-masked]> writes:
>enforcing them as actual configurations, may be a better idea is to perform
>a negotiation with potential configurations in two stages: First the
>offerer and the anserer agree which potential configurations are applicable
>and secondly which are the chosen configurations to become actual
>(i.e. counter-offer and counter-answer). Solution for such behaviour can be
>RFC 3312.

This sounds like a minimum 1.5-round-trip negotiation
(offer/counter-offer/counter-answer).  That appears to violate REQ-100 (it
must work within the offer-answer model, specifically it must do a
negotiation within a single round-trip).  What you're proposing sounds more
like preconditions (though I'm not 100% up on the details of how
preconditions work).

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

---

From: Teodora Guenkova-Luy <[email-masked]>
Date: Mon, 26 Jun 2006 16:54:29 +0200

>like preconditions (though I'm not 100% up on the details of how
Hi,
If you look at REQ-100 the author seems also not to be sure if the 
negotiation of potential configurations should be limited to O/A model 
only. IMHO, you don't need to negotiate potential configurations if you 
are sure that the proposed actual configurations will work as they are. 
Hence, you don't need preconditions for your session. However, if only a 
limited amount of the actual configurations works, your session is also 
limited, and it can be enhaced only through a re-negotiation, but the 
re-negotiation is IMHO more expensive compared to the negotiation of 
potential configurations as it takes place during the media session. If 
you are proposing potential configurations this means that you are not 
sure what kind of answer you'll get and eventually the answerer may 
enhance the proposal of the offerer with further potential 
configurations in order to ease the decision of the offerer what 
configurations to take for the session. Furthermore, the offerer may 
propose potential configurations that might be too expensive for the 
offerer (e.g. in terms of resources), so the offerer has to wait the 
answer in oder to make its final decision. Consequently and due to such 
uncertainties, only after exchanging potential configurations, the 
offerer can decide which configurations can be taken as actual and 
signal them to the answerer. This is no more O/A model, as the proposals 
for potential configurations work as pre-conditions for the success of 
the following session.

---

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

>like preconditions (though I'm not 100% up on the details of how
Right. Given the amount of negative feedback receved from implementers 
of preconditions, I don't think we can rely on that (which is not to say 
we can't define additional operations that can take advantage of such 
mechanisms and the extra half or full roundtrip).

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Jun 2006 18:02:44 -0400

Teodora Guenkova-Luy wrote:

> only. 

Correct, but I believe it is an absolute requirement that it does work 
within that model.

> IMHO, you don't need to negotiate potential configurations if you are 
> sure that the proposed actual configurations will work as they are. 
> Hence, you don't need preconditions for your session. However, if only 
> a limited amount of the actual configurations works, your session is 
> also limited, and it can be enhaced only through a re-negotiation, but 
> the re-negotiation is IMHO more expensive compared to the negotiation 
> of potential configurations as it takes place during the media session. 

Agreed - negotiation of the potential configurations should be an 
integral part of the initial negotation process and hence not require 
separate renegotation (we can more or less do that with existing 
mechanisms already, e.g. just include RFC 3407 capability information in 
both the offer and answer).

> If you are proposing potential configurations this means that you are 
> not sure what kind of answer you'll get and eventually the answerer 
> may enhance the proposal of the offerer with further potential 
> answer in oder to make its final decision. Consequently and due to 
> such uncertainties, only after exchanging potential configurations, 
> the offerer can decide which configurations can be taken as actual and 
> signal them to the answerer. This is no more O/A model, as the 
> proposals for potential configurations work as pre-conditions for the 
> success of the following session.

This sounds like more full fledged capability negotation ala SDPng and 
I'm not sure we want to take the proposal that far. We'll need to agree 
on the requirements first I guess.

-- Flemming