Subject: RE: [Sipping] RE: Meaning of status codes

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 6 Dec 2002 19:27:41 -0500

inline.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Friday, December 06, 2002 2:51 PM
To: Peterson, Jon
Cc: 'Francois Audet'; 'Gonzalo Camarillo'; 'William Marshall';
[email-masked]'; [email-masked]';
[email-masked]'; 'Alan Johnston'; 'sipping'; 'Adam Roach'
Subject: Re: [Sipping] RE: Meaning of status codes

On Thursday, December 5, 2002, at 02:41 PM, Peterson, Jon wrote: 

Clipping avoidance is a separable issue from the matter at hand. What we're
discussing now is whether or not vanilla SIP UAs should use an SDP answer in
a 180 to establish an early media session that is disjointed from the media
of the call. If we can agree that this is bad, and that there are more
attractive alternatives, we will have made significant progress, I think, in
so far as we will have chosen a more narrow and practical scope for the
problem. 

That much said, I think that sending an SDP answer in a 180 for continuous
media (media that will transition to the call requested by the initial
INVITE) is also problematic. 

Why is this problematic? What breaks in the "just play it" model that is any
harder to deal with than receiving the same answer in a 183? 

<JFP> Yes, my note above was really more of an IOU than an argument - though
at least some of my argument is in the thread about forking to which you
have also responded (to which I will respond there). I have been trying to
adhere to Gonzalo's request to stay focused on one issue at a time.
Fortunately, I do think the thread about relating status codes to local
ringback is quieting down, so it probably is time to move on to clipping.
</JFP>

If I get a 180 with an answer, I will probably play local ringback until I
receive media from that answer. 

<JFP> This is in fact commensurate with what is recommended by RFC3398
today, agreed. What people seem to want to investigate here is whether some
'early media extension' would yield even better results. </JFP> 

thanks, 

-rohan 

I don't think the "just play it" philosophy is actually a panacea for
clipping. Paradoxically, the cases in which early media is used in this
fashion are actually the hardest to solve, I think, not the easiest. There
is a design trade-off built in to SIP that makes the use of early media for
this purpose inherently difficult for SIP (due to forking and related issues
about how status codes are used). This is a subject for a separate thread,
but suffice it to say that I'm not sure I find the strategy you detail below
practicable. 

Jon Peterson 

NeuStar, Inc. 

-----Original Message----- 

From: Francois Audet [mailto:[email-masked]] 

Sent: Thursday, December 05, 2002 2:21 PM 

To: 'Peterson, Jon'; 'Gonzalo Camarillo' 

Cc: 'William Marshall'; [email-masked]';
[email-masked]'; [email-masked]'; 'Alan Johnston';
'sipping'; 'Adam Roach' 

Subject: RE: Meaning of status codes 

[snip] 

While I personally don't really have a problem with this, it seems to me
that other people have (in particular for clipping avoidance). 

Perhaps the way to deal with this is the following (from the receiver of the
INVITE's point-of-view): 

•       It is OK to send an SDP in a 180 in order to avoid clipping (and
even perhaps recommended). 

•       It is not a good idea to send in-band tones/announcements after
sending a 180/SDP (although striclty speaking, legal as the calling party
has no way of distinguishing this from clipping avoidance). Other mechanism
are preferable (as described in Jon's email above): 183/SDP (with or without
a 180 sent later), the URL method, text, etc. 

From the originator of the INVITE's point of view: 

•       SDP in 180/183 means listen and play if/when media is available
(overriding any optional locally-generated tone). 

•       180 means "far-end user is being alerted", and CAN result in a local
indication (GUI display, locally-generated tone, etc.). 

This seems fairly simple and implemenatable.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 08 Dec 2002 18:08:40 +0200

Folks,

I will try to summarize all the discussions so far in this thread. 

Adam, Fracois Audet, Rohan, Jon and Gonzalo stated that if the callee is
being alerted, 180 is the right status code to use.

Alan, John Hearty and Michael Hammer said that current gateways send a
183 (even if the user is being alerted) when there is early media.
Therefore, in order to be backward compatible, they would like to avoid
using 180 with SDP.

Jon said that vanilla SIP UAs should not send early media with the same
offer/answer context of the original INVITE. He gave some alternatives
to the 18x with SDP approach. 18x with SDP would be used only by
gateways.

As I see this, we have two issues:

1) how big is the backwards compatibility problem that Alan brought up.

2) 18x with SDP for early media: is it conceptually correct for vanilla
UAs? are there technical issues?

I will send a separate note about 2).

About 1), I am not sure whether or not we face a backwards compatibility
problem. The issue is that an ingress gateway (UAC) will generate local
ringback upon reception of a 180 (even if it has SDP).

Let's suppose that we do not have early media in a particular call. A
current gateway that uses the strategy described above, will have to be
prepared to stop local ringback when the first media packets (the
"hello" from the callee) arrive, because it cannot rely on receiveing
the 200 OK first (there is a race condition).

Therefore, current gateways are already prepared to stop local ringback
if inband alerting is received (the gateway will not know if what is
being received is the "Hello" or "beep, beep...")

I do not see any issue here that keep us from sending a 180 and inband
ringing at the same time. Alan, can you elaborate on what you believe is
the problem?

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: Gonzalo Camarillo <[email-masked]>
Date: Sun, 08 Dec 2002 18:42:54 +0200

Folks,

as summarized in my previous mail, Jon questions the validity of sending
early media within the same offer/answer context as the original INVITE.
He brought up several issues, some conceptual and some technical.

Conceptual issues:

The SIP status codes already provide information about how session
establishment is progressing, so we should discourage the use of inband
information for the same purpose.

Early media that does not relate directly to call establishment (e.g.,
"Gonzalo is upstairs...", or listening to a comercial while you are
waiting for the callee to pick up) should not be part of the same
offer/answer context as the original INVITE.

Technical issue:

Forking may be difficult to handle if 18x responses with SDP are used.

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.

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

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.

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

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.

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.

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.

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.

Thoughts?

Thanks,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 08 Dec 2002 20:57:05 +0200

Hi,

A few comments inline,

> ringback upon reception of a 180 (even if it has SDP).

[CHH] I agree.

> the 200 OK first (there is a race condition).

[CHH] Forgive me if I'm wrong, but to me it sounds like you now make the
assumption that the gateway/UAC will use the RTP packets as a "trigger" to
stop generating local ringback. I don't think we have agreed on that (there
has been a number of concerns raised to that proposal), and I also think it
is a little out of scope of the specific meaning-of-status-code discussion
(you wanted to stay focused :)

> Therefore, current gateways are already prepared to stop local ringback if
> inband alerting is received (the gateway will not know if what is

[CHH] I guess a gateway is PREPARED to stop generating local ringback at any
time. But, I still think the question still is what is the TRIGGER for that.
Again, I think there has been concerned raised with the
stop-when-the-first-RTP-packet-is-received mechanism, and I think we should
treat that as a separate issue.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 09 Dec 2002 10:42:07 +0200

Hi,

I appologise if some of you already got this mail, but since it didn't show
up on the mailing list I thought something may have gone wrong when sending
it.

Anyway, I have a couple of comments (inline) on the summary.

> Therefore, in order to be backward compatible, they would like to avoid

[CHH] At this point I think there is another question we need to add to this
discussion: does the SDP/non-SDP have anything to do with the meaning of the
status code?

> to the 18x with SDP approach. 18x with SDP would be used only by

[CHH] Here I think it is important not to forget the manyfolks resrource
reservation mechanism. There was a comment that the 183 would be used "in a
wrong way there", and that can of course be discussed separately, but let's
not forget there is a scenario where the UAS (no matter what kind of SIP
node it is) will have to send 18x with SDP.

> being received is the "Hello" or "beep, beep...")

[CHH] Now I wonder what you mean by saying that "a gateway has be be
prepared to stop local ringback when the first madia packets arrive". Of
course, a media gateway has to be prepared, in the sense that SOMETHING
triggers it to stop local ringback, and one could also argue that it should
be able to receive media packets while still generating local rinback, to
avoid clipping. However, I don't think we have agreed that the media packet
as such should be a trigger to stop local ringback, have we (there has been
concerns raised about that solution proposal)?

> ringing at the same time. Alan, can you elaborate on what you believe is

[CHH] From my point of view the problem is the same as it has been from the
beginning: how does the UAC know if it should expect early media or not
(note: I didn't say there there always will be early media in this case).
Yes, we could agree that a UAS always send 180 when the called party has
been alerted (this is what I thought was supposed to be the focus of this
discussion, but it seems like we are once again trying to solve all issues
at once...), but that still doesn't mean we have solved the early media
issue. Again, I don't think we have agreed to use the detecting-of-media
mechanism to decide if to generate local ringback or not.

In any case, I'm glad you did this summary, because at least I find it very
difficult to follow the discussion, now when it once again has taken off in
different directions.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 09 Dec 2002 11:28:24 +0200

Christer,

> up on the mailing list I thought something may have gone wrong when sending

when an email with too many recipients is sent to the mailing list, I
have to approve it manually (spam prevention). A good policy to avoid
this is to limit the number of people that are cc:ed in the emails to a
small number.

Thanks,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 09 Dec 2002 14:01:17 +0200

Hi,

Comment at the end.

> for the preconditions stuff.

[CHH]  I assume that when that draft was written it was assumed that
"inactive" means there is no media sent. Now we say that one should be able
to receive media also on an "inactive" stream (to avoid clipping), so from
an offer/answer point of view there is little use in sending those messages
(I think that has been said by other people too). Of course, they can be
used to provide the UAC with the information if it should generate local
ringback or not, but I would hope we could come up with something more
simple for that single purpose.

However, in the summary mail Gonzalo also mentioned the backward compability
issue, and what impacts they may have on the solution. So, to start with I
think we should collect all information related to that, and base any
solution on that, IF we want to be backward compatible.

Having been following this discussion, having read the SIP phone requirement
draft etc, I am pretty sure that the output of a backward compatible
discussion would say something like:

"Send 180 if you don't intend to sent early media, and send 183 if you
intend to send early media".

Now, it doesn't matter how much "wrong use of SIP this is", and it doesn't
matter what has been proposed during this discussion (I may agree on many
issues, but that doesn't matter either) but the picture I've got is that
THAT is the way it works today, and anything else we do will cause "backward
compability problems". Please correct me if I'm wrong.

I've heard comments from people saying that they are not going to accept
anything which would break existing deployments. Those comments may be very
valid, but my point is that we should really collect all those facts before
starting to discuss solutions. I think that is what Gonzalo also asked for
in his summary mail, so please let's start from there.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 10 Dec 2002 11:20:27 -0800

On Tuesday, December 10, 2002, at 11:03 AM, Michael Hammer wrote:

> Gonzalo,
>
> My main issue was the possibility that a 180 with SDP could be 
> received, where the receipt of RTP packets contained dead air or 
> comfort noise rather than tones or announcements for the purpose of 
> avoiding clipping.

Mike,

While some folks might send an initial sacrifice packet to help with 
middlebox traversal, nobody I've seen sends dead air or comfort noise.  
It actually doesn't help avoid clipping, and it takes work.

thanks,
-rohan

> I don't have a problem with the idea that receipt of SDP means be 
> ready to play media upon Answer.
>
> I do have an issue with the assumption that receipt of RTP means that 
> meaningful media is present.
>
> When 180 is received, it means alerting and so long as the user is 
> alerted by visual or audio means (I don't care which, that is 
> implementation) I am fine.
>
> I am inclined to think that such alerting should continue until 
> Answer.  I do not think it wise to base that on RTP receipt.  See 
> faulty assumption above.
>
> If a SIP phone continued visual alerting and played RTP media when 
> received, that would be fine too.
>
> I have a problem with the idea that receipt of SDP or RTP abdicates 
> the signaling responsibility to signal the user thereby re-entangling 
> signaling and media.
>
> I don't think there is an issue with sending 18x with SDP in those 
> cases where the gateway has no idea what ring-back/tones/announcements 
> are in the media stream.
>
> Mike
>
>
> At 06:08 PM 12/8/2002 +0200, Gonzalo Camarillo wrote:
>> Folks,
>>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Dec 2002 22:18:22 +0200

Hi,

Comments inline.

> My main issue was the possibility that a 180 with SDP could be received,
> where the receipt of RTP packets contained dead air or comfort noise rather
> than tones or announcements for the purpose of avoiding clipping.
>
> I don't have a problem with the idea that receipt of SDP means be ready to
> play media upon Answer.

[CHH] I have a comment on this at the end of the mail.

> meaningful media is present.

[CHH] Agree.

> When 180 is received, it means alerting and so long as the user is alerted
> by visual or audio means (I don't care which, that is implementation) I am
> fine.
>
> I am inclined to think that such alerting should continue until Answer.  I
> do not think it wise to base that on RTP receipt.  See faulty assumption above.

[CHH] Agree. And, if not until answer, then at least until some kind of other
signalling event (whatever that may be).

In forking scenarios, we MAY want to choose to pass media only from one remote
destination, and I don't want to assume that the media handler does that decission
on it's own. The signalling controller may want to do the decission which stream to
be based based on signalling (whether it's a received SDP, a specifc status code,
or whatever), and that is the reason I think we should have indications on the
signalling level - and not make decissions simply based on received RTP packets.
There may also be security reasons why the signalling controller wants to decide
which stream is passed.

> received, that would be fine too.

[CHH] I don't think the biggest problem is if we have visual and audio alerting at
the same time, but when we receive remote audio and at the same time generate local
ringback.

> I have a problem with the idea that receipt of SDP or RTP abdicates the
> signaling responsibility to signal the user thereby re-entangling signaling
> and media.

[CHH] Agree.

> I don't think there is an issue with sending 18x with SDP in those cases
> where the gateway has no idea what ring-back/tones/announcements are in the
> media stream.

[CHH] IF we would use SDP as an indicator that there may be remote early media we
should have a look how scenarios (including the manyfolks resource reservation)
mandating SDP in specific messages, no matter if there is early media or not,
affects that solution. In other words, do we look at the SDP, or specific SDP
parameters? If we do, for example, look at the media mode indicator we will again
bring up the issues with clipping, the meaning of "inactive", extra UPDATE
transactions etc etc.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Michael Hammer <[email-masked]>
Date: Tue, 10 Dec 2002 15:42:37 -0500

At 11:20 AM 12/10/2002 -0800, Rohan Mahy wrote:

>>where the receipt of RTP packets contained dead air or comfort noise 
>>rather than tones or announcements for the purpose of avoiding clipping.
>
>Mike,
>

I only wanted to sum up the extent of my concern.  I believe the inclusion 
of requirement statements that this should not happen would make my concern 
go away and thus a moot point.

Mike

>>I don't have a problem with the idea that receipt of SDP means be ready 
>>to play media upon Answer.
>>
>>Answer.  I do not think it wise to base that on RTP receipt.  See faulty 
>>assumption above.
>>
>>signaling responsibility to signal the user thereby re-entangling 
>>signaling and media.
>>
>>where the gateway has no idea what ring-back/tones/announcements are in 
>>the media stream.
>>
>>Mike
>>
>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 11 Dec 2002 20:51:25 +0200

Hi Mike,

I believe we are in agreement. If you have received a 180 Ringing, your
GUI should be in the alerting state, regardless of the media status.

Then, if somebody uses ringback tones instead of visual alerting and
wants to mix local alerting with the early media received or wants to
give priority to one of them, is up to the local policy of that device.

Thanks,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~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: Michael Hammer <[email-masked]>
Date: Tue, 10 Dec 2002 14:03:07 -0500

Gonzalo,

Mike