Subject: RE: [Sipping] RE: Early media in the INVITE offer/answer context

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 12 Dec 2002 03:44:00 -0500

inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Wednesday, December 11, 2002 11:46 AM
> To: Peterson, Jon
> Cc: 'Gonzalo Camarillo'; 'sipping'
> Subject: Re: [Sipping] RE: Early media in the INVITE offer/answer
> context
> 
> 
> no major disagreements with you in this message.  one difference of 
> degree near the bottom....
> 
[snip]
> 
> Alert-Info, Error-Info, etc... are all really good, but we can't make a 
> blanket assumption that these will work.  There is currently no way for 
> a UAS to figure out if the UAC is capable of handling one of these, or 
> the URI included therein.
> 

Fortunately, we're talking about using Alert-Info to provide information
that is supplemental to the status of the call. It should be okay if the UAC
is not capable of handling the early media. And it is also fine to establish
a dialog in the backwards direction if you want to be certain that the UAC
is accepting the media.

Anyway, there's also no way for the UAS to figure out if the UAC will be
able to manage pre-answer media in the INVITE's offer/answer context. If it
sends it, though, the UAC is forced to contend with it, unlike Alert-Info.

[snip]
> > ... my recommendation is that it be allowed only
> > in those cases in which gateways cannot express status information in
any
> > other way.
> 
> I think your recommendation is a bit harsh.  You are proposing a MUST 
> NOT instead of a SHOULD NOT.
> 
> a UAS SHOULD NOT send media before it sends a 200 OK unless it cannot 
> express early status information in any other way.
> 

Pretty much. To be more precise, I mean something like:

A UAS MUST NOT use a backward media stream in the offer/answer context of
the original INVITE to send pre-200 OK media unless it cannot express early
status information any other way. Typically, only gateways that interworking
with non-SIP networks (such as the PSTN) will need to resort to this way of
communicating status information.

While I understand that downgrading this to SHOULD NOT is an obvious way to
compromise, (and at the risk of sounding unnecessarily obstinant,) I still
haven't been able to glean from this thread a single reason why we should
validate this.

> note that even with this strong recommendation, the UAC needs to be 
> robust in handling early media from a variety of implementations that 
> predate this recommendation.
> 

Agreed. This is just a UAS behavior issue. 

[snip] 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 18 Dec 2002 05:28:31 -0500

Some notes inline.

Jon Peterson
NeuStar, Inc.

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Tuesday, December 17, 2002 5:25 AM
> To: Peterson, Jon
> Cc: 'sipping'
> Subject: Re: Early media in the INVITE offer/answer context
> 
> 
> Jon,
> 
> > This problem seems to be the same as that of the globally-routable
contact
> > address problem that is currently being considered in REFER and
conferencing
> > work. This is a SIP problem that will be solved, I think.
> 
> Yes, it is the same problem. What is the status of that work?
> 

Well, someone in the relevant design team could probably answer that
question better than I. As I said above, I think this is a solvable problem.
Many contact addresses in use today are globally routable. We also know how
to insert routing information into URIs. I don't think this is a question of
whether or not we can skin the cat, just a question of how the cat can best
be skinned.

> I find it valuable to distinguish, as you pointed out, between a UAS
> that sends early media that is "optional", and a UAS (probably a
> gateway) that cannot know whether or not the early media it is sending
> is optional.
> 

Cool.

> In addition to using a related dialog in the opposite direction to
> establish this "optional" early media, we could use a new stream in the
> same offer/answer context (established with an UPDATE). We could even
> define an SDP media attribute to label the new stream as optional (i.e.,
> non-essential in-band information). This would achieve the same as the
> related dialog approach, but it involves less signalling (UPDATE instead
> of INVITE) and does not have the globally routable URI problem. Besides,
> the UAS has to store state for one dialog, not for two.
> 
> Thoughts?
> 

I think this is a layering question - is the meaning of the session, its
semantics, something that belongs in the SIP layer or the SDP layer? Adding
a new attribute to SDP that indicates that a media stream is optional is
certainly possible, but I'm not sure if we want to start putting this sort
of information in SDP. For example, if you reject the optional session, are
you rejecting it because you aren't able to support it (but would be willing
to support some other codec, say, for such media) or because you aren't
willing to accept it?

Anyway, I'm not necessarily sure that it's less signaling... it needs to be
enough signaling to accomodate an offer/answer - no more, no less. True that
INVITE is minimally a three way handshake vs. two way for UPDATE, but I
don't think the difference is that material (subsequent UPDATEs might be
necessary to deactivate such media streams, right?). If you really want to
save on signaling, avoid globally-routable contact addresses and whatnot,
then Alert-Info is probably the best option.

> Gonzalo