Subject: RE: [Sipping] New version of the early media draft

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 12 Mar 2003 23:52:29 -0500

Let me see if I can put this is a slightly simpler light. Let's ignore what
SIP status code the gateway sends for a moment.
 
A gateway UAS needs to decide whether it's going to send pre-answer media
media or not. What I've heard you saying is that the indicators in ISUP
don't provide this information (presumably that the 'in-band status
indicator' in OBCI doesn't have to be present in order for the PSTN to send
in-band status, just sending 'subscriber free' in BCI is enough). All right,
let's grant that for a moment.
 
So how does the gateway decide whether or not it's going to send media? I've
heard that ISUP doesn't tell you this, and that in-band media detection at
the UAS gateway is unacceptable.
 
What's the point of proposing some indicator (regardless of where it
appears) that a gateway UAS can send to the UAC signifying pre-answer media
if the gateway has no deterministic way of figuring out whether or not it
should send media?
 
The value you ascribe to the UAC knowing that the state is 'alerting' while
still receiving in-band status information is also a little curious to me.
It might be useful in PSTN-SIP-PSTN cases for a UAC gateway to know that the
UAS gateway is in the PSTN state 'alerting', but of course that can be
accommodated with RFC3204. I'm not sure how great the value of communicating
the alerting state is for SIP in other cases, though, when in-band media
contains the real indication of the state of the call. It's not as if that
state information can replace the in-band status information, right?
 
The conclusion is, if there is a deterministic way for the UAS GW to know
the state of a call, we can provide a mapping for it with our existing
mechanics. If there's not, this whole discussion is moot, because then the
gateway never knows the state of the call, your recommendation would have to
be that you send 183 and media for every call that comes through the gateway
UAS. That would be a very ill-advised recommendation to make, in my
estimation.
 
Some more inline.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Tuesday, March 11, 2003 9:23 AM
To: 'Peterson, Jon'
Cc: [email-masked]'
Subject: RE: [Sipping] New version of the early media draft

Well, yes, if you change the axioms you will get a different conclusion.
<JFP> My point was more that SIP has no axioms for this to start with - the
standard is more or less totally silent about this. </JFP>
 
The Alerting state in ISUP is certainly well-defined. It certainly includes
the possibility of in-band media and does not make any assumptions about
what that media is (i.e. does not assume that it is 'ringtone'). It is not
'misleading' for ISUP to signal 'subscriber free' and to include in-band
media which is other than 'ringtone'.
 
Is the SIP state occasioned by 180 Ringing equivalent to 'Alerting' in ISUP
??  
<JFP> Indeed, that is the question. I see no reason to think it is. For one
thing, ISUP can assume that a backwards media path exists - that circuit
reservations were made when the IAM was sent. SIP makes no such assumption.
That's at least one difference in state. </JFP> 
 
Now, if you like, you can (re)define the SIP 180 Ringing state so that it
differs from the ISUP Alerting state in respect of support for in-band
media. Let's say that 180 Ringing does not support in-band media - which
seems to be where Jon is going below.  Now we have an interesting choice at
PSTN gateways in terms of deciding whether to send 180 or not. We could
determine somehow whether the in-band media was in fact 'ringtone' or not
and use this to decide - but perhaps that is not so realistic. Or we could
send 183 whenever we have in-band media (i.e. almost all the time). Ok, so
this will work, but I have discarded the indication that the subscriber is
in fact free. This is useful information at the UAC for several reasons:
(i) is assists in determining what to do with multiple provisional responses
received due to forking 
<JFP> But if you need to play the in-band media anyway, its value is no
greater than that of 183. The UAC knows that it needs to render the media to
get the status information. </JFP>
(ii) I can use it to drive a visual or other indication of call state
<JFP> The whole point of the fact that there's in-band information is that
there's something that can't be summed up by the simple 'ringing' icon or
indicator. If there's a call waiting announcement, shouldn't the visual
display ideally read "your call is waiting" or something? </JFP>
 
<JFP> But here's the thing - in the sorts of use cases I'm hearing from you,
it's not at all clear to me that the subscriber is free. In a call-waiting
case, isn't the subscriber 'free' or being queued? The in-band status
information provided instead of ringtone effectively clobbers the indication
that the subscriber is free. How ISUP defines its states is somewhat
immaterial to this point - saying that you're in the 'alerting state,
subscriber free' when you're playing a announcement that says something
different seems inherently contradictory.
 
All of these arguments about what happens at gateway UASs are predicated on
the fact that the gateway has some way to determine the state of the call.
What I hear you saying is that there really isn't. So where are you getting
this information that you want to carry back to the UAS? </JFP>
 
What is so wrong about wanting to carry this useful information to the UAC
??
 
...Mark

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 10 March 2003 20:44
To: Watson, Mark [MOP:EP10:EXCH]
Cc: [email-masked]'
Subject: RE: [Sipping] New version of the early media draft

Behind this all is probably an argument about what the 'alerting' state in
SIP really means, especially contrasted with 'queuing' and so on. Is call
waiting actually best expressed in the PSTN by ACM with 'subscriber free'?
Is it best expressed in SIP by 180 (or should it be 182)? Whether or not the
PSTN signals 'subscriber free' in ACM for call waiting, that doesn't mean
that the SIP 180 alerting state is co-extensive with arbitrary in-band
status information. The problem is that SIP does not define its states at
this level of granularity, so the evidence for either position would be
indirect at best. 183 expresses that the call is in some provisional state,
that it hasn't yet been rejected as far as SIP knows, and so on - at the
very least, it's sent when other 18x's aren't appropriate for some reason.
 
SIP gains significant benefits from not having to reserve a circuit and
transmit media in the backwards direction in order to communicate that a
telephone is ringing. Again, if ISUP is misleading about the condition that
prevails, I'm not sure that admits of any repair in SIPPING. SIP does
support response codes tailored for queuing situations, but if the PSTN
can't tell us out-of-band that queuing is taking place, we can't map to
them.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Monday, March 10, 2003 1:15 AM
To: 'Peterson, Jon'; 'Ejzak, Richard P (Richard)'; 'Gonzalo Camarillo'
Cc: sipping
Subject: RE: [Sipping] New version of the early media draft

Jon,
 
If I use 183 then I lose the functional (out of band) indication that the
call is now in the Alerting state. So then, for example, a more advanced SIP
client may not provide the correct visual indication to the use ('ringing'
icon, or whatever).
 
We are talking about cases where the call state IS known to be 'Alerting',
so I think we must surely use 180, not 183. But there are useful in-band
tones AS WELL. In general a gateway would not know whether the in-band
information was boring ringtone, or something more interesting.
 
...Mark

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 07 March 2003 18:03
To: Watson, Mark [MOP:EP10:EXCH]; 'Ejzak, Richard P (Richard)'; 'Gonzalo
Camarillo'
Cc: sipping
Subject: RE: [Sipping] New version of the early media draft

I'm not sure I missed that point, exactly. I said that if the gateway knows
that the early media is just ringtone, it should send a 180. You're just
citing another case below in which the early media is not ringtone. I can't
see how this contradicts what I said. If there's some other in-band status
information available, the gateway should be using 183.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Friday, March 07, 2003 1:17 AM
To: 'Peterson, Jon'; 'Ejzak, Richard P (Richard)'; 'Gonzalo Camarillo'
Cc: sipping
Subject: RE: [Sipping] New version of the early media draft

Jon, 

You have missed one very important point which is that in-band media during
alerting is not necessarily 'just ringtone'. It is quite common for the call
to be in the 'Alerting' state (and for this to be know to a SIP to ISUP
gateway), but for the in-band media to contain some useful information other
than 'just ringtone'.

For example, in the UK at least, if the called party has Call Waiting, then
the call of course goes straight in to the Alerting state, but the caller
will here a message along the lines 'Please wait while we try to connect
your call - the person you are calling knows you are waiting'.

A second example would be when the call terminates on a queueing system, and
the message played gives the caller some idea of how long they will need to
wait.

I absolutely agree that if the in-band media was 'just ringtone' there would
be no point. In particular I don't see any need to support the PSTN
'feeture' in which you always hear the ringtone of the destination country
(IMO this is a bug, not a feature!).

So, let's recognise that there are cases where *both* out-of-band and
in-band status indications are present. My view is that out-of-band
indications should always be propogated if available - so for the scenario
in question we MUST use 180, not 183. Now we need to indicate that in-band
status is also available - is this really so hard ????

...Mark 

> -----Original Message----- 
> From: Peterson, Jon [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: 07 March 2003 00:09 
> To: 'Ejzak, Richard P (Richard)'; Peterson, Jon; 'Gonzalo Camarillo' 
> Cc: Watson, Mark [MOP:EP10:EXCH]; sipping 
> Subject: RE: [Sipping] New version of the early media draft 
> 
> 
> 
> Everything below is familiar ground, and I don't want to 
> start rehearsing 
> these same arguments again. SIP has made a number of design 
> decisions that 
> predispose it towards out-of-band status information. Sending 
> in-band status 
> information in SIP is harmful - period. In-band media should 
> be sent only 
> when the gateway does not know the status of the call, and thus cannot 
> communicate it out-of-band. Below, you basically argue that 
> in cases where 
> the gateway does not know the status of the call, it has to send early 
> media. I agree. I said that in cases in which the gateway 
> knows that the 
> early media is just ringtone, it should send 180. Clearly, if 
> there's some 
> in-band transition in call state from ringtone to some other 
> audible call 
> progress information, and the gateway isn't made aware of it, then the 
> gateway doesn't know the state of the call. Perhaps we might draw the 
> conclusion from your example that out-of-band call status 
> indicators are 
> inherently unreliable, then - and surmise that it is 
> impossible for the 
> gateway to know the state of the call. Or perhaps the 
> likelihood of this 
> condition arising is sufficiently remote, the consequences of 
> sending early 
> media sufficiently troublesome, that we might decide the 
> in-band information 
> in these cases is not 'essential' enough to worry over. But I 
> firmly believe 
> we should leave this to the conscience of the individual gateway 
> implementer. I don't think the early media draft needs to draw that 
> conclusion. 
> 
> Mr. Camarillo's draft already maintains a very delicate 
> balance of behavior 
> to accommodate SIP's needs, and I haven't heard anything in 
> this yet that 
> should alter it. 
> 
> Jon Peterson 
> NeuStar, Inc. 
> 
> > -----Original Message----- 
> > From: Ejzak, Richard P (Richard) [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > Sent: Thursday, March 06, 2003 2:40 PM 
> > To: 'Peterson, Jon'; 'Gonzalo Camarillo' 
> > Cc: Mark Watson; sipping 
> > Subject: RE: [Sipping] New version of the early media draft 
> > 
> > 
> > Jon, 
> > I must disagree with your blanket recommendation that the 
> > gateway not sent in-band ringing media.  This may be possible 
> > in some cases - and nothing we have suggested would prevent a 
> > gateway from using out-of-band indications.  But ringing is 
> > not the only in-band call progress information you may 
> > receive while trying to establish a call from SIP to ISUP.  
> > The transition from alerting to other forms of in-band call 
> > progress information is not guaranteed to be clearly signaled 
> > by ISUP within an ACM or CPG (since every switch in the 
> > network can safely assume in-band call progress after a 
> > certain point in the call), and it is essential that this 
> > subsequent information (when it exists) be presented to the 
> > UAC/user.  And the notion of having the gateway intelligently 
> > filter what it thinks is ringing and detect a transition to 
> > other forms of call progress is not acceptable. 
> > 
> > Regards, 
> > Richard Ejzak 
> > Lucent Technologies 
> > 
> > 
> > 
> > -----Original Message----- 
> > From: Peterson, Jon [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > Sent: Thursday, March 06, 2003 4:06 PM 
> > To: 'Gonzalo Camarillo' 
> > Cc: Mark Watson; 'Ejzak, Richard P (Richard)'; sipping 
> > Subject: RE: [Sipping] New version of the early media draft 
> > 
> > 
> > 
> > Well, 
> > 
> > > -----Original Message----- 
> > > From: Gonzalo Camarillo [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > [snip] 
> > > 
> > > The scenario he is after is as follows; a gateway *knows* 
> > that the user 
> > > is being alerted and also *knows* that it will be sending in-band 
> > > ringing. 
> > > 
> > 
> > If the gateway knows that it will be sending in-band ringing, 
> > my position is 
> > that the gateway shouldn't be sending that media. It's just 
> > ring tone. The 
> > UAC can generate that itself. Let's not waste the bandwidth 
> > sending ringing, 
> > especially in forking cases, especially because the UAC 
> might not even 
> > render this provisional media (if it's a PC UAC, for example). 
> > 
> > If media arrives at the UAC, it should override local 
> > ringtone, agreed. And 
> > I have no problem with the idea that a UAC would delay local 
> > ringtone for a 
> > short interval in order to see if any media is coming, even 
> > when 180 is 
> > received. But we should not encourage gateways to send 
> ringing media. 
> > 
> > Jon Peterson 
> > NeuStar, Inc. 
> > 
>

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 13 Mar 2003 08:59:26 -0500

I have been watching this discussion with great interest, but I have to say
that I agree pretty much with what Jon is saying. It seems to me there are a
few simple rules to follow:

1) If the UAS does not want the UAC to play media, then the UAS should not
send media. I still cannot figure out why a UAS would send media if it does
not want it played.

2) If the UAC receives media, it should play it. This becomes very important
if the call ends up at some announcement server (or the American Airlines
IVR system) that is playing media that the caller needs to hear.

I do however think that Alerting in the PSTN does equate to 180 in SIP. 180
should only be sent by the UAS when the called party is being alerted
(whether the UAS sends media or not). When there is no media, I as the user
of the UAC would want the "rendering" of a "ringing" indication to be
accurate. Also, not all UACs have a human user. If the UAS does not know
that it is ringing, it should not lie to the UAC and say it is. I'm not
saying it has to be absolute. If the UAS "believes" it is ringing it can
send 180.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Peterson, Jon" <[email-masked]>

> UAS. That would be a very ill-advised recommendation to make, in my
<previous messages trimmed, please consult the archive>

_______________________________________________
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: Fri, 14 Mar 2003 15:18:08 -0500

At 08:59 AM 3/13/2003 -0500, Bob Penfield wrote:
>2) If the UAC receives media, it should play it.

Do you include in the term "media":

1) RTP stream with silence as input at the PSTN GW, or
2) RTP stream with actual audio carried

I agree you play if 2), not sure about that for 1) as this may be merely 
early setup to avoid clipping.

If ISUP in-band indication is meant to identify 2) or if that is always 
known to be the case, then the way is clear.  But, as already mentioned, 
the ISUP indicator may not be present and the PSTN GW may not be detecting 
audio, thus the non-determinism.

Mike