Subject: Re: [Sip] Local vs Remote ringback on 180

From: "Alexeitsev, D" <[email-masked]>
Date: Mon, 1 Jul 2002 17:29:54 +0200

Hello

a comment inline

Greeting,
Denis Alexeitsev

> -----Ursprüngliche Nachricht-----
> Von: Christer Holmberg [mailto:[email-masked]]
> Gesendet am: Freitag, 28. Juni 2002 18:53
> An: Chris Hogg
> Cc: Flemming Andreasen; Jonathan Rosenberg; Mark Watson; [email-masked];
> Bob Penfield
> Betreff: Re: [Sip] Local vs Remote ringback on 180

However, there is no specific "remote ringback session" in SIP. You establish a generic early dialiog, by sending an offer and receiving an answer,

[DA]As the offer/answer draft says: one "MUST be prepared to receive media" after the sending of the offer, so it does not require for UAC to receive an answer in order to start the media playback (as the early media, in my understanding, always come from the UAS i.e. ringback tone, announcement,... and not other way around)

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Bert Culpepper" <[email-masked]>
Date: Mon, 1 Jul 2002 13:30:22 -0400

comments inline...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Alexeitsev, D
> Sent: Monday, July 01, 2002 11:30 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sip] Local vs Remote ringback on 180
>
>
> Hello
>
> a comment inline
>
> Greeting,
> Denis Alexeitsev
>
> However, there is no specific "remote ringback session" in
> SIP. You establish a generic early dialiog, by sending an
> offer and receiving an answer,
>
> [DA]As the offer/answer draft says: one "MUST be prepared to
> receive media" after the sending of the offer, so it does not
> require for UAC to receive an answer in order to start the
> media playback (as the early media, in my understanding,
> always come from the UAS i.e. ringback tone, announcement,...
> and not other way around)
>

We want the UAC to render received media once it's sent an offer to
prevent clipping.  We need this, it causes an unacceptable user
experience if we don't do this.  In addition, we don't want to require
the UAS to provide "call progress" media, we have the 180 for it to
indicate the callee is being alerted, the UAC can convey this state to
the caller through local ringback or whatever.  It's been
proposed/discussed/and I believe there's consensus that a UAS will send
183 (or 180 recently) with SDP when it intends to present media that
should be rendered to the caller.  (Now this is not required of the UAS
but it is "polite" in that it informs the UAC of its intentions.)  The
expected UAC behavior is for it to stop "ringback" indication at this
point.

Now there's the case when the UAS is doing something more with the
session, and stops sending media to the UAC.  In this case, the caller
will not see/hear any "call progress".  What's being asked for now is
clarification on how to "ask" the UAC to again generate call progress
indication.  It's been suggested that another 18x without SDP indicate
this scenario.  As Christer indicated, there are some I-Ds that describe
this behavior.  There was a period in time where there seemed to be
consensus in the WG on this.  However, offer-answer, unify, ... I-Ds
have since come along that more rigorously define "early dialogs",
meaning of SDP, etc.  And again, the presence of SDP in 18x has nothing
to do with when a UAC should generate or expect session progress
indications.  AFAIK, it's not possible in SIP to indicate to a UAC that
it should stop rendering media and go back to local generation of
progress indication.  Nor do we want to try to do this in SIP.

IMHO, services/applications that will generate early media and then stop
have the responsibility to make the caller's user experience acceptable
(i.e., by playing an announcement, music, or whatever).  In Christer's
B2BUA example, the B2BUA's UAC assumes the responsibility to provide
call progress indication to its user (which is another UAC).

We should only recommend that a UAC generate a local indication upon
receipt of a 180 and then stop upon receipt of media (which it should
render).  Services such as Christer's example must take it upon
themselves to provide an acceptable user experience.  Otherwise we add
complexity to the protocol and degrade both interoperability and user
experience.

This is what I'd propose be the "official" clarification.  My 2 cents
anyway.

Regards,
Bert

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 02 Jul 2002 10:29:30 +0300

Hi Bert,

Great mail! Thanks!

> expected UAC behavior is for it to stop "ringback" indication at this

[CHH] True. But, this is the case where the UAC first generates local
ringback, then starts receiving remote early media, and the case
I've brought up is the oposit.

Also, what you wrote was very much true until the media mode indicators
(sendrecv, inactive etc) were introduced to SIP. Now, if a UAC sends an
INVITE with "inactive", is it still a MUST for the UAC to be able to receive
media at that point? One of the reason to use "inactive" was to PREVENT
early media, so...

> this behavior.

[CHH] To clarify, the drafts I refer to is bis-09 and the ISUP/SIP mapping
draft.

> There was a period in time where there seemed to be consensus in the WG on
> this.  However, offer-answer, unify, ... I-Ds
> indications.

[CHH] True, and that is the reason I asked if the SDP as an ringback
indicator (which it IS used as in some drafts) is a good idea in the first
place. Like Bert said, those drafts were written long before anyone had
heard of any offer/answer rules etc...

> AFAIK, it's not possible in SIP to indicate to a UAC that

[CHH] If that is the case, the text in the drafts I refered to should be
rewritten. I guess what you propose is:

"When the UAC receives the 180 it does the ringback decission based on if
there is an early media session established, and the state of it (sendrecv,
inactive,...) - NOT based on if there is a SPD in the 180 or not (of course,
the SDP in 180 may be the SDP used to establish the early media session, but
that is a separate issue)."

> call progress indication to its user (which is another UAC).

[CHH] If that's fine with those who are going to build/use such
applications, it's fine with me :) I assumed, however, that people don't
want the B2BUA to generate ringback tones on behalf of the SIP phones...
And, I also think it could be a relatively common SIP application, so I
don't think we're talking about a strange and weird scenarios...

> complexity to the protocol and degrade both interoperability and user

[CHH] I don't think the UAC shall "stop upon receipt of media". If the UAS
starts sending media, it shall also send a 18x with an answer to the offer
sent in INVITE to establish an early media session (or, an UPDATE it the
early session already exists, but in "inactive" mode).

I also would like to get a clarification if the offer/answer rules in bis-09
"allow" us to establish an early media session by sending the answer in an
unreliable 18x?

> This is what I'd propose be the "official" clarification.  My 2 cents

[CHH] That's what I asked for :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bert Culpepper" <[email-masked]>
Date: Tue, 2 Jul 2002 14:34:49 -0400

Hi Christer,

more of my comments below...

> media at that point? One of the reason to use "inactive" was

Yes, the ability to now use "inactive" changes things.  But if a UAC
indicates "inactive" then there is no means to send the corresponding
media streams.  And the caller then can not see/hear far-end media-based
progress indications.

> heard of any offer/answer rules etc...

I've glanced through bis-09 for a discussion on UAC behavior for 18x and
didn't find anything on when or when not to generate ringback locally.
The SIP/ISUP I-D describes this for PSTN gateways.  Being that that I-D
is dealing with PSTN interworking (where the far end typically provides
audible call progress indications) a convention is needed that addresses
when local vs. far-end call progress indication is needed.  I'm a little
behind in my SIP-ISUP reading but I think the precedures described
therein apply to PSTN gateways and not general SIP UAs.  Also, PSTN
interworking is a distinct enough scenario that additional semantics
(for 180 vs. 183 and presence of SDP) are OK (but only as far as
gateways are concerned).

> that is a separate issue)."

Again, I didn't find this kind of discussion in bis-09.  I myself think
some guidance (as you suggest above) would be helpful in a some I-D.
Otherwise we have to debate this aspect on mailing lists :)

> don't think we're talking about a strange and weird scenarios...

Well, I think the B2BUA has to "manage" the callee in this case, given
the absence within the protocol to tell a UAC to generate ringback (in
the general case).  I think it would be a useful capability but doubt
attaching additional semantics to SDP presence and/or 180/183 is the way
to do it.  Currently it's only a MAY in bis-09 that a UAC generates
local ringback upon receipt of a 180 anyway.

> early session already exists, but in "inactive" mode).

Again, AFAIK a UAS can send media to the UAC after receiving the UAC's
SDP.  No response is required to be sent back to the UAC.  Sending a
response with SDP is the "polite" thing to do IMHO as it's an explicit
indication that the UAS will send media (and allows RTP/RTCP to "work").

I believe UAC behavior here is an largely an implementation issue, and
what I said are my views on what will provide an acceptable user
experience in the general case.  If the SIP WG wants to define
"operational semantics" for some protocol scenarios I'm OK with that.
The subject of this thread is a good one IMHO, and I remember a time
when this was discussed.

> "allow" us to establish an early media session by sending the

My read indicates answers MUST be in a reliable response, which is only
200 in bis-09.  This is stated pretty clearly IMHO.  I'm not sure what a
"early media session" is but if you want to complete the offer-answer
exchange prior to sending/receiving a 200 OK, then there's the 100-rel
extension (as I'm sure you're aware :).

Best regards,
Bert

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 03 Jul 2002 16:09:58 +0300

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

---

From: "Bert Culpepper" <[email-masked]>
Date: Thu, 4 Jul 2002 10:18:25 -0400

Hi Christer,

comments below.

> that's the only way SIP allows us to do it I am not going to

I agree with you.  But with what's written in bis-09 and other I-Ds
there's no guarantee on what the UAC will do with this sequence of
messages as far as rendering session progress.  I believe the issue here
is how to provide a good user experience and as long as the UAC presents
some indication of what's going on in the signaling the user shouldn't
get confused.

> (used to put media on hold), which means there is again a

Well, I believe the purpose of UPDATE is to modify session state prior
to the INVITE transaction completing.  Given this, I would say UPDATE
transactions have to complete before the INVITE transaction completes.
And yes, there is a chance of clipping here.  So to prevent this, if the
UAS only indicates that it will stop sending media the UAC will still
render received media if/when it arrives.  Some additional session
update is needed anyway to have the UAC send its media to the new
destination right?  This seems to be a case of 3pcc where we need the
UAC to *not* change its SDP during these transactions.

Regards,
Bert