Subject: RE: [Sipping] Meaning of status codes

From: "Hearty, John" <[email-masked]>
Date: Thu, 5 Dec 2002 09:44:08 -0700

I think it's important to consider what most applications typically are doing today, which is generating some kind of local ringing when a 180 without an answer is received.  Seems coupled to me, and seems to work pretty well in many cases.

John Hearty
Level3

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Thursday, December 05, 2002 12:33 AM
> To: Francois Audet
> Cc: 'William Marshall'; [email-masked]';
> [email-masked]'; [email-masked]';
> [email-masked]'; 'Alan Johnston'; sipping; Adam Roach
> Subject: [Sipping] Meaning of status codes
> 
> 
> Folks,
> 
> we have had some private mail exchanges regarding the early 
> media draft
> about the meaning of the status codes. 
> 
> I maintain that the information of any status code is completely
> orthogonal to the status of the media session. That is, the 
> status code
> does not tell you anything about the media session. It does 
> not tell you
> that you will have media and it does not tell you that you 
> will not have
> media either. Those are offer/answer issues. NOthing to do with the
> status code.
> 
> Therefore, if a UA received a 180 Ringing response, all the 
> UA knows is
> that the other party is being alerted. Nothing about who will generate
> the ringback tone (this info will be in the offer/answer).
> 
> And I believe that my view is consistent with the SIP way of doing
> things. However, some folks believe that I am wrong, and that 
> the status
> codes give you information about the media session, as you can see
> below:
> 
> > Gonzallo, it seems that Bill, Alan, Jon and myself all 
> share the view
> > that
> > it is consistent with 3261 (and sip-isup-06) to couple 180 with
> > locally
> > generated ringback.
> 
> Just as a clarification, the text above refers to a MAY in 
> the SIP spec
> when defining 180. IMO, that MAY is correct.
> 
> I would like to get more opinions on this. What do people think about
> this?
> 
> 1) Status codes and media are two different things
> 2) Status codes and media have to be coupled
> 
> 
> And please, try to answer the question I am asking. Every 
> time we tackle
> something that is somehow related to the PSTN we end up with endless
> threads that miss focus easily. Let's try to avoid that.
> 
> As I stated previously, I believe 1) is the way to go.
> 
> Thank you,
> 
> 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
> 
_______________________________________________
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: William Marshall <[email-masked]>
Date: Thu, 5 Dec 2002 12:23:55 -0500 (EST)

(I've lost track of who said what):
> > However, as I said above, early media
> > through gateways (the problem we are considering) is a case in which the
> > media stream is used to describe the status of the call.  This is not a
> > 'normal' SIP condition - native SIP should never do this. This is an
> > aberrant condition that occurs only in gateway interworking.
> 
> I believe that we are almost in agreement about everything but this
> part. You believe that a vanilla SIP UAS will never send early media
> with a 180, and I believe it MAY.
> 

After a vanilla SIP UAS sends a 200 (after sending a 180), the UAC may
(and in many cases likely will) see the media before it sees the 200.
To avoid clipping te first part of the "hello", the UAC should 
preempt the local ringback and play the media.

So from the UAC point of view, it doesn't really know whether this media
is "early media" or not.  It shouldn't matter.  Just play it.

Bill Marshall
[email-masked]

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 5 Dec 2002 11:57:15 -0800

> media draft about the meaning of the status codes. 
> 
> I maintain that the information of any status code is 
> completely orthogonal to the status of the media session. 
> That is, the status code does not tell you anything about the 
> media session. It does not tell you that you will have media 
> and it does not tell you that you will not have media either. 
> Those are offer/answer issues. NOthing to do with the status code.
> 
> UA knows is that the other party is being alerted. Nothing 
> about who will generate the ringback tone (this info will be 
> in the offer/answer).

No! There is nothing in the offer/answer that means that there
is in-band ringback tone. An a=sendrecv simply means that there
might be some early media.

The simplest case is the following:

SIP phone A calls SIP phone B. 

B is being alerted, so it sends a 180 back to A. Also, in order
to have the fastest cut-through for the answer and avoid clipping,
it includes its SDP (with a=sendrecv) in 180. Since it is a modern
SIP phone, it does not provide in-band ringing.

A, upon receiving the 180 provides an indication that user B is
being alerted. 

A graphical terminal might display the indication. I don't think
anybody disagrees with this.

A simple audio-only device (i.e., a pots-like SIP phone) may (I would
say should, if it is a pots-like phone) provide an audible ringing 
indication (i.e., locally-generated ringback).

If an audio stream is being received on the wire, then it should override
any locally-generated ringback tone. That will avoid clipping (and it will
also mean that the user on Phone A will hear any ringing pattern that
MIGHT be provided by Phone B (or more realistically, Gateway B to the 
PSTN).

> And I believe that my view is consistent with the SIP way of 
> doing things. However, some folks believe that I am wrong, 
> and that the status codes give you information about the 
> media session, as you can see
> below:
> 
> > that it is consistent with 3261 (and sip-isup-06) to couple 180 with
> > locally
> > generated ringback.
> 
> the SIP spec when defining 180. IMO, that MAY is correct.
> 
> I would like to get more opinions on this. What do people 
> think about this?
> 

Satus code and RTP media are 2 different things.

Locally-generated audible indication (in a pots-like phone for example)
can be triggered by a status code. 

> 2) Status codes and media have to be coupled

Status code and RTP media are NOT coupled.

A typical pots-like SIP phone may choose to couple locally-generated audible
indication with a status code.

In-band RTP media and locally-generated audible indications are 2 different
things

In-band RTP media is loosely coupled with the SDP (and a=sendrecv tag).
There is no
timing synchronization between the two, and even if a stream is in sendrecv
mode, it
doesn't mean that there is actual media flowing all the time.

Locally-generated audible indications are a matter of local policy and CAN
be
triggered by status codes (such as 180).

Locally-generated audible indications such as ringback can not really be
triggered 
by SDP (and a=sendrecv tags) because the coupling with media is too loose to
be
reliable.

As a matter of local policy, a SIP phone needs to decide what to do when
both the
locally-generated audible indication and the audible RTP media stream are
competing
for the same speaker. It is recommended that the the RTP media stream take
precedence
in order to avoid clipping.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 5 Dec 2002 15:06:07 -0500

Right. We talk about this extensively in sipping-isup-06. If the "called
party free" BCI indicators are present, then 180 Ringing is perfectly
reasonable. If there are certain other values, then the gateway has no
concept of the status of the call. This is the hard case, and the one from
which I am currently arguing.

Jon Peterson
NeuStar, Inc.

> From: Adam Roach [mailto:[email-masked]]
> Sent: Thursday, December 05, 2002 9:03 AM
> To: 'Peterson, Jon'; 'Gonzalo Camarillo'
> Cc: Francois Audet; 'William Marshall'; [email-masked]';
> [email-masked]'; [email-masked]'; 'Alan
> Johnston'; sipping; Adam Roach
> Subject: RE: Meaning of status codes
> 
> 
> > From: Peterson, Jon [mailto:[email-masked]]
> >
> > A gateway that relays in-band status information from
> > the PSTN in a media stream has no way of knowing wha
> > the status of the call is...
> 
> I think this may be the fundamental point of contention.
> 
> I'll admit that the passage of time has left me with only 
> a modest memory of the way ISUP works, but I have this
> nagging recollection of a "called party free" flag in
> the ACM message, which semantically indicates whether the
> called party is being alerted.
> 
> Right?
> 
> /a
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 5 Dec 2002 12:12:10 -0800

Jon Peterson:
> Actually, this question isn't the issue you described above. 
> That question would be:
> 
> 1) Status codes and locally-generated ringback are two 
> different things
> 2) Status codes and locally-generated ringback have to be coupled
> 
> The relationship between media and locally-generated ringback 
> is at the core of this issue, but the two are hardly identical.

Right, this is also what I am saying in my previous mail.

> It does seem obviously mistaken to me to use a 180 Ringing 
> status code (even with an SDP answer) to communicate the 
> presence of early media when that media could contain a busy 
> signal. Imagine a UAC with a graphical interface that reads 
> "Ringing" when a busy tone is playing over the audio channel. 
> 183 is neutral as to the state of the call - it doesn't 
> suggest that the end-user is being alerted. I therefore think 
> it is much better suited to the early media case.

Agreed. That would definitively be wrong.

The only time one should use a 180 is when you are really sure
that the far-end is being alerted. 

The corner case is when the terminating end knows that you IN-BAND
RINGBACK is being played and it also know that the user is being ALERTED.

One implementation could choose to send a 183/SDP and drop the logical
alerting indication.  That way it forces the calling side to listen
to the inband tone. Of course, by doing so, it gets rid of the logical
alerting indication (which could mean that the GUI would not have
the alerting indication).

Another (perhaps better) implementation could choose to send a 180/SDP
instead.
By doing so, it keeps the logical indication (good for a GUI). If the
calling 
UA is a SIP pots-like, it may be able to play a locally-generated
tone based on the 180, and override it by any incoming RTP audio media that
come (i.e., it can come as part of early media as in-band ringing, or it
can come a bit later as the "hello" answer). If the phone is a really cheap
device, it may even choose not to override the locally generated audible
indication
and only cut-through at 200 OK (not advisable, but certainly allowed). Or it
overlap the
audio (also probably not advisable, but certainly allowed).

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 5 Dec 2002 12:19:16 -0800

> I disagree with this. I want my UAS to send you a 180 Ringing 
> and at the same time play (early) media saying "Today Gonzalo 
> is upstairs repairing the ceiling, it may take a little 
> longer than usual for him to come down to pick up the phone. 
> Please be patient. I am already alerting him". I believe that 
> this should be possible even in a SIP to SIP (i.e., no
> gateways) scenario.

I agree. 

That case is taken care of in the example of my previous email.

Alternatively you could send a 183/SDP first and then send a 180 at the
end of the announcement.

> > The text in sipping-isup-06 started from the assumption that when a 
> > 180 is sent, a UAC might start to generate local ringback - in the 
> > case I described above, where a native SIP phone UAS sends 
> a 180 with 
> > no media
> 
> This is where our assumptions differ. I believe that a 
> vanilla SIP UAS may send early media and a 180 Ringing (the 
> example above) at the same time.

Careful, there are two cases and you are both right for one of them:

1- It is OK to send a 180 with SDP if you know that the user is being
ALERTED
2- It is not OK to send a 180 with SDP if you don't know that the user is
being ALERTED (i.e.,
   he could be busy)

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 5 Dec 2002 16:05:25 -0500

I think Mr. Camarillo is talking about something else in the passage below,
a case in which there is some disjointed media (media unrelated to the call,
like an announcement or service message) that is played before the actual
media for the call is cut-through. While your scenario is also valid, I
think we need to consider these two scenarios separately. He's talking about
a case where some disjointed media (not the callee answering the phone) is
sent before any audio media from the actual callee - your case is where
media from the callee arrives before the 200 OK.

Jon Peterson
NeuStar, Inc.

> From: William Marshall [mailto:[email-masked]]
> Sent: Thursday, December 05, 2002 9:24 AM
> To: [email-masked]
> Subject: [Sipping] Re: Meaning of status codes
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 5 Dec 2002 13:49:30 -0800

> Okay, so what you have just called reasonable points to an 
> agreement with the statement that Gonzalo used to start this 
> thread. To rephrase:
> 
> "The 180 status code does not necessarily indicate locally 
> generated ringback. Early media (i.e. in-band ringtone) *can* 
> be sent subsequent to an offer/answer exchange performed with a 180."
> 
> Do you agree?

Agree, although the wording is a little off. Early media does NOT mean
early ringback. But in-band ringback does imply early media.

I would rephrase it as follows:

"The 180 status code does not necessarily indicate that the user
shall be provided with locally-generated ringback. In-band ringback
can also be sent as early media subsequent to an offer/answer exchange
performed with a 180 or 183."

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 5 Dec 2002 16:54:00 -0500

Some notes below on alternative ways to send provisional media from a UAS
with a 180.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Thursday, December 05, 2002 12:19 PM
To: 'Gonzalo Camarillo'; 'Peterson, Jon'
Cc: 'William Marshall'; [email-masked]';
[email-masked]'; [email-masked]'; 'Alan Johnston';
'sipping'; 'Adam Roach'
Subject: RE: Meaning of status codes

[snip]

<JFP> Actually, I think we need to think more about scenario (1). I think we
need to ask ourselves why we need this capability in the UAS.

If the UAS knows the callee is being alerted, then we agree that 180 should
be sent. But sending SDP, and presumably some provisional media, requires
further consideration.

If you have some provisional status information above and beyond the fact
that the callee is being alerted, there are other ways that you can send
this information than by answering the offer in the 180 and beginning to
transmit media. A few alternatives come to mind:

- Setting up a new dialog in the backwards direction to the caller. This
method is especially useful because it allows third party devices (operated
by service providers or advertisement servers, which seem to play a large
part in motivating these use cases) to make their own offer to the caller.
Accepting the offer in the original INVITE restricts the provisional media
to media controlled directly by the UAS.

- Sending back some sort of URL in the backwards where the caller can
download more status information. For example, the Alert-Info header can
appear in a 180 response, where it designates an 'alternate ringback' that
should be played by the caller. This could in fact by an audio message
("Gonzalo is upstairs...") or any other relevant information. I think this
should cover most such cases, and frankly, I think this is the most SIP-like
option. This has the important property that the acquisition of the
provisional media is left up to the UAC - when the UAS answers the offer in
180 and begins transmitting media, it is really cramming this media down the
UAC's throat (even though the UAC already knows the callee is being alerted
from the status code, so this media is at best 'optional'), which is bad in
forking cases.

- Sending a textual message in the backwards direction. This can be
accomplished in any number of ways (extra text/plain MIME body with
'render', etc).

The point is, a SIP UAS that sends a 180 and knows that the callee is being
alerted has numerous alternatives, if it wishes to send provisional media,
to answering the SDP offer in 180. Answering the SDP offer creates known
difficulties (especially in forking cases) for provisional media. A gateway
has no choice but to do this when it does not know the status of the call -
that is one of the two or three big pieces of the early media problem. 

I think the first step towards making progress on this issue is to
acknowledge that answering an SDP offer in a 180 is problematic, and that
normal SIP UASs SHOULD NOT do so - they have numerous other ways of sending
provisional media that do not incur problems with forking, et al.  We must
then acknowledge that there are cases in which gateways have no alternative,
effectively, and we must then figure out how to deal with that. This is a
scope issue - I think that normal UASs sending provisional media should not
be in the scope of our current considerations. I think we should restrict
our current considerations to gateway interaction, and separately
investigate the best way (of the options above and anything else along those
lines) for a SIP UAS to communicate provisional media when it does know the
status of the call.

</JFP>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 5 Dec 2002 17:04:06 -0500

I didn't mean to suggest that I was endorsing an SDP answer in 180. As I
just wrote in a much longer message, I think there are reasons to be
skeptical that SDP answer in 180 is the right way to signal a desire for
provisional media when the UAS knows that the callee is being alerted. In
gateway interaction cases, this may be inevitable, but I think this is a
special case, and we should be very cautious about recommending it for
everyday SIP use.

Jon Peterson
NeuStar, Inc.

> Sent: Thursday, December 05, 2002 1:42 PM
> To: 'Peterson, Jon'; Adam Roach; 'Gonzalo Camarillo'
> Johnston'; sipping
> Okay, so what you have just called reasonable points to an agreement
> with the statement that Gonzalo used to start this thread. To 
> rephrase:
> 
> "The 180 status code does not necessarily indicate locally generated
> ringback. Early media (i.e. in-band ringtone) *can* be sent subsequent
> to an offer/answer exchange performed with a 180."
> 
> Do you agree?
> 
> /a
> 
> > Sent: Thursday, December 05, 2002 14:06
> > To: 'Adam Roach'; 'Gonzalo Camarillo'
> > Johnston'; sipping

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 5 Dec 2002 17:08:01 -0500

Alan's interpretation of the RFC3261 text on 180 (the MAY for the generation
of local ringback) is also how I have always interpreted that passage -  as
a statement that a UAC might not have an interface that favors the
generation of local ringback, not as a statement that the UAC might not want
to notify the caller that the remote side is being alerted.

Jon Peterson
NeuStar, Inc.

> From: Alan Johnston [mailto:[email-masked]]
> Sent: Thursday, December 05, 2002 7:49 AM
> To: Gonzalo Camarillo; Francois Audet
> [email-masked]'; sipping; Adam Roach
> Subject: Re: Meaning of status codes
> 
> 
[snip]
> >
> >Just as a clarification, the text above refers to a MAY in the SIP spec
> I wrote this text in 3261, and it is a MAY because the UA might not have 
> audio capabilities.  For example, sending an INVITE to setup a instant 
> messaging session, the client receiving a 180 Ringing would not play 
> ringback, instead it would flash a message or pop up a 
> window, for example.
> 
> The MAY does not mean that the calling UA MAY ignore the meaning of the
180 
> ringing.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 5 Dec 2002 14:21:15 -0800

This is the case that was illustrated in the call flow of the previous
email. 

This is certainly an interesting option. And probably better when the
in-band notification is viewed as optional (like the "I am upstairs" thing).

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: "Francois Audet" <[email-masked]>
Date: Thu, 5 Dec 2002 14:33:41 -0800

This is also my interpretation.

> Alan's interpretation of the RFC3261 text on 180 (the MAY for 
> the generation of local ringback) is also how I have always 
> interpreted that passage -  as a statement that a UAC might 
> not have an interface that favors the generation of local 
> ringback, not as a statement that the UAC might not want to 
> notify the caller that the remote side is being alerted.

---

From: William Marshall <[email-masked]>
Date: Thu, 5 Dec 2002 17:40:13 -0500 (EST)

Jon,

> media from the callee arrives before the 200 OK.

Agree completely that they are different scenarios.  But I think
there is an advantage to considering them together.

If we drop Gonzalo's request for "focus" for a moment, and look at a
slightly different and fuzzier problem --

One of the practical aspects of the UAC is how it needs to react to 
receipt of media prior to the 200-OK.  My claim is that it doesn't 
know what is happening, and that is an advantage to us.  Just thinking
in terms of keeping the UAC simple and predictable....

If the UAC needs to play received media (after a 180) to avoid clipping,
and if the UAC needs to play received media (after any 1xx) to avoid
clipping, then this fact goes a long way toward solving lots of other
early media problems.  
  In-band ringback - whether preceeded by a 183 or a 180, will still
play the in-band ringback (although possibly with an initial locally-
generated ringback from the 180, which is not real nice)
  Announcement prior to ringback - 183 then send media then send 180
(although the timing of sending the 180 is not simple) will handle
the "I'm insulating the attic right now" message.
  Mid-ring announcement - 180, delay - send the announcement - then
another 180.

But in restoring (my) focus --- just don't clip.

Bill Marshall
[email-masked]

-----original message-----
From: "Peterson, Jon" <[email-masked]>
To: "'William Marshall'" <[email-masked]>, [email-masked]
Subject: RE: [Sipping] Re: Meaning of status codes
Date: Thu, 5 Dec 2002 16:05:25 -0500 

Jon Peterson
NeuStar, Inc.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 05 Dec 2002 17:37:52 -0500

Jon,

An obvious answer to the question of a gateway that gets an indication of 
inband ringback on the PSTN side is to send the SDP with a 183 rather than 
a 180.  That way you avoid the 180 with SDP case and support a common case 
in PSTN networks.  Is there any need to have an additional signal 
indication that alerting is occuring inband?

Mike

At 04:54 PM 12/5/2002 -0500, Peterson, Jon wrote:
><JFP> Actually, I think we need to think more about scenario (1). I think 
>we need to ask ourselves why we need this capability in the UAS.
>If the UAS knows the callee is being alerted, then we agree that 180 
>should be sent. But sending SDP, and presumably some provisional media, 
>requires further consideration.
>method is especially useful because it allows third party devices 
>(operated by service providers or advertisement servers, which seem to 
>play a large part in motivating these use cases) to make their own offer 
>to the caller. Accepting the offer in the original INVITE restricts the 
>provisional media to media controlled directly by the UAS.
>should cover most such cases, and frankly, I think this is the most 
>SIP-like option. This has the important property that the acquisition of 
>the provisional media is left up to the UAC - when the UAS answers the 
>offer in 180 and begins transmitting media, it is really cramming this 
>media down the UAC's throat (even though the UAC already knows the callee 
>is being alerted from the status code, so this media is at best 
>'optional'), which is bad in forking cases.
>The point is, a SIP UAS that sends a 180 and knows that the callee is 
>being alerted has numerous alternatives, if it wishes to send provisional 
>media, to answering the SDP offer in 180. Answering the SDP offer creates 
>known difficulties (especially in forking cases) for provisional media. A 
>gateway has no choice but to do this when it does not know the status of 
>the call - that is one of the two or three big pieces of the early media 
>problem.
>normal SIP UASs SHOULD NOT do so - they have numerous other ways of 
>sending provisional media that do not incur problems with forking, et 
>al.  We must then acknowledge that there are cases in which gateways have 
>no alternative, effectively, and we must then figure out how to deal with 
>that. This is a scope issue - I think that normal UASs sending provisional 
>media should not be in the scope of our current considerations. I think we 
>should restrict our current considerations to gateway interaction, and 
>separately investigate the best way (of the options above and anything 
>else along those lines) for a SIP UAS to communicate provisional media 
>when it does know the status of the call.
></JFP>

---

From: Michael Hammer <[email-masked]>
Date: Thu, 05 Dec 2002 17:43:04 -0500

If 180 with SDP is necessary to avoid clipping, then some sort of explicit 
signaling indication of "suppress local audio alerting 'cause its inband" 
might be useful.  That way the downstream node can give some guidance to 
the upstream node as to where the ringback should come from.

Mike

At 02:21 PM 12/5/2002 -0800, Francois Audet wrote:
>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 
>    * It is not a good idea to send in-band tones/announcements after 
> 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.
>    * SDP in 180/183 means listen and play if/when media is available 
>    * 180 means "far-end user is being alerted", and CAN result in a local

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 5 Dec 2002 14:51:56 -0800

> indication that alerting is occuring inband?

In the PSTN, there are cases where both in-band tones
and an explicit indication are provided. 

An ALERTING message with a Progress indicator of #1 or #8 means
"user is being alerted, and in-band tones are present". This is
fairly common.

There might thus be a loss of information if there is a double mapping.

---ALERTING PI=1 or 8----->
                           -----183---------->
                                              ---PROGRESS PI=1 or 8----->

Apparently this may result in loss of functionality for certain services
(because certain services will behave differently when it is known that
the user is being alerted).

There is an equivalent in ISUP, but I am not an expert.

Regardless of PSTN interworking, I agree with Adam that if we know that the
user is being alerted a 180 should be sent.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 5 Dec 2002 16:34:27 -0800

> the upstream node as to where the ringback should come from.

That's the way it works in PSTN...

I agree it could be useful, but it is probably not required. As a 
gateway providing both 180 and in-band ringing, I probably don't care
if the far end is using in-band or out-of-band alerting. As long as
it is alerting. Getting both shouldn't be a problem.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 5 Dec 2002 16:24:25 -0800

> OK, lets assume your call flow, and that A wants to generate local 
> ringback after a 180 if there is nothing to play from the negotiated 
> media stream.
> 
> Lets further assume that B, after sending the 180, doesn't want to 
> generate ringback, and in fact doesn't want to send anything until it 
> sends the 200.
> 
> Based on your callflow, there is no offer/answer exchange 
> initiated at 
> (5), so the media stream is still open. Presumably B must send RTCP 
> packets, but won't be sending any RTP packets. How is A to decide 
> whether the absence of RTP packets is merely an indication of 
> intentional silence after earlier speach, which should 
> suppress locally 
> generated ringback, or an indication that there is no longer 
> an intent 
> to send, where enabling the ringback is appropriate?

You could send another UPDATE to turn it off explicitely if you are really
paranoid about it. I guess one could argue that it could just notice that
there is no media (silence will result in silence packets being sent: in
this
case there is no silence packet).

I would tend to agree with you that my flow works better with the in-band
ringing. If you want to do local ringing, it might be better to add the
UPDATE
before the 180 to kill the stream (or place it in recvonly).

As long  as it applies only to the annoucement-turned-out-of-band, I don't
have
a problem with this.

What I do not want to see is a bunch of UPDATEs and offer/answer for a plain
call 
with in-band ringing or .

Maybe we are on to something here.  Perhaps the draft should show flows for

1) In-band announcement followed by in-band ringing (like the one I have
below).

2) In-band annoucement followed by out-of-band alerting (i.e., with the
extra
   UPDATE), which would then look very similar to Gonzallo's Figure 2)

3) Anti-clipping 180 (and 183). The simple case. No UPDATEs required.

> (This is different than the case of media that simply precedes a 200, 
> where the first appearance of RTCP packets is concurrent with 
> the early 
> speech.)
> 
> 	Paul
> 
> Francois Audet wrote:
> > 
> >  > I think Mr. Camarillo is talking about something else in the  > 
> > passage below, a case in which there is some disjointed media  > 
> > (media unrelated to the call, like an announcement or service  > 
> > message) that is played before the actual media for the call  > is 
> > cut-through. While your scenario is also valid, I think we  
> > need to 
> > consider these two scenarios separately. He's talking  > 
> about a case 
> > where some disjointed media (not the callee  > answering 
> the phone) is 
> > sent before any audio media from the  > actual callee - 
> your case is 
> > where media from the callee  > arrives before the 200 OK.
> > 
> > Right, this is a good suggestion (to document separately the 
> > disjointed media versus the not-disjointed media). 
> Gonzallo's Figure 1 
> > ane 2 are more looking into the disjointed media case, 
> while the ones 
> > that Bill and I wrote were for the non-disjointed case.
> > 
> > I would think that the disjointed media case could look like this 
> > (which is as per RFC 3311). I'm assuming SDP B is for the 
> announcement 
> > is SDP B' is for the answerer.
> > 
> >           A                                            B    
>              
> >                                                             
>              
> >           |                                            |    
>              
> >           |---------------(1) INVITE    -------------->|    
>              
> >           |                   SDP A, a=sendrecv        |    
>              
> >           |<------(2) 183 Session Progress-------------|    
>              
> >           |           SDP B, a=sendrecv                |    
>              
> >           |-----------------(3) PRACK----------------->|    
>              
> >           |                                            |    
>              
> >           |<-----------(4) 200 OK (PRACK)--------------|    
>              
> >           |  *                                         |    
>              
> >           | ****************************************** |    
>              
> >           |*     User B will be with you shortly     * |    
>              
> >           | ****************************************** |    
>              
> >           |  *                                         |    
>              
> >           |<------------(5) 180 Ringing----------------| 
> >           |  *                                         |    
>              
> >           | ****************************************** |    
>              
> >           |*     OPTIONAL INBAND RINGBACK            * |    
>              
> >           | ****************************************** |    
>              
> >           |  *                                         
> > |                                
> >           |-----------------(6) PRACK----------------->|    
>              
> >           |                                            |    
>              
> >           |<-----------(7) 200 OK (PRACK)--------------|    
>              
> >           |                                            |    
>              
> >           |<--------------(8) UPDATE    ---------------|    
>              
> >           |                   SDP B', a=sendrecv       |    
>              
> >           |                                            
> > |                      
> >           |------------(10) 200 OK (UPDATE)----------->|   
> >           |                   SDP A, a=sendrecv        |    
>          
> >           |                                            |
> >           |<-----------(11) 200 OK (INVITE)------------|    
>              
> >           |                                            
> > |                         
> >           |-----------------(9) ACK------------------->|    
>              
> >           |                                            |
> >           |  *                                      *  |    
>              
> >           | ****************************************** |    
>              
> >           |*        Bi-directional conversation       *|    
>              
> >           | ****************************************** |    
>              
> >           |  *                                      *  |    
>              
> >           |                                            |    
>              
> > 
> > Note that in this flow, there might be in-band ringing 
> provided after
> > the message
> > or not. This is independent of the sending of 180. A can 
> play locally 
> > generated
> > tones if there is no in-band ringback received (or not if 
> it doesn't 
> > need it because for
> > example it is a terminal with a GUI). It doesn't influence 
> the call flow 
> > which is
> > independent from the presence of media.
> > 
> > The main difference with Gonzallo's proposal is that it doesn't 
> > attempt
> > to explicitely tell the
> > other end of turning off-and-on the media flow based on 
> > a=inactive/sendonly tags.
> > 
> > Does this make any sense?
> > 
> 
>

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 5 Dec 2002 18:00:19 -0800

The only solution that actually works is to only send media after
receiving the 200 (sender) and the ACK (receiver). All the other
solutions are based on the desire to overload the SIP session
establishment message with some other function, e.g. map to ISUP or map
to accounting events. I believe such mapping is fundamentally
impossible.

> Sent: Thursday, December 05, 2002 5:16 PM
> To: 'William Marshall'
> Cc: [email-masked]
> While I think I understand your analysis below, I think it is to a
large
> degree undermined by the fact that SIP requests can fork, and that
> multiple
> UASs may wish to share early media with an end-user. I've brought up
this
> point several times now in connection with your "just play it"
philosophy.
> If four UASs send media to the UAC, how does "just play it" help us
with
> clipping? UACs have no way to know which one of these UASs may,
> eventually,
> answer and begin sending 'real' media from the callee. So which media
> stream(s) are rendered to the user in order to prevent clipping? What
if
> some of these media streams containing ringing, some busy signal, some
> announcements, and the gateway cannot differentiate between these?
Once we
> have to take this into account, there is no longer such a simple
answer to
> the problem. And I'm afraid we do have to take this into account. The
PSTN
> can make the facilitating assumption that only one destination is
reached
> by
> the call - SIP cannot make that assumption.
> 
> This is why what looks like the easiest case (naive use of provisional
> media
> with in-band ringback to prevent clipping) is actually the one of the
> hardest.
> 
> In any event, it isn't clear to me why we should conflate continuous
and
> disjointed media based on your analysis below. I maintain that the
> distinction between the two is valuable. The "just play it" philosophy
> doesn't help with the fact that disjointed media requirement that an
> entity
> other than a UAS that is a target of the call can source the media.
> Continuous media (provisional media that transitions seamlessly into
> 'final'
> media) should always be an exception case that is only caused by
> interworking. Disjointed media should be a normal part of SIP, and
should
> be
> handled with the tools best suited to its needs (which does not mean
180
> with SDP, I suspect).
> > Sent: Thursday, December 05, 2002 2:40 PM
> > To: [email-masked]
> > Cc: [email-masked]

---

From: William Marshall <[email-masked]>
Date: Fri, 6 Dec 2002 08:53:39 -0500 (EST)

> solutions ....

I think you are right in the specific case when the offer is contained
in the 200-OK and the answer in contained in the ACK.  Then media can
only start at the time you specify above.

But when the offer/answer exchange occurs earlier in the session 
establishment, media can start as soon as the offer/answer completes.
That is the whole point of decoupling the media state from the 
session state.

Waiting for the ACK will likely clip the "Hello", which is one of my
big annoyances.

Bill Marshall
[email-masked]

-----original message-----
Subject: RE: [Sipping] Re: Meaning of status codes
Date: Thu, 5 Dec 2002 18:00:19 -0800
From: "Christian Huitema" <[email-masked]>
To: "Peterson, Jon" <[email-masked]>,
        "William Marshall" <[email-masked]>
Cc: <[email-masked]>

large
this
philosophy.
with
if
Once we
answer to
PSTN
reached
and
should
180

---

From: William Marshall <[email-masked]>
Date: Fri, 6 Dec 2002 09:18:33 -0500 (EST)

Jon,

> While I think I understand your analysis below, I think it is to a large
> degree undermined by the fact that SIP requests can fork, and that multiple
> UASs may wish to share early media with an end-user. 

In theory it is certainly true.  A SIP proxy that recognizes the destination
to be a PSTN endpoint can fork and send the request to six separate 
gateways - one of which will return 183 with inband ringback, two
will return a 200-OK when the voicemail server answers, and three will
return a 183 with inband fast-busy tone.  So the UAC has to choose
between inband ringback and inband fast-busy, until it receives the
200-OK and plays the voicemail greeting.  It would be nice if it
didn't have to make that choice.

But seriously, I wonder if this is a real problem.  Forking a request
to both a user's UAS and to a voicemail server is not likely to ever
connect to the user, so the proxy needs to sequentially do this forking.
Forking a request to multiple UASs leads to a pickup race, and which
one wins is somewhat irrelevent.  At worst, the UAC discovers there
was a race.

So I think the simple-minded "just play it", when there are multiple
choices, works fine in all practical cases with a "just pick one".
It would take a very complex UAC to analyze all the multiple streams
(when there are multiple streams) and merge the relevant ones, or to
use different windows/speakers for each; I don't think the gain is 
worth the complexity.

> In any event, it isn't clear to me why we should conflate continuous and
> disjointed media based on your analysis below. 

As I understand your distinction between continuous and disjointed, my
point was that solving the problem for continuous (which is necessary
to interwork) goes a long way toward a solution for disjointed as well,
which fact we can use to keep the UAC algorithms simple.

> Continuous media (provisional media that transitions seamlessly into 'final'
> interworking. 

And here I'm confused.  "Final" media can overtake the 200-OK and appear
to the UAC as "provisional" media.  We have to treat that as a normal case,
not an exception that is only caused by interworking.  I'll agree though
that true "provisional" media, like inband ringback, should only be
caused by interworking.  But the distinction is lost at the UAC.

Bill Marshall
[email-masked]

-----original message-----
From: "Peterson, Jon" <[email-masked]>
To: "'William Marshall'" <[email-masked]>
Cc: [email-masked]
Subject: RE: [Sipping] Re: Meaning of status codes
Date: Thu, 5 Dec 2002 20:16:24 -0500 

While I think I understand your analysis below, I think it is to a large
degree undermined by the fact that SIP requests can fork, and that multiple
UASs may wish to share early media with an end-user. I've brought up this
point several times now in connection with your "just play it" philosophy.
If four UASs send media to the UAC, how does "just play it" help us with
clipping? UACs have no way to know which one of these UASs may, eventually,
answer and begin sending 'real' media from the callee. So which media
stream(s) are rendered to the user in order to prevent clipping? What if
some of these media streams containing ringing, some busy signal, some
announcements, and the gateway cannot differentiate between these? Once we
have to take this into account, there is no longer such a simple answer to
the problem. And I'm afraid we do have to take this into account. The PSTN
can make the facilitating assumption that only one destination is reached by
the call - SIP cannot make that assumption.

This is why what looks like the easiest case (naive use of provisional media
with in-band ringback to prevent clipping) is actually the one of the
hardest.

In any event, it isn't clear to me why we should conflate continuous and
disjointed media based on your analysis below. I maintain that the
distinction between the two is valuable. The "just play it" philosophy
doesn't help with the fact that disjointed media requirement that an entity
other than a UAS that is a target of the call can source the media.
Continuous media (provisional media that transitions seamlessly into 'final'
media) should always be an exception case that is only caused by
interworking. Disjointed media should be a normal part of SIP, and should be
handled with the tools best suited to its needs (which does not mean 180
with SDP, I suspect).

Jon Peterson
NeuStar, Inc.

---

From: Michael Hammer <[email-masked]>
Date: Fri, 06 Dec 2002 09:38:35 -0500

Francois,

But much of this debate seems to center around where to focus the audio 
output (where GUI may or may not be present) based on the ambiguity in what 
is being sent.  So... unless one wants to mix the ringing (maybe as a 
background element) based on receipt of 180 with the receipt of RTP which 
might be comfort noise or dead air or "I'm in the attic give me time to 
reach the phone" then making the wrong choice dependent on the case will 
leave the user with an unexpected outcome.

I would like to see each combination event enumerated along with the 
corresponding signal combination, and then the resulting expected 
behavior.  Much discussion focuses on which event to address.

Mike

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 6 Dec 2002 12:21:08 -0800

> Early-media for early-ringback/announcement howere is more 
> troublesome. 
> The rationale for supporting this has always been mostly PSTN 
> interworking. It seems that the idea of answering the call 
> artificially (200) to provide inband ringing was turned down for
> billing/accounting purposes. Assuming that we do not override this
> decision, it seems to indicate that we do need to support early-
> ringback/announcement in the case of PSTN interworking (and yes it 
> will have some interesting effects on forking: calls that sounds busy
> and then is answered, message saying "number disconnected" and then
> an answer, etc). I'm not sure that there is a solution to these 
> side-effects. 

There are indeed many side effects. If you are concerned about billing,
then consider what happens if I put up an information service that
simply passes its content as an "early media", without ever answering a
call. Or consider what happens if I can send back an SDP packet in an
180 response, and never bother to actually send a 200 response -- just
keep sending call progress messages. The whole thing is silly. 

> We do have a choice however on what we do when there is NO PSTN 
> interworking. It looks like Christian is arguing for NOT allowing 
> early-ringback/announcement. That would imply that in order to 
> satisfy Gonzallo's "I'm in currently working in the garage" alerting 
> announcement, you'd have to answer the call artificially (like an 
> answering machine). This seems to be a fundamental question to 
> answer. 

There is beauty in simple solutions. I fear that early media leads to a
world of patches after patches.

By the way, if we are concerned with security, then we should consider
that most secure scenarios do require some form of handshake before
sending the media. Something like send a certificate in the invite, send
a session key and a proof of identity in the 200, finalize the session
key negotiation in the ACK.

> From: Christian Huitema [mailto:[email-masked]] 
> Sent: Thursday, December 05, 2002 6:00 PM 
> To: Peterson, Jon; William Marshall 
> Cc: [email-masked] 
> The only solution that actually works is to only send media 
> after receiving the 200 (sender) and the ACK (receiver). All 
> the other solutions are based on the desire to overload the 
> SIP session establishment message with some other function, 
> e.g. map to ISUP or map to accounting events. I believe such 
> mapping is fundamentally impossible.

---

From: "Hearty, John" <[email-masked]>
Date: Fri, 6 Dec 2002 14:36:23 -0700

Like it or not, SIP-PSTN interworking is happening, and could possibly be a dominant early use of SIP.  Users will expect to hear media (tones, announcements) provided by the PSTN prior to answer, and will expect no clipping of the PSTN callee's "Hello."  It is safe to say these are hard requirements that need to be met, they cannot be ignored in favor of a beautiful, simple solution.

I watch this thread with great interest, anticipating a solution meeting the above requirements.  I would agree with those who discourage the use of early media for native IP applications, where the desired user experience could be attained through other methods, thereby (hopefully) keeping session initiation complexity to a minimum.

John Hearty
Level3

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 6 Dec 2002 18:42:01 -0500

Some notes inline.

Jon Peterson
NeuStar, Inc.

> Sent: Friday, December 06, 2002 6:19 AM

From a user interface perspective, it's also unclear how the UAC would
'choose' between these. Some sort of channel-changer? 

> one wins is somewhat irrelevent.  At worst, the UAC discovers there

If a proxy forks to three gateways, the problem exists. I think this problem
is real enough that we have to factor it in. Remember, a proxy may not be
able to tell, by looking at a contact address it has for a particular AoR,
whether or not sending a request to that URI will reach a gateway or not. Or
at least, I don't think we can make a facilitating assumption to the
contrary.

> choices, works fine in all practical cases with a "just pick one".

It won't solve the clipping problem, however, if you have two gateways that
are both giving you ringing, and you choose the one that doesn't happen to
pick up. Then the media that would ordinarily be clipped is still clipped,
even though the UAC receives it, because the user doesn't happen to be
listening to that media. This is the root of my problem with "just play it".

> use different windows/speakers for each; I don't think the gain is 

Agreed.

> which fact we can use to keep the UAC algorithms simple.

Disjointed media has different requirements that continuous media (like
being sourced from external servers). So I'm not sure I believe this is
true. There are also much better ways (like Alert-Info) to implement
disjointed media that don't apply to continuous media. Consider that
continuous media might be played a busy signal, not an alerting tone at all.

> to the UAC as "provisional" media.

Well, and this is the semantic distinction I'm proposing as a matter of
scope for this work. I don't think UACs should consider continuous
provisional media to be a 'normal' case. 'Normal' provisional media is
disjointed and should be established with some mechanism other than SDP
answer in 180. Only this aberrant gateway case uses provisional media to
express call status. Although I'm not proposing any mechanisms at the
moment, I'm only trying to get agreement on the problem, there might be a
way that gateways can inform user agents that they are 'aberrant' in this
fashion.

The fact that 'final' media can overtake the 200 OK is important. But as
you've pointed out in the past, simultaneous pick-up isn't our problem case
here. I'm not worried if media transmission only begins when someone picks
up the phone. I'm worried when there is media transmission during the
provisional phase that is unrelated to pickup.

> We have to treat that as a normal case,
> caused by interworking.  

Good that we agree on that.

> But the distinction is lost at the UAC.
> 
> Bill Marshall
> [email-masked]
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 6 Dec 2002 18:44:34 -0500

A note below.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Friday, December 06, 2002 11:44 AM
To: 'Christian Huitema'; 'Peterson, Jon'; 'William Marshall'
Cc: [email-masked]'
Subject: RE: [Sipping] Re: Meaning of status codes

We do have a choice however on what we do when there is NO PSTN
interworking. It looks like 
Christian is arguing for NOT allowing early-ringback/announcement. That
would imply that 
in order to satisfy Gonzallo's "I'm in currently working in the garage"
alerting announcement, 
you'd have to answer the call artificially (like an answering machine). 

This seems to be a fundamental question to answer. 

 <JFP> This is exactly why I have been suggesting alternatives like
Alert-Info, that do not create the problems of early media but allow us to
satisfy virtually the same requirements. </JFP> 

> From: Christian Huitema [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 6 Dec 2002 18:56:44 -0500

My ideal outcome of this work is to leave SIP untouched. I think it is very
plausible that we will discover that the early media problems that can be
solved have already been solved in SIP, and that there's little we can do
about the problems we can't solve.

However, there is still a lot of confusion about the problem how to apply
the mechanisms already available in SIP to early media. I believe it is
worth documenting in an I-D the problem statement and the application of SIP
to this problem even if this requires no new SIP mechanism - just so we
won't spin this WG's gears on this problem any more.

Jon Peterson
NeuStar, Inc.

> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 1:15 PM
> To: 'Francois Audet'; 'Christian Huitema'; 'Peterson, Jon'; 'William
> Marshall'
> Cc: [email-masked]
> There was a time when most of data network design by some was focused
> (wrongly) on interfacing with the mainframe front-end processor to SNA
> networks. Many people on the list may not remember it. 
> 
> Focusing SIP design on 100% equivalence with PSTN will be similar
> forgotten. 
> 
> I also think Christian is right and let's put this to rest, 
> unless there
> are clarifications to existing SIP documents.
> 
> SIP is no longer an academic exercise, but has a solid 
> product base that
> cannot be upset for trivial reasons IMHO (or for closed 
> network designs)
> - keep here only what is backward compatible and is applicable to the
> public Internet.
> 
> Thanks, Henry
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Francois Audet
> Sent: Friday, December 06, 2002 1:44 PM
> In the case of forking, I believe Christian is absolutely right. No
> matter how much we try, 
> if we do early media we have a 1-chance-in-N of the early media to be
> appropriate. 
> Consequently, only sending the media after the 200 (called 
> side) works. 
> Sending early media will not be useful. 
> We should be very careful then with early in-band 
> ringback/announcement
> and clipping avoidance. 
> Early-media (for clipping avoidance) does not seem to be an issue as
> only one endpoint 
> will eventually answer. 
> The rationale for 
> supporting this has always been mostly PSTN interworking. It 
> seems that
> the idea of 
> answering the call artificially (200) to provide inband ringing was
> turned down for 
> decision, it seems to 
> indicate that we do need to support early-ringback/announcement in the
> case of PSTN interworking 
> (and yes it will have some interesting effects on forking: calls that
> sounds busy and then is 
> answered, message saying "number disconnected" and then an 
> answer, etc).
> I'm not sure 
> that there is a solution to these side-effects.

---

From: William Marshall <[email-masked]>
Date: Fri, 6 Dec 2002 23:21:45 -0500 (EST)

Jon,

> I mean, if the gateway does know that what's happening in the media stream
> is alerting, it should just send a 180. The media associated with that
> alerting isn't immensely valuable to the UAC. Mr. Marshall (and others) have
> suggested that it is worth sending media in every case (whatever provisional
> status code you return) in order to prevent clipping, since it seems to do
> [no] harm. 

I don't think so.  Sorry if some of my postings have given that impression.

A PSTN Gateway that doesn't know the call status needs to send provisional
media, but that is the only case for it.  A "normal" UAS would
only send media after (or simultaneous with) the 200-OK.  I think
there has been general agreement on this point.

But the situation is different at the UAC.  It doesn't know what is
happening; doesn't know whether the call is going to a PSTN gateway or
not.  My claim is that the UAC needs to be prepared to accept this 
provisional media, even though it only comes in only rare cases (or never 
in the PSTN-free future).  The UAC sees an SDP answer to its offer in 
some provisional response (18x).  Once the UAC has received the SDP answer 
(and before receiving the 200-OK), it needs to be prepared to receive 
media packets; provisional media and final media will look alike.

And one other minor point,
> > Jon,  what you are describing is a general problem of early media and 
> > forking. 
> Yes, exactly. One that Mr. Marshall did not seem to be considering, hence I
> was trying to bring it to his attention.

I continue to believe that proxy that forks a request to send it to
two PSTN gateways is inherently broken.  (Recall my earlier example about
one inband-ringing, two voicemails, and three fast-busys, and the voicemail
always wins being the first to send 200-OK.)  So I have considered this,
and consider it a non-problem.  Are thee really valid cases for forking
a request to multiple PSTN gateways simultaneously?  I just don't see them.

Bill Marshall
[email-masked]

-----original message-----
From: "Peterson, Jon" <[email-masked]>
To: "'Rohan Mahy'" <[email-masked]>
Cc: "'William Marshall'" <[email-masked]>, [email-masked]
Subject: RE: [Sipping] Re: Meaning of status codes
Date: Fri, 6 Dec 2002 19:26:53 -0500 

Some notes below.

Jon Peterson
NeuStar, Inc.

> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 3:02 PM
> To: Peterson, Jon
> Cc: 'William Marshall'; [email-masked]
> Subject: Re: [Sipping] Re: Meaning of status codes
> 
> 
> 
> On Thursday, December 5, 2002, at 05:16 PM, Peterson, Jon wrote:
> 
[snip]
> >
> 
> Jon,  what you are describing is a general problem of early media and 
> forking. 

Yes, exactly. One that Mr. Marshall did not seem to be considering, hence I
was trying to bring it to his attention.

> The "just play it" philosophy and the extra semantic data 
> provided by sending a 180 instead of a 183 is actually a benefit to 
> resolving the problem.  

A lot of this thread has been about whether or not there is any 'extra
semantic data' that is made available by sending a 180 vs. a 183. I happen
to agree that it is better to use 180 when you know alerting is occurring.
However, the hard cases that motivate early media are ones in which the
gateway does not know what sort tone is being played in the provisional
phase; ringing, a busy signal, an announcement - all can show up the same
way to the gateway in ISUP signaling in some cases.

I mean, if the gateway does know that what's happening in the media stream
is alerting, it should just send a 180. The media associated with that
alerting isn't immensely valuable to the UAC. Mr. Marshall (and others) have
suggested that it is worth sending media in every case (whatever provisional
status code you return) in order to prevent clipping, since it seems to do
know harm. I've been responding that there are cases in which it does more
harm than good, namely forking cases. I also think it is unSIPlike for a
number of reasons to send that ringing media, but I'll detail that in
another (longer) note.

> The problem is solved simply by setting a 
> priority scheme for the sources of incoming audio.  Note that most 
> other types of media do not have this problem so I will focus 
> on audio only.
> 
> media from connected dialog
> media from early dialog with 183
> media from early dialog with 182
> media from early dialog with 181
> media from early dialog with 180
> inband alerting
> 

Also, just because one gateway is aware that there is ringing on the line
(and hence sends a 180), and another gateway is not (and hence sends a 183),
why is it more plausible, from the perspective of preventing clipping, that
the 180 responder will actually be the place where the user picks up? I
don't think it is. I don't think this prioritization necessarily grants us
any additional leverage in figuring out how to prevent clipping.

> if I get more than one media stream in the same category, I need to 
> just pick one of those steams to represent the category.  

As I said in other mails (and this was the point of my whole thread with Mr.
Marshall), this does not in fact give you any additional leverage on the
problem of clipping - "just pick one" does not guarantee that you'll be
listening to the one that will be picked up. Clipping prevention is being
presented as an argument for "just play it".

> Note that you 
> need to do something like this *anyway* if you deal with 
> multiple 183s.
> 

I have argued elsewhere in this thread that media in the offer/answer
context of a dialog prior to 200 OK is an aberrant and avoidable case that
we should eliminate in native SIP interactions (there are much better ways
to provide that functionality), so I'm not sure there are valuable 'anyway'
cases.

> Also, note that parallel forking an INVITE to more than one PSTN 
> gateway is a stupid thing to do anyway, so this is really just handling 
> an error case in a robust fashion.
> 

Well, it isn't at all clear how a forking proxy will know that a given
contact address points to a PSTN gateway - I mean, in some cases it could be
explicit and obvious, but in other cases it won't be. Even an individual
ISUP gateway might, for some calls, be able to tell when there is alerting
in the media streams, but for other calls be unable to do so. Of course,
some sorts of gateways might never be able to give you status information
out-of-band, and it might be nice (looking ahead to mechanism for a moment)
to be able to identify such gateways to UACs or forking proxies.

I do agree this is an error case - but I think the 'error' lies in that some
PSTN networks express their status in-band. I agree that the problem of
early media is to a large degree about handling this error case in a robust
fashion.

> thanks,
> -rohan
> 
> 
> > UACs have no way to know which one of these UASs may, eventually,
> > reached by
> > should be

---

From: Al Varney <[email-masked]>
Date: Sat, 07 Dec 2002 09:22:38 -0600

At 02:36 PM 12/6/02 -0700, Hearty, John wrote:
>Like it or not, SIP-PSTN interworking is happening, and could possibly be 
>a dominant early use of SIP.  Users will expect to hear media (tones, 
>announcements) provided by the PSTN prior to answer, and will expect no 
>clipping of the PSTN callee's "Hello."  It is safe to say these are hard 
>requirements that need to be met, they cannot be ignored in favor of a 
>beautiful, simple solution.
>
>I watch this thread with great interest, anticipating a solution meeting 
>the above requirements.  I would agree with those who discourage the use 
>of early media for native IP applications, where the desired user 
>experience could be attained through other methods, thereby (hopefully) 
>keeping session initiation complexity to a minimum.

    The solution is obvious:  Never use 180 on SIP-to-PSTN calls through a 
gateway.  Always use 183 with "recv only" or "sendrecv".  In-band ringback 
or other tones are ALWAYS furnished by the PSTN.  Clipping in the backward 
direction disappears.  Clipping in the forward direction will, as in ISUP 
today, require the "answer" signalling to get back through any gateway/UA 
that isn't set to "sendrecv".

    This solution was an option in the SIP-ISUP draft-04, prior to the 
hurried changes during Last Call (in draft-05) that were 
anti-early-media.  Jon's suggestion at the time was that early media needed 
to be addressed for all of SIP, not just for SIP-PSTN interworking, so we 
should allow the draft to go forward and propose changes after a more 
robust generic SIP mechanism/framework was agreed (after November IETF).

    Now I'm hearing that whatever this "more robust" early media framework, 
it needs to be backward-compatible with SIP-ISUP-05, which means it has to 
follow a rushed and (IMO) incomplete mechanism.

    As I recall, SIP-ISUP-draft-05 was cast in stone in August -- remind me 
again what the rush was to get it in the Editor's queue, rather than 
allowing the discussion to complete as part of Last Call?  And why did we 
have to hold further discussion until after November IETF?

    Alternatively, follow Christian Huitema's more "SIP-pure" suggestion 
that a PSTN gateway send 200 OK for "early media" cases (so it's no longer 
"early").  After all, the UAS to PSTN-gateway SESSION is established -- 
some other message can send "answer/charging begins", which probably only 
makes sense for PTST interworking anyway.  Those using SIP over 
bandwidth-scarce interfaces (3GPP) would then be assured that receipt of 
180 really meant that there is no media to be received.

-----
    While I'm on the subject, (from the "Early media draft" thread):
At 03:14 PM 11/26/02 -0800, Francois Audet wrote:

>2. But in certain cases, the gateway DOES know that the far end
>is being alerted AND that in-band media is available. In that case
>it can send both the sendrecv and the 180. This will cause no harm.
>The phone can just do whatever it is supposed to do when receiving
>a 180 (i.e., text indication, or providing local ringback overriding
>any in-band voice).

    This isn't the case (IMO) for SIP-ISUP gateways, since I don't believe 
ISUP provides a reliable indication of "being alerted" (as opposed to "line 
is free", which isn't the same thing).  And that's the reason I was 
concerned about the changes from Draft-04 to Draft-05.  Jon suggested 
waiting until "generic SIP early media" was ironed out before re-opening 
any update to SIP-ISUP.  I'm still waiting.

>3. And finally there is the last case (the one that doesn't work if you
>turn off the normal treatment of 180, as per the example in the draft).
>This case is when there is a 180 and a sendrecv but NO inband ringing. This
>will happen often when a PSTN gateway makes a call on an ISDN interface and
>stays ISDN end-to-end (because in that case, many implementations will
>behave like "normal" SIP and will NOT provide in-band ringing).

    I'm presuming this is a SIP-ISDN gateway, not a SIP-ISUP gateway.  I 
don't know of any ISUP that doesn't provide in-band ringing on voice 
calls.  Folks have suggested it exists, and some books on ISUP have 
described it.  But I'd really like to try calling it from an ISDN phone in 
the USA.  There, audible ringing tone (ringback) is always presumed to be 
generated at the terminating exchange or a PBX connected to that exchange 
(see ANSI T1.609).

-----
   Forking with early media is another issue -- but it seems to avoid the 
question of what to do with multiple 200 ACKs from forked INVITEs.  Can one 
really think there will only be one 200 ACK, and that the other possible 
answering parties won't be upset if their call is ignored?  (I can get that 
treatment today from telemarketers.)

    Also, what happens if you receive several 180 codes with "sounds" 
embedded inside -- which do you pick to play?

 > mapping is fundamentally impossible.

    I'd note that, from my non-SIP-expert viewpoint, the "early media" 
problem exists because SIP does not appear to support the serial "hand-off" 
of a session from UAC to UAC to UAS (that's the insertion of short 
announcements, call progress tones, etc. as the session is 
established).  If it did so, there wouldn't be a need for "early media", 
which allows 200 ACK to mean "I'm done handing off the session".  Then all 
media could occur after 200 OK and explicit messages could indicate the 
movement of the session end-point from one UAC/UAS to another (if the 
originator even cares to know about the movement).  "Answer" would be 
discarded as an old PSTN concept.  Sorry, got carried away....

    OK -- I'll shut up for awhile (again).

Al Varne

---

From: Adam Roach <[email-masked]>
Date: Thu, 5 Dec 2002 11:02:40 -0600

Right?

/a

---

From: Michael Hammer <[email-masked]>
Date: Thu, 05 Dec 2002 12:15:13 -0500

I think there is also a potential indicator in the optional backward call 
indicators to indicate that signaling is present in-band.  But, there is 
not guarantee that these arrive at the gateway.

Mike

---

From: Adam Roach <[email-masked]>
Date: Thu, 5 Dec 2002 15:42:29 -0600

Okay, so what you have just called reasonable points to an agreement
with the statement that Gonzalo used to start this thread. To rephrase:

Do you agree?

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 5 Dec 2002 16:48:51 -0600

Stop. Wait. Think about it.

It's just moronic to send a 183 when you know for a fact that the
called user is being alerted. There's no point. We have a code
that means "the called party is being alerted". It's 180. Just
use it.

In fact, as Jon points out, this is precisely what RFC 3398,
section 7.2.6, says to do.

/a

> From: Michael Hammer [mailto:[email-masked]]
> Sent: Thursday, December 05, 2002 16:38
> To: Peterson, Jon
> Cc: 'Francois Audet'; 'Gonzalo Camarillo'; 'William Marshall';
> [email-masked]'; [email-masked]'; 'Alan
> Johnston'; 'sipping'; 'Adam Roach'
> Subject: Re: [Sipping] RE: Meaning of status codes
> 
> 
> Jon,
>

---

From: Al Varney <[email-masked]>
Date: Mon, 09 Dec 2002 10:41:10 -0600

>called party is being alerted.

    No -- It means the party might be alerting.  Or not.

  1) Possible Call Blocking service:
    ACM=subscriber-free, media is playing "The party you called is not 
accepting calls from your line."
  2) Possible Call Waiting service:
    ACM=no-indication, media is playing RINGBACK.

    So a SIP-ISUP gateway can't really be sure either way.  A gateway for 
SIP-ISDN or SIP-POTS (directly-connected lines), on the other hand, CAN 
tell if the party is being alerted.

    But this is really a SIP-ISUP issue.  Before we describe the operation 
of various gateways, we must first agree on how early media works in SIP 
generally.  (Unfortunately, SIP-ISUP Draft 05 has been agreed prior to 
agreement on early media.)

Al Varney

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 9 Dec 2002 10:50:55 -0800

I can asssure you that on ISDN interfaces (including Q.931, QSIG, etc.),
local alerting
with NO far-end generated inband ringback (which is an ALERTING message
without Progress indicator 
#1 or #8) is VERY commonplace.

This is why we have to take the 180 seriously.

> Cc: Audet, Francois [SC100:4K02:EXCH]; 'William Marshall'; 
> [email-masked]'; [email-masked]'; 
> Subject: [Sipping] RE: Meaning of status codes
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

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

As I say in the note that you cite below, I don't think it is an 'error'
case in the sense that Bill meant, and that you seem to imply below. I agree
it is perfectly plausible for a proxy to fork to multiple gateways, and I
agree that it is probably impossible for a proxy to ascertain whether or not
a given URI indicates a gateway or not. I was just saying that because some
PSTN networks express their status in-band, this in and of itself creates
exceptional conditions for SIP when it interworks, and that if there's any
'error' here, it lies in that, not something broken about forking.

Jon Peterson
NeuStar, Inc.

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, December 09, 2002 7:03 AM
> To: Peterson, Jon
> Cc: 'Rohan Mahy'; 'William Marshall'; [email-masked]
> Jon and Bill,
> Why do you consider this to be an error case?
> 
> It *might* be an error case if you fork to two gateways in an 
> attempt to 
> reach a *single* phone number in the PSTN. But it could as well be a 
> normal forking case attempting to reach either of two distinct 
> addresses, both of which happen to be PSTN phone numbers.
> 
> And of course the forking proxy may have no way to know this is the 
> situation. The addresses being forked to may both appear to it as sip 
> AORs, that are routed to gateways further downstream.
> 
> 	Paul
> 
> Peterson, Jon wrote:
>  >
> William Marshall wrote:
>  > two PSTN gateways is inherently broken. (Recall my earlier example
>  > about one inband-ringing, two voicemails, and three fast-busys, and
>  > the voicemail always wins being the first to send 200-OK.) 
> So I have
>  > considered this, and consider it a non-problem. Are thee 
> really valid
>  > cases for forking a request to multiple PSTN gateways 
> simultaneously?
>  > I just don't see them.
> 
>

---

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

inline.

Jon Peterson
NeuStar, Inc.

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Tuesday, December 10, 2002 4:02 AM
> To: [email-masked]
> Hi,
> We seem to spend a lot of time arguing about it early media 
> shall be used between SIP nodes, or only in interworking cases.
> 
> Let's assume for a while that early media would be used ONLY 
> in interworking cases. Then we need to answer the following questions:
> 
> 1. In a SIP-to-PSTN call, how does the gateway indicate to 
> the remote SIP phone that early media may arrive?
> 
> 2. In a PSTN-to-SIP call, how does the remote SIP phone 
> indicate to the gateway if there may be early media (ie how 
> does the gateway know if it should generate local ringback 
> towards the PSTN network or not)?
> 
> Now, one may argue that the second question is not valid, 
> since we assumed SIP nodes won't generate early media.
> 
> BUT, what if the SIP node is another gateway, ie we have a 
> trunking case? Will we prevent early media in trunking cases?
> 

On question two, the point is that we can make a different behaviorial
recommendation for normal SIP UASs than we do for UASs that interwork with
non-SIP networks which are unable to express status out-of-band.

So, I don't think the right way to cast the questions is SIP->PSTN vs.
PSTN->SIP. I think he right way to cast it is:

(a) Normal UAC behavior (which must work with either of the UAS scenarios
below)
(b) Normal UAS behavior (this includes cases where the UAS wants to send
some provisional media)
(c) Gateway UAS behavior (including cases where the gateway does and does
not have out-of-band status information)
(d) Gateway UAC behavior (if we in fact need any special behavior here)

But you're on the right track, I think, in that you are posing questions and
not proposing mechanisms.

> I think these are REQUIRMENT questions we have to solve 
> first, toghether with the backward compability issues 
> mentioned in other mails - otherwise we will go on with this 
> discussion forever...
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 11 Dec 2002 11:09:38 -0800

> RFC3261 has provisions for playing media received over an 
> offered stream
> regardless of whether or not an answer has yet been received. 
> How does the
> answer in 180 itself help to prevent clipping? If Bill is 
> only concerned
> with media that is sent when the remote side has picked up 
> the phone (i.e.
> simultaneous with transmission of 200 OK), what additional 
> leverage do we
> get from having the answer in the 180 instead of the 200? 
> This also raises
> concerns that have been discussed in this thread about 
> sending an answer
> with an 'active' media stream when you don't intend to play any media.

Clipping prevention only makes sense when there is no forking. In that case,
the SDP in the 180 is acceptable.

When forking occurs, there is no way to reliably avoid clipping. I guess you
could try to play all the packets coming your way from different sources,
but
that seems far-fetched to me.

---

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

inline.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Wednesday, December 11, 2002 11:10 AM
To: 'Peterson, Jon'; 'Rohan Mahy'
Cc: [email-masked]'
Subject: RE: [Sipping] Re: Meaning of status codes

> with an 'active' media stream when you don't intend to play any media. 

Clipping prevention only makes sense when there is no forking.  

<JFP> My fear that there will be no way to manage clipping when forking
occurs for pre-answer media in the INVITE offer/answer context is exactly
why I want to reduce the number of cases that generate pre-answer media. It
makes our job easier to specify UAS behavior that relies on pre-answer media
as infrequently as possible. </JFP>

 In that case, 

<JFP> Even if we grant this, how does a UAS that receives an INVITE know
that it was forked, and that it is therefore acceptable to send 180 in SDP?
I also remain a little unsure what the SDP in 180 is meant to accomplish.
</JFP>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 12 Dec 2002 08:49:08 -0800

This is exactly what I am saying. 

 In that case, 

I don't beleive that the UAS receiving the INVITE needs to know that it was
forked. Endpoints receiving the INVITE just do their normal treatment. The
receiver of the response will have to decide what to do with the multiple
dialogs with early media (if present). There is nothing we can do to prevent
conflict in cases of forking (different endpoints each sending their own
early media stream).

My point of view on the 180/SDP is that its main attraction is clipping
avoidance (when there is no forking). Other people on this list would also
like to use it for in-band ringing even when an out-of-band alerting
indication is used (I'm not a big fan of the last item, but I don't mind as
long as it don't break anythink). Presumably, the idea is that an
annoucement could be sent, or that one wishes to a specific ringback tone.
My view is that if the content of the in-band media is more important the
logical indication, I'd rather use the 183 to make sure that it is not
ignored by the far end. Or perhaps use your Alert-info idea.

I think we are converging...

---

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

inline.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 8:49 AM
To: 'Peterson, Jon'
Cc: [email-masked]'
Subject: RE: [Sipping] Re: Meaning of status codes

 [snip] 

<JFP> Perhaps you missed my point - I meant, why specifically does sending
an SDP answer in 180 (as opposed to any other way of signalling the
transmission of early media from the UAS, such as sending answer in 200)
actually help prevent backwards media clipping? I agree that sending media
on answer simultaneously with the 200 OK might lead to a case in which in
the media arrives before the answer, but RFC3261 already seems to have
provisions for this. </JFP>

<JFP> I agree - on this issue, at least. Plenty more to go over here...
</JFP>

---

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

A few notes inline.

Jon Peterson
NeuStar, Inc.

> Sent: Thursday, December 12, 2002 1:54 AM
> To: Peterson, Jon
> Cc: 'Rohan Mahy'; [email-masked]
> A few comments.
> > >>As an aside, if you receive ten such media streams, your 
> client would
> > >>have some difficulty playing any of them if there are bandwidth
> > >>constraints, etc.
> > >which we can address with an UPDATE to shut these up.
> >
> > True, but it is better to recommend a UAS behavior that 
> does not require the
> > UAC to go to this trouble. UPDATE should be used as a last 
> resort when UASs
> > are (hopefully out of necessity) sending pre-answer media, 
> but it is better
> > still to allow the UAC to manage its acquisition of 
> optional early media
> > more easily.
> 
> [CHH] I agree on this. Of course a UAC MAY send UPDATE if it wants, but it
may
> also choose to simply use some kind of
> RTP "filter", to mix everything, or not to pass anything before 200 OK. I
guess
> that is all based on local policy and capabilities.
> 
> However, IF the UAC sends UPDATE, we have to remember that another UPDATE
must
> also be sent when the call is answered (I assume "an UPDATE to shut these
up"
> mean you mean changing the mode to "inactive"?). And, I guess it's the UAS
who
> would have to send that UPDATE (I think that is at least what has been
> proposed), but can we really assume that will happend? Or, do we assume
that the
> node which sends to first UPDATE (to stop early media) will also send the
second
> UPDATE (to allow it) when it receives 200 OK? In any case, however, we
once
> again come to the issue of clipping, and what "inactive" really means.
> 

Well, my perspective is that the UAC should have some capability to control
the transmission of early media from one or more UASs. The UAS, however, is
the one that makes a decision about how it is going to offer pre-answer
media to the UAC. If it turns out to be through continuous early media in
the offer/answer context of the original INVITE, then the UAC can use
UPDATEs to manage this process (with a few caveats - source and sink
information in the SDP seems to be necessary). You're probably right that
subsequent UPDATEs would be necessary to active media streams as
appropriate. It's also less than clear to me how a UAC would choose which
media stream to accept when presented with alternatives (i.e. how denying
shutting up various media streams realistically combats clipping). Still,
there is a role for update in those cases in which a UAC simply cannot
accomodate multiple media streams under any circumstances.

[snip]
> > >
> > >Gateway side (UAS for the INVITE)
> > >1. If the GW knows that the PSTN is alerting, it should send a 180 with
> > >and answer, *but send no media* until it sends a 200 or 183.
> > >2. If the GW does not know the semantics or some early media, it should
> > >send a 183 with an answer and send that media.
> >
> > Yes, this is essentially what I've been suggesting.
> 
> [CHH] Just to clarify, what do you mean by "with answer". Assume the UAS
has
> already sent an answer. Do you mean that it now would send the same SDP (a
copy
> of the answer) as some kind of indicator, or? I think we shall remember
that the
> gateway may recieve multiple ISUP messages, mapped into 18x. Does your
> suggestion only affects the first 18x sent, or?
> 

Heh - sorry, thanks for catching this. I had read (1) incorrectly to suggest
that 180 would be sent without an SDP answer. I certainly haven't been
suggesting that the 180 should contain an answer when no media will be sent
- I've been struggling to understand what properties people want to derive
from that.

[snip]
> 
> [CHH] Didn't you earlier say that sending UPDATE should be used as "last
> resort", so I think it should be MAY instead of SHOULD. Also, the UAC may
not
> reserve different ports for every early stream, it may simply change the
stream
> to "inactive" (in which case either party also needs, as described
earlier, to
> put the stream back to "sendrecv" when the call has been answered).
> 

Well, this is the distinction between UAS and UAC behavior. The UAS
shouldn't be sending backwards pre-answer media that requires the use of
UPDATE - hence the UAC shouldn't be put into this position, and it is a last
resort when the UAC needs to rely on this media. So, what I want to
discourage is the UAS sending continuous early media (and by extension early
answers) in the first place. We can then make recommendations for how the
UAC should deal with this situation when it arises.

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 21 Dec 2002 15:22:41 -0800

Agreed.