Subject: Re: [Sipping] new draft-ietf-sipping-isup-05

From: William Marshall <[email-masked]>
Date: Tue, 13 Aug 2002 09:30:30 -0400 (EDT)

Gonzalo wrote:
> Right now, the status code of the response (e.g., 180 or 183) indicates
> what is going on, and the session description indicates if there is
> media coming from the other end.

I think the point that has been made several times is that this is not
the case, and that the UAC does not have sufficient information to make
the correct decision - whatever the local policy.  And, in the most common 
case of SIP-ISUP mapping, following the procedures given in isup-05, that 
decision is likely to be wrong.

Bill Marshall
[email-masked]

-----original message-----
Date: Tue, 13 Aug 2002 13:35:58 +0300
From: Gonzalo Camarillo <[email-masked]>
To: Michael Hammer <[email-masked]>
Cc: "Peterson, Jon" <[email-masked]>,
        "'William Marshall'" <[email-masked]>, [email-masked]
Subject: Re: [Sipping] new draft-ietf-sipping-isup-05

Hi,

When thinking about solutions for early media and local vs remote
ringback generation, we should not try to replicate ISUP.

SIP systems have many ways to indicate that someone is being alterted.
They can play ringback, but they can simply display a message on the
screen or on a pop-up window, or they could vibrate, or flash in red or
whatever...

Right now, the status code of the response (e.g., 180 or 183) indicates
what is going on, and the session description indicates if there is
media coming from the other end.

With these two pieces of information, it is a matter of local policy
what to do regarding the GUI. I do not want the callee to master my SIP
terminal telling when it should play ringback and when not. For example,
if the callee is being alterted (180 has been received) and no media has
been established, it makes sense to play local ringback... but this may
not be the only choice my terminal has. The final decision should be up
to its local policy.

I believe that adding new parameters to indicate remote vs. local
ringback could reduce the number of messages exchanged, but I do not
think they would provide information that we cannot convey using RFC
3261 right now.

Regards,

Gonzalo

Michael Hammer wrote:
> 
> Jon,
> 
> This is a short-hand interpretation of what I think you are saying.  Please
> correct me if this is not in line with your words:
> 
> (The yes/no refers to an event indication of alerting.  I assumed that
> downstream more switches are involved.  Backward (upstream) flow is left to
> right)
> 
> ISUP    GW1 SIP    GW2 ISUP
> ACM/no  ->  183    ->  ACM/no
> CPG/no  ->  183    ->  CPG/no
> CPG/yes ->  180    ->  CPG/yes
> GW2 applies local ringing,
> upstream switch connects backward media containing ringing
> 
> ending #2:
> CPG/yes -> 180/SDP -> CPG/yes
> GW1 and GW2 connect backward media containing ringing
> upstream switch connects backward media containing ringing
> 
> ending #3:
> CPG/yes -> 180/Alert-Info -> CPG/yes
> while GW2 fetches .wav file or whatever and injects it inband,
> upstream switch connects backward media containing
> announcement/music/ringing, etc.
> 
> What I understand you are pointing out is that SDP can be delivered
> earlier, but that in itself should not indicate ringing and should not
> cause the event=alerting to be sent.
> 
> In all cases the 180 message is sent based on event=alerting, and causes
> event=alerting to be sent, in ACM or CPG messages.  Upstream switches
> receiving event=alerting causes them to do backward cut-through.
> 
> SDP can arrive at any time, but does not affect event=alerting.  Absence of
> SDP with 180 requires GW2 to inject ringing.
> 
> Just trying to follow the pathology.
> 
> Mike
> 
> At 02:26 PM 8/12/2002 -0500, Peterson, Jon wrote:
> 
> >"... completely within rfc3261." Well, we can all read section 20.4 of
> >RFC3261 and judge for ourselves - I'm not interested in arguing this point
> >at great length, but I feel that if we want a header that is an explicit
> >(rather than implicit, overloaded and non-interoperable) indication that
> >early media will or will not be played, that header is not Alert-Info.
> >Telling a phone to play silence as an alert tone could have any number of
> >semantics (like, override any early media with this silence - I'm sure some
> >proxies, which can add Alert-Info at their discretion, would find this
> >interpretation useful). We would want a new header that was created for this
> >purpose.
> >
> >Any fully-featured early media solution will require an extension to SIP,
> >and in the process of defining that extension any new header(s) could be
> >specified as necessary to provide an explicit indication of whether or not
> >early media will be provided. SIPPING-ISUP is however not the place to
> >define or frame that extension.
> >
> >The specific problem that you've raised is the race condition in the UAC
> >between playing early media on receipt of backwards-direction RTP and
> >playing local alerting tones on receipt of a 180. Short of defining some new
> >extensions/headers, if we need to recommend anything in SIPPING-ISUP, I
> >would rather we return to the familiar 180/183 distinction. Today, RFC3261
> >says that when 180 is received, a UAC MAY generate a local ringback, but no
> >similar hint is offered for 183. We could use 183 in SIPPING-ISUP not to
> >indicate explicitly that early media is going to be transmitted, but rather
> >just to provide a provisional response that does not explicitly instruct the
> >UAC to generate a ringtone (which makes sense since in these in-band media
> >cases the gateway has no indication of whether or not some remote phone is
> >in fact 'ringing'). When the gateway receives indications of in-band audio
> >from the ISUP side, it could send such a 183 (presumably without SDP,
> >although with an encapsulated ACM/CPG as appropriate). While some unusual
> >SIP phones might nevertheless generate local ringback on receipt of 183
> >(anyone on the list do that?), at least RFC3261 doesn't tell them to do so.
> >
> >It might also make sense to recommend that gateways which support no early
> >media extension begin transmitting backwards media before sending a 18x
> >response when ISUP states that provisional in-band information is present.
> >
> >Essentially, both of these measures would combat that race condition. Would
> >this be okay for now? With the understanding that fully-featured early media
> >systems in the future will attack this problem more directly?
> >
> >Jon Peterson
> >NeuStar, Inc.
> >
> > > -----Original Message-----
> > > From: William Marshall [mailto:[email-masked]]
> > > Sent: Saturday, August 10, 2002 8:53 PM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: [Sipping] new draft-ietf-sipping-isup-05
> > >
> > >
> > > Jon Peterson wrote:
> > > > Alert-Info is intended to contain a URL that points to some
> > > sort of sound
> > > > file that a UAC would download and then play as an
> > > alternative ringtone.
> > > > While I'm not necessarily opposed to the idea of having
> > > some explicit
> > > > indication of whether or not a UAC should generate local
> > > ringback when it
> > > > receives a 18x, I don't think we should overload Alert-Info for this
> > > > purpose. ...
> > >
> > > If the PSTN G/W were to insert the following header in the
> > > 180-Ringing:
> > >
> > >   Alert-Info: <data:audio/basic;base64,AAAAAA>
> > >
> > > it would be completely within rfc3261; the sound file is
> > > contained inside
> > > the URL, and consists of mu-law silence.  When the media
> > > starts arriving, it
> > > preempts this locally-generated "ringback".  No overloading
> > > needed at all.
> > >
> > > > I would note that the pre-emption of ringback with tones
> > > and announcements
> > > > can occur in many PSTN interworking scenarios, so while it
> > > is undesirable, I
> > > > wouldn't go so far as to say it's unacceptable as a user experience.
> > >
> > > While I agree that preemption of ringback by a tone or
> > > announcement can
> > > occur (like in 0.1% of calls), using this as an excuse to
> > > break the other
> > > 99.9% ....
> > >
> > > While it would certainly be possible to require gateway
> > > vendors to insert
> > > the above Alert-Info header in their 180-Ringing response, and thereby
> > > fix the problem, it would be preferred if there was a somewhat more
> > > intuitive indication of what is expected.
> > >
> > > Bill Marshall
> > > [email-masked]
> > >
> > > -----original message-----
> > > From: "Peterson, Jon" <[email-masked]>
> > > To: "'William Marshall'" <[email-masked]>, [email-masked]
> > > Subject: RE: [Sipping] new draft-ietf-sipping-isup-05
> > > Date: Fri, 9 Aug 2002 14:08:07 -0400
> > >
> > > The purpose of the early media clarifications in isup-05 was
> > > more to prevent
> > > the text from interfering with any more fully-featured early
> > > media system,
> > > rather than proposing such a system in detail. The pre-05 text was
> > > wrong/unhelpful, and as it stands a gateway will at least do what any
> > > RFC3261 user agent could be expected to do.
> > >
> > > Alert-Info is intended to contain a URL that points to some
> > > sort of sound
> > > file that a UAC would download and then play as an
> > > alternative ringtone.
> > > While I'm not necessarily opposed to the idea of having some explicit
> > > indication of whether or not a UAC should generate local
> > > ringback when it
> > > receives a 18x, I don't think we should overload Alert-Info for this
> > > purpose. In any event, I think explicit ringback tone
> > > indicator would be a
> > > good thing to propose a part of a comprehensible,
> > > fully-featured early media
> > > system; I suspect that this functionality might require a bit more
> > > consideration before it is fully-baked.
> > >
> > > I would note that the pre-emption of ringback with tones and
> > > announcements
> > > can occur in many PSTN interworking scenarios, so while it is
> > > undesirable, I
> > > wouldn't go so far as to say it's unacceptable as a user experience.
> > >
> > > Jon Peterson
> > > NeuStar, Inc.
> > >
> > > > -----Original Message-----
> > > > From: William Marshall [mailto:[email-masked]]
> > > > Sent: Friday, August 09, 2002 6:22 AM
> > > > To: [email-masked]
> > > > Subject: RE: [Sipping] new draft-ietf-sipping-isup-05
> > > >
> > > >
> > > > The latest version of this draft has gone a long way toward
> > > > consistency with the offer/answer model of rfc3261, thereby
> > > > allowing integration with the additional procedures for
> > > preconditions,
> > > > and resolving the in-band vs. local ringback issue.  However, I
> > > > don't think it is there yet.
> > > >
> > > > With in-band ringback there is a race condition with the 180-Ringing
> > > > provisional response; the UAC may receive the 180 response and
> > > > start a local ringback, then start receiving media and preempt it
> > > > with the in-band ringback.
> > > >
> > > > This is not an acceptible user experience.
> > > >
> > > > The UAS in this case knows that it will be generating a media
> > > > stream as soon as it sends the 180, so it could clearly indicate
> > > > this in the signaling message.  I believe use of 183 instead of 180
> > > > was discussed in Yokohama, but isup-05 stayed with 180.
> > > >
> > > > I'd like to propose a convention on use of the Alert-Info header
> > > > in a 180-Ringing response, where one particular value of the header
> > > > parameter indicates to the UAC that in-band media will be coming
> > > > and that it should not start a local ringback.  This approach seems
> > > > completely backwards compatible with all existing systems, and
> > > > those that understand the convention can do the proper thing.
> > > > Other solutions solicited.
> > > >
> > > > Bill Marshall
> > > > [email-masked]
> > > >
> > > > _______________________________________________
> > > > 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
> 
> _______________________________________________
> 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: Gonzalo Camarillo <[email-masked]>
Date: Tue, 13 Aug 2002 16:45:32 +0300

Hi,

> the correct decision - whatever the local policy. 

The status code tells you whether the user is being alerted or not. The
direction attribute tell you whether or not you can expect media from
one stream (you will use UPDATE to change the direction attribute).

In which scenarios you are lacking information in order to make the
right decision?

Your local policy could look like this:

1) If there is media coming from a stream, play it (don't play local
ringback), regardless of the status of the callee (alerted or not).

2) If there is no media coming from any stream (they are all inactive or
sendonly or no SDP has been received) AND the user is being alerted (180
has been received) play local ringback.

3) If there is no media AND the user is not being alerted, do nothing.

Regards,

Gonzalo