Subject: [MMUSIC] CapNeg aware intermediate which does not support specific alternatives

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 12 Nov 2008 17:08:08 +0100

Hi,

Assume there is an intermediate which DOES support Cap Neg, but it
doesn't support one or more of the alternatives/profiles.

The intermediate could of course reject the whole offer, but another
option is that the intermeidate removes the stuff it doesn't support. I
think that would be good to indicate in the spec.

Regards,

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

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 12 Nov 2008 09:56:51 -0700

Christer wrote:
> The intermediate could of course reject the whole offer, but
3264 is SDP agent, an offerer and an answerer. In your example, at what
point do you consider the "intermediate" to be one of the agents that is
doing the o/a exchange and intrusive in e2e SDP?

> another option is that the intermeidate removes the stuff it
> doesn't support. I think that would be good to indicate in the
> spec.
In your above example, what is specific to capneg?
Take most SDP params, have an intermediate that understand an SDP
attribute mangle it and things may break.  This is true for an
intermediate changing codecs, packetization time, groupings, etc.  I
don't think we should have a new mandatory "SBC Considerations" section
in all SDP drafts.

At the same time, if folks are interested in capturing some of this, we
could discuss means to do it.
A few thoughts:
	- we have draft-ietf-mmusic-media-path-middleboxes-01 which is
chartered against this milestone in the charter: "Submit Considerations
for using SDP offer/answer with middleboxes for BCP".  It's received
limited reviews.  While the current content of the ID is more on MIDCOM
boxes and interactions between media path signaling and those, can it be
extended to cover additional considerations on middleboxes that act as
SIP ALG/B2BUA?

	- are folks interested in having a cooking guide for SDP as a
separate ID?  Target audience = folks who write I-Ds about SDP
attributes and those who implement SDP.  This could capture known
recipes, highlight implementation considerations on things that come up
from time to time such as the intended use of ptime, and that could also
include mention something on the effect of intermediaries there?

comments?
Jean-Francois.

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 13 Nov 2008 01:51:32 +0100

Hi, 

>3264 is SDP agent, an offerer and an answerer. In your example, at what
point do you consider the "intermediate" to be 
>one of the agents that is doing the o/a exchange and intrusive in e2e
SDP?

The intermediate does not trigger the o/a, but it receives an offer and
uses the SDP to trigger some actions, e.g. reserve media resources in a
media proxy. That is typical SBC behavior.

>>another option is that the intermeidate removes the stuff it doesn't
support. I think that would be good to indicate in 
>>the spec.
attribute mangle it and things may break.  This is 
>true for an intermediate changing codecs, packetization time,
groupings, etc.  I don't think we should have a new 
>mandatory "SBC Considerations" section in all SDP drafts.

We already have text about intermediates in the CapNeg spec. For
example, the award winning backward compability statemement saying "Make
sure you intermediates support it" :)

>	- we have draft-ietf-mmusic-media-path-middleboxes-01 which is
chartered against this milestone in the charter: >"Submit Considerations
for using SDP offer/answer with middleboxes for BCP".  It's received
limited reviews.  While the 
>current content of the ID is more on MIDCOM boxes and interactions
between media path signaling and those, can it be 
SIP ALG/B2BUA?

Perhaps.

Regards,

Christer