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

From: Michael Hammer <[email-masked]>
Date: Mon, 12 Aug 2002 16:48:01 -0400

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 13 Aug 2002 13:35:58 +0300

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

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Aug 2002 15:34:09 +0300

Hi,

> media coming from the other end.

[CHH] A while ago there was a LONG discussion about this early media issue. To my
understanding the conclusion then was that it was NOT a good idea, and there were
reasons for that, to use the session description in 180 as such as an indicator if
there is media coming or not (of course the SDP in 180 can be used to establish an
early-session, used to send early media, but that is independent of the response
code). Don't know if what we agreed on ever was put down on paper, though...

> not be the only choice my terminal has. The final decision should be up

[CHH] Correct. But, a 183 with SDP may have been received, and an early session
have been established. Then a 180, without SDP, may be received, but since an early
session have been established they UAC can make a local policy decission if to
generate local ringback or not. Maybe that's what you meant, but in that case I
understood you wrong :)

[CHH] Below is a copy of the last (I think) mail of the previous discussion, where
I tried to come up with some kind of conclusion :)

--------------

>
>Hi Bert,
>
>As a conclusion to this discussion my proposal for a clarification would be
>that the local ringback generation depends on if a early media session has
>been established or not when the 180 arrives.
>
>And, IF a UAS sends early media, and then wants the UAC to generate local
>ringback, it first have to put the early media on hold, using UPDATE, then
>send 180 (the UAC MAY now generate local ringback, since there is no early
>media), and when the called party answers the UAS will first send a new
>UPDATE, to un-hold the media, then send 200 for the INVITE. I still think
>this process is very messy, and "much pain for little gain", but since
>that's the only way SIP allows us to do it I am not going to argue against
>it :)
>
>I still would like to get a clarification on the
>"UPDATE-and-buffering-of-200) issue I brought up, though :) Personally I see
>no reason why to buffer the 200, but the UAS may have to buffer the second
>UPDATE (used to un-hold the media) until it has completed the first UPDATE
>(used to put media on hold), which means there is again a chance of media
>clipping.
>
>Now, as Bert mentioned, the UAS may start sending early media without
>indicating it (sending 183 with SDP), and then still send 180 without SDP
>even if it sends early media, so in that case I guess there is a risk the
>local ringback WILL get mixed with the early media (but, we can get early
>media mixing in forking scenarios, anyway) - UNLESS the UAC is able to do
>some decissions based on detected media (I don't think that would work very
>well, but it's up to each implementor to decide for him/herself).
>
>Or, does anyone have another proposal?
>
>Thanks!
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland
>

--------------

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 13 Aug 2002 15:49:16 +0300

Christer,

> there is media coming or not 

I did not say that the presence of SDP indicates that there is early
media. I said that information about media is in the session
description. If you use SDP, this information will most likely be in
form of a=recvonly/sendonly/inactive attributes.

In short, what I said is that we do not need a flag saying that ringback
has to be produced locally or remotely. We have already information
about the status of the remote party (e.g., 180 The Callee is being
Alerted) and status about the media (a=inactive means that there is no
media coming). With these two pieces of information, our UA can make a
decision about what to do with its GUI.

Of course, having a flag will save you some traffic at establishment
time, no doubt about it.

> generate local ringback or not. Maybe that's what you meant, but in that case I

Yes, you understood me wrong. If the first 183 contained a=inactive, UAs
will typically play local ringback upon reception of 180.

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Aug 2002 16:09:04 +0300

Hi,

> form of a=recvonly/sendonly/inactive attributes.

[CHH] True. It may also be sendrecv, though, and the problem here is that that still
doesn't tell if there will be early media or not. But, we agreed that that is a problem,
which need to be fixed at some stage, but that it isn't related to the ISUP/SIP mapping.

> decision about what to do with its GUI.

[CHH] Again, my understanding is that sendrecv doesn't necessary mean there will be media
either :)

> Of course, having a flag will save you some traffic at establishment

[CHH] I think it would be useful to have a flag, or something similar (I have talked
about that earlier too, and I also gave a proposal on adding this kind of indicator in
the caller preferences draft), but I agree that it doesn't need to be in the ISUP/SIP
mapping draft. We shall just make sure that the draft doesn't define any MUSTs that would
make it difficult to define such a flag later :)

> will typically play local ringback upon reception of 180.

[CHH] Again, the UAC MAY play local ringback even if the first 183 contained a=sendrecv.
I don't think sendrecv means you MUST send early media. HOW the UA then makes the
decission is dependent on local policy, and the problem is that there is a risk of mixing
of the local- and remote ringback. But, which was also said in the conclusion mail, we
have a similar mixing problem in a forking environment too, so...

We should also remember (this was mentioned by someone during the previous discussion)
that the UAS MAY start sending early media without sending any 18x at all (the draft says
that a UAC shall be able to receive media after the INVITE is sent, so...).

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 13 Aug 2002 16:23:39 +0300

Christer, 

the sendrecv attribute in SDP means that you intend to send AND receive
media on that stream. If there is not going to be media, it should not
be sendrecv. I do not quite understand your confusion.

About a UAC being ready to receive early media after sending the INVITE,
it solves the race condition that occurs when the first RTP packet
arrives before the answer (in a 1xx or 2xx response). However, it is not
intended to be used to send early media without sending an answer. This
creates problems with RTCP, for instance.

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 13 Aug 2002 16:38:08 +0300

Christer,

> Yes, there ARE ways (using UPDATE for example) to first set the mode to
> inactive/sendonly, and then change the mode to sendrecv when the called
> party answers, but those methods are very "heavy"

OK, now it seems that you understood my previous messages. A flag would
reduce traffic, but it will not add new information.

It is good to keep in mind that such a flag would be an optimization,
not an enabler of things that cannot be done today.

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Aug 2002 16:34:22 +0300

Hi,

> be sendrecv. I do not quite understand your confusion.

Of course there will be media, but maybe not until the called party answers
the phone and starts talking...

The problem is that there are cases (if PRACK is used for example) where the
UAS is not allowed to wait until the 200 to send the SDP - it MUST be sent
in the first 18x - no matter if there will be early media or not.

Yes, there ARE ways (using UPDATE for example) to first set the mode to
inactive/sendonly, and then change the mode to sendrecv when the called
party answers, but those methods are very "heavy", and nobody mandates you
to use those. You also have a serious media clipping risk there, and sending
the UPDATE before the 200 OK would cause even more final response buffering
than we alreday have...

> creates problems with RTCP, for instance.

Yes, but is it really clearly said that a UAS MUST send 18x before it starts
sending early media? I did that assumption during the previous discussion,
but I don't think everyone agreed, so...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Aug 2002 16:53:14 +0300

Hi,

> not an enabler of things that cannot be done today.

I never said otherwise :)

Please note, however, that it can't be done with a implementation not
supporting UPDATE. Yes, you can send 200 OK, then wait for ACK, and then send
a re-INVITE to set the media to sendrecv - but is that really a realistic
option?

Regards,

Christer Holmberg
Ericsson Finland