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

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 10 Mar 2003 10:47:42 -0600

Jon,
You point out that "there are PSTN cases in which ringing is not generated by the remote switch, in which out-of-band signaling causes ringback to be generated elsewhere in the network."  Agreed.  There are also PSTN cases in which a remote switch signals the presence of both in-band call progress information AND alerting where the in-band media is not ringing tone.  And there is no problem in this case since the remote switch is not asking for the generation of local ringing - it is asking to have in-band information cut through to the calling party while also signaling alerting out of band.  Nor is this an incorrect use of ISUP - that's why both indications are available.  No where in ISUP does it say that the only in-band call progress information allowed during alerting is ringing tone.
 
Both of these scenarios are common and important in the PSTN today.  What makes it important to support one but not the other?
 
After some more consideration, I also think that it is appropriate and important to include the resolution of this issue in Gonzalo's draft, since the draft already discusses the role of gateways and in-band media.
 
Regards,
Richard Ejzak
Lucent Technologies

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

Cases in which no interworking is encountered and ISUP fails to portray call status are problematic, sure. Agreed that there are lazy PBXs that may not use Q.931 correctly, which results in poor ISUP, and so on. But if ISUP lies to you about call status, then that creates internal problems for the PSTN, not just interworking with SIP. I'm sure you are aware that there are PSTN cases in which ringing is not generated by the remote switch, in which out-of-band signaling causes ringback to be generated elsewhere in the network. These cases would seem to have problems when out-of-band ISUP indicators are wrong.
 
I'm not sure that it's our job to design interworking cases around non-standard usages of PSTN protocols, however. We could similarly say that if a native SIP endpoint sent a 180 when the call is actually in a state more indicative of 181, or something, that it would be problematic, but I don't think we therefore need to say that SIP endpoints always need to transmit in-band status info.
 
But this is all moot from my perspective - a new in-band indicator for SIP won't make any of this any easier. You are correct, I am saying that a UAS gateway should send 183 when it does not know the status of the call - that is effectively the only in-band indicator that I think we need. But this fact doesn't interact well with your lack of a 'guarantee' about whether or not the out-of-band status is accurate, though. Presumably, you think that a UAS gateway would be required to deliver in-band status info for every call, because there is never any 'guarantee' that ISUP is correct. I don't think we should recommend that a gateway always send in-band status information, whether it would be sent with a 180 or 183. In-band status information, as I've said before, is bad; how we indicate that there is in-band status info is orthogonal to the real issue here.
 
Anyway, Gonzalo's draft is concerned with early media as a general interworking phenomenon, I believe - it isn't just limited to ISUP. So I agree that Gonzalo's draft is not the right place to recount the various ISUP indicators and how a gateway UAS will treat them. You are correct that RFC3398 is the right place for that specification. Currently, though, I don't see a need to revise its existing text.
 
Jon Peterson
NeuStar, Inc.

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

Jon,
You are assuming a model in which the UAS gateway call control entity has perfect knowledge of the content of the media stream.  This is frequently not true, particularly in a decomposed MGC/MG architecture.  There are two possible ways for it to gain this knowledge: 1) for the MG to monitor the media stream and analyze its contents and report the results to the MGC (an unacceptable solution); or 2) for the MGC to receive this information from the next hop via the call control protocol on that hop (ISUP/BICC/SIP).  But for case 2) to work, an MGC depends on the chain of switches all the way to the terminating switch to accurately signal this information (equivalent to 183 if it's not ringing tone; 180 if it is) in the backward direction.  One simple example of where this breaks down is when no COT is performed and there is a link failure (i.e. there is no in-band information even while alerting).  In effect, the in-band information tests the media path, providing immediate i!
nformation about the media path to the caller so the call can be abandoned if appropriate.  THIS IS NOT POSSIBLE without having a clear indication in the 180 from the UAS that there is supposed to be in-band progress information.  The current text would have the UAC inject local ringing in the absence of in-band media, while what we really want to do is play silence since there is no media path beyond the UAS anyway!  Many more examples are possible.  Alerting indication (180) does not necessarily mean there is in-band ringing when in-band information is present.  There may be announcements or various tones or nothing, depending on the state of the network.  There is no guarantee that a UAS gateway will have sufficient information to send a 183 if in-band call progress information changes during alerting.
 
In general, I support Mark's analysis of the situation and continue to request an in-band call progress indication for the 180 response.
 
If you are alternately saying that a UAS gateway that cannot guarantee that any in-band call progress information it may be sending is in the form of a ringing tone should send 183 rather than 180 after receiving "subscriber free" or "alerting" indications, then I can also accept this solution.  But then this new guideline must be clearly spelled out in either Gonzalo's draft or RFC 3398, preferably the latter, since a UAS gateway will rarely send 180 once in-band information is available.  I have seen some strong resistance to this in prior emails on this reflector.  We can't have it both ways.
 
Regards,
Richard Ejzak
Lucent Technologies

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Friday, March 07, 2003 12:03 PM
To: 'Mark Watson'; '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: Gonzalo Camarillo <[email-masked]>
Date: Tue, 11 Mar 2003 10:40:05 +0200

Folks,

let me try to summarize our discussions so far and propose a way
forward.

Richard and Mark are asking for an indicator to be placed in 180
(Ringing) responses that indicates whether or not there will be early
media. The idea (and the gain we would get) is that this indicator would
allow us to avoid implementing media detection (especially important in
decomposed gateways).

However, not implementing media detection have some problems when the
call is answered: a UAC is generating local ringback, and the callee
picks up. The first RTP packets arrive to the UAC before the 200 OK for
the INVITE. The UAC can either discard the media until it gets the 200
OK or mix it with the local ringback it was generating until the 200 OK
stops it (the local ringback).

I had claimed that, because of the issue above, you want to implement
media detection anyway. However, Mark has claimed that he knows of some
scenarios where the media gateway will not let any media in until the
200 OK is received. And for those scenarios, a "there is media coming"
indication would be useful for the UAC.

(This is the summary of our discussions so far... below comes my
proposal to move forward)

But we have already such an indication. We do not need to develop any
new parameter. In fact, such an indication was proposed in the first
version of the draft. However, we removed it because of the media
clipping problem. The indication is the direction attribute of SDP.

When you send a 180 (Ringing), you send an answer setting the audio
stream to inactive. When the UAS sends the 200 OK, it sends an UPDATE in
parallel with the 200 OK setting the audio stream to sendrecv again.

The delay is the same as the one achieved with a flag (or an empty
Alert-Info), since the messages are sent in parallel. The number of
bytes is probably higher, but I would not worry about it. And we have
the advantage of not having to implement any new parameter that would
not be understood by old UAs.

Does this meet your requirements?

Below you have a call flow with an announcement followed by local
ringback (180 + inactive stream) and followed by the answer of the call.

          |                                           
|                         |---------------(1) INVITE   
-------------->|                         |                  
a=sendrecv               |               
          |<------(2) 183 Session
Progress-------------|                         |          
a=sendonly                       |                        
|-----------------(3) PRACK----------------->|                        
|                                            |                        
|<-----------(4) 200 OK (PRACK)--------------|                        
|  *                                         |                         |
****************************************** |                        
|*     User B will be with you shortly     * |                         |
****************************************** |                         | 
*                                         |                        
|<------------(5) 180 Ringing----------------|                        
|                                            |                        
|<--------------(6) UPDATE    ---------------|                        
|                   a=inactive               |                        
|                                            |                        
|-------------(7) PRACK--------------------->|                        
|-------------(8) 200 OK (UPDATE)----------->|                        
|                 a=inactive                 |                        
|<-----------(9) 200 OK (PRACK)--------------|                        
|                                            |                        
|                                            |                        
|                                            |                        
|<----------(10) 200 OK (INVITE)-------------|                        
|                                            |                        
|<-------------(11) UPDATE    ---------------|                        
|                   a=sendrecv               |                        
|                                            |                        
|-----------------(12) ACK------------------>|                        
|                                            |                        
|------------(13) 200 OK (UPDATE)----------->|                        
|                 a=sendrecv                 |                        
|  *                                      *  |                         |
****************************************** |                        
|*        Bi-directional conversation       *|                         |
****************************************** |                         | 
*                                      *  |                        
|                                            |               

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