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

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 11 Dec 2002 04:10:53 -0500

Some notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Sunday, December 08, 2002 8:43 AM
> To: Peterson, Jon
> Cc: 'Rohan Mahy'; 'Francois Audet'; 'William Marshall';
> [email-masked]'; [email-masked]';
> [email-masked]'; 'Alan Johnston'; 'sipping'; 'Adam Roach'
> Subject: Early media in the INVITE offer/answer context
> 
> 
[snip]
> 
> 
> 
> My response to the conceptual issues:
> 
> It is true that the status codes already provide information about how
> session establishment is progressing. However, we do not need to limit
> this information to the information that can be conveyed using a status
> code. If I want to use personallized ring back tones, I should be able
> to do it. When Jon calls, I want him to hear my special ringback for him
> (i.e., "Hi Jon, I will be with you shortly"). We may claim that this is
> a stupid way of wasting badwidth, but this is not up to the protocol
> designers to decide.
> 

Of course, I want to allow this capability, and SIP already allows this in
numerous ways other than sending early media in the INVITE offer/answer
context. Doing it in the INVITE offer/answer context leads to problems (like
forking, which you acknowledge but do not address in your technical
response) - isn't this alone a sufficient reason to prefer the alernatives?

In any event, I'm not trying to block that application.

> My point is that early media related to session progress should be
> allowed.
> 

I think my main point is that early media that completely  -replaces- normal
session progress information has to be allowed, and has to be in a
continuous early media stream, but that other early media that occurs in the
provisional stage, regardless of whether or not it is related to session
progress (could be an advertisement or status information), should be set up
in some way that is friendlier to the realities of SIP.

> 
> Regarding how we establish early media, I agree that using a different
> offer/answer context than the original INVITE informs the UAC that this
> is another type of media. While I find this distintion conceptually
> interesting (and I agree with), I am not sure whether or not it is a
> useful distintion.

Informing the UAC that this is another type of media was not, ultimately, my
reason for suggesting the separate dialog approach, although that is
important. Justifications follow after this...

> 
> The signalling for setting up a different dialog or sending back a URL
> to be retrieved by the client is going to represent an important
> overhead. If you have to negotiate and establish QoS for this new media
> stream again it will take long... and if you are using a cellular
> terminal, it can take even longer...
> 

I think it is critical that provisional media that is not continuous with
the 'final' media of the call be optional. If you receive a 180, you know
that someone is being alerted, and any additional information about the
status of the call, while it can supplement this information, does not
supplant it. This is very different from a gateway case, say, in which the
gateway cannot express the state of the call out of band and it must send
you provisional media in order to let you know what is going on with the
call.

At least part of the problem are cases in which UASs send media before an
SDP answer has been sent (in order to prevent clipping) - this forces the
media on the UAC, and doesn't give the UAC the chance to preemptively reject
this media (which is bad in forking cases, if you were to recieve ten
provisional media streams simultaneously). This thread has also noted that
there are ambiguities that arise if you send an SDP answer but then don't
start sending media for a while (answer at 180 but don't start sending until
you have 'final' media when you would send the 200). Both of these
difficulties are resolved if we use something that a new dialog in the
backwards direction or Alert-Info.

I agree that QoS always makes continuous early media more attractive. In
fact, reserving a circuit with QoS reduces this to a very similar situation
to the one in ISUP. Before you send a IAM, you already have to pick a TCIC,
so your media resources are already reserved, so you might as well send some
media in the backwards direction if it helps with clipping. However, I think
forking and QoS have their own conflicts. One of the nice things about SIP
as a signaling protocol is that you don't have to commit any resources to
exchange some informational signaling with a destination. I think
recommending that UASs force continuous early media on UACs unnecessarily
chips away at this nice property of SIP.

> In addition to that, those mechanisms will not always work. A dialog in
> the backwards direction can be routed to a different UA that the one
> making the call.
> 

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.

> Sending a SIP URL may work, but some clients may have problems with that
> as well. Some terminals will not want to reserve resources for two
> streams at the same time.
> 

I'm not exactly sure what you mean by sending a SIP URL here... sending,
say, an HTTP URL in Alert-Info in 180, however, allows the UAC to choose for
themselves whether they would like to play this media or not - hence, they
are not required to reserve resources. I think it puts the control where it
belongs - with the UAC.

> 
> We had this same discussion some time ago and Jonathan released a draft
> analyzing several alternatives for early media. The conclusion was the
> UPDATE work. The whole idea of UPDATE is to do early media within the
> same offer/answer context as the original INVITE. If we had not intended
> to do that, something like the old COMET would have been probably enough
> for the preconditions stuff.
> 

UPDATE is a critical part of managing these forking cases in which
provisional media is returned by gateways in the original INVITE's
offer/answer context - no question. However, this in and of itself provides
no justification for using the original INVITE's offer/answer context when
alternatives that are easier to manage might be used instead. This is a
question of what UAS behavior we recommend for early media.

> 
> My opinion is that all the three approaches for porviding early media
> have pros and cons... and the conclusion may be to document the issues
> that each of them have. Depending on the scenario, one or another may be
> best.
> 

I think it is reasonable to document multiple options - I've put forward a
couple (separate dialog and Alert-Info) myself to address some of the
requirements, I don't believe we need to document only one.

However, as I remarked in the initial comments I sent on your draft, I think
that the use of continuous provisional media in the INVITE's offer/answer
context should be discouraged - my recommendation is that it be allowed only
in those cases in which gateways cannot express status information in any
other way.

So, I agree with your conclusion. We probably only disagree about what
recommendations we should make based on the documentations of the issues.

> Thoughts?
> Thanks,
> Gonzalo
_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Dec 2002 09:20:02 -0500

Peterson, Jon wrote:
> forking and QoS have their own conflicts. 

Your last statement deserves more emphasis and discussion.

If you are bandwidth limited, and your call is parallel forked, and you 
want to use QoS, it looks like you may be screwed. What is supposed to 
happen? I presume you must attempt to reserve bandwidth for all the 
forks, which in this case won't be possible. So what happens? Does the 
first reservation succeed and then all the others fail, causing you to 
reject all but one fork before any attempt is made at alerting?

	Paul

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 11 Dec 2002 11:46:19 -0800

no major disagreements with you in this message.  one difference of 
degree near the bottom....

> are not required to reserve resources. I think it puts the control 

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.

> in those cases in which gateways cannot express status information in 

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.

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.

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 11 Dec 2002 11:49:05 -0800

On Wednesday, December 11, 2002, at 06:20 AM, Paul Kyzivat wrote:

> If you are bandwidth limited, and your call is parallel forked, and 
> you want to use QoS, it looks like you may be screwed. What is 
> supposed to happen? I presume you must attempt to reserve bandwidth 
> for all the forks, which in this case won't be possible. So what 
> happens? Does the first reservation succeed and then all the others 
> fail, causing you to reject all but one fork before any attempt is 
> made at alerting?

you setup your qos so it applies to any single flow (you don't know 
which)  [for RSVP, you request a shared explicit reservation with a 
path id (you can share the reservation in both directions)].  then you 
use UPDATE to tell all but one of them to shut up.

thx,
-r

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 17 Dec 2002 15:24:53 +0200

Jon,

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

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.

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?

Gonzalo