Subject: [MMUSIC] SDPCapNeg Issue #6: Second Offer/Answer exchange

From: Flemming Andreasen <[email-masked]>
Date: Mon, 25 Jun 2007 13:15:02 -0400

The SDP Capability Negotiation framework currently specifies the 
following operation when the offerer receives the answer:

<quote>
   If the offer/answer exchange was successful, and if the answerer
   selected one of the potential configurations from the offer as the
   actual configuration, then the offerer MAY perform another
   offer/answer exchange: The new offer should contain the selected
   potential configuration as the actual configuration, i.e. with the
   actual configuration used in the "m=" line and any other relevant
   attributes. This second offer/answer exchange will not modify the
   session in any way, however it will help intermediaries that look at
   the SDP, but do not understand or support the capability negotiation
   extensions, to understand the details of the media stream(s) that
   were actually negotiated. If it is known or suspected that one or
   more such intermediaries exist, then this second offer/answer SHOULD
   be performed (this is already done when using Interactive
   Connectivity Establishment [ICE]).
</quote>

ICE has this second offer/answer exchange at MUST strenght, and hence 
the question was raised whether this second offer/answer exchange should 
be at MAY, SHOULD, or MUST strength. Francois Audet was against having 
this second exchange at MUST strength, but is OK with the current text. 
Since there were no objections to the current text/recommendation 
otherwise, it will stay as-is.

A problem scenario was brougth up though:
1) Offerer generates an offer SDP with the actual configuration 
specifying a low-bandwidht configuration, and a potential configuration 
specifying a high(er) bandwidth configuration.
2) A middle-box (e.g. P-CSCF or SBC) that is SDPCapNeg unaware 
authorizes the session based on the actual configuration.
3) The answerer chooses the high(er) bandwidth configuration and 
generates an answer accordingly.
4) Middle-box passes through the answer
5) Offerer now generates a second O/A exchange as a courtesy to any 
middle-box, which specifies the high(er) bandwidth configuration that 
was chosen.
6) Middle-box sees the second O/A exchange, does not want to authorize 
use of the QoS required and hence rejects it.
7) Offerer receives the rejected offer.

After step 7, per RFC 3264, the original (completed) O/A exchange 
remains in effect, however since the middle-box has not authorized the 
QoS, quality may suffer.

There is not a lot we can (or will) do about this issue in the base SDP 
Capability Negotiation framework, however the document will elaborate on 
the issue per the above example and explain why an SBC, P-CSCF, etc. 
should understand the capability negotiation framework (so it can 
authorize correctly in the first place).

If you disagree with this, please let me know.

Thanks

-- Flemming

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