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

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 6 Mar 2003 19:09:24 -0500

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]]
> 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]]
> 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]]
> [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. 
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 Mar 2003 10:48:03 +0200

Folks,

I agree with Jon that we should not encourage people to send in-band
ringing tones, but I also agree with Mark that this issue has
re-surfaced a number of times already. The message we want to get
through is that adding a SIP flag for resolving that issue offers little
or no value.

I am willing, if people agree, to add some text saying why it is not a
good idea to add a SIP-layer flag to 180 responses indicating that media
is coming.

What about a section along these lines:?

2.2.1 Problems with SIP-layer Indications in 180 Responses

As stated above, it is not an easy task for a UAC that receives a 180
(Ringing) response to decide whether it should generate local ringback
or it will be receiving early media. At first sight, it may seem that
adding a "there is media coming" indication to 180 (Ringing) responses
would facilitate the task of UACs. Upon reception of a 180 (Ringing)
response with such an indication, the UAC would not generate local
ringback. However, such an indication would offer little or no gain.

The only scenario where such an indication would be applicable is when
the UAS sends a 180 (Ringing) response and starts sending early media
right away. If the UAS intended to send early media at a later time,
instead of right away, a sensible local policy for the UAC could be to
generate local ringback in the meantime. Therefore, the "there is media
coming" indication would be useless.

Assuming, then, that the UAS sends the 180 (Ringing) response and the
first media packets in parallel towards the UAC, we have a race
condition. If the media packets arrive at the UAC before the 180
(Ringing) response, the "there is media coming" indication will not
provide any further information to the UAC.

The only situation where the UAC could benefit from that indication is
when the 180 (Ringing) response arrives before the first media packets.
The UAC could avoid generating local ringback for an instant before the
first media packets arrive. However, the same result can be achieved in
a much simpler way (without protocol extensions) by just having UACs
always delay the generation of local ringback for a short period of
time. The UAC can, for instance, generate a short beep upon reception of
the 180 (Ringing) response (this is already done by some
circuit-switched mobile terminals) and one second later start generating
local ringback if no media have been received during that period.

\motivation{Note that adding such an indication does not keep UACs from
implementing media arrival detection either, since they have to
implement it anyway to cover other scenarios, like the race condition
between the 200 OK for the INVITE and the first regular media packets).}

Opinions?

Gonzalo

---

From: Michael Hammer <[email-masked]>
Date: Fri, 07 Mar 2003 11:40:14 -0500

Gonzalo,

So the sequence is:

1) Receive 180, beep, wait 1 second,
    if media,    play media,
    if no media, play local ring-back.

2) While playing local ring-back,
    if media arrives, cut off local ring-back and play media.

Rationale for step 2:  Absent this, there is a race condition between 200 
OK and real media (versus in-band signals) leading to temporal clipping.

Mike