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

From: Adam Roach <[email-masked]>
Date: Fri, 14 Jun 2002 18:42:33 -0400

No.

No, no, no, no, no.

If you know there is user alerting going on, use 180.

Sending 183 and playing in-band ringback is not a
generally acceptable solution; you're overriding
the calling party's user interface's rendering of
"remote party is being alerted." Their client may
very well not render this using audio at all.

Think of the interactions between abusing 183 this
way and, say, a deaf user.

/a

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Friday, June 14, 2002 16:54
> To: Flemming Andreasen
> Cc: Mark Watson; [email-masked]
> Subject: Re: [Sip] Local vs Remote ringback on 180
> 
> 
> 
> Hi,
> 
> I'm also curious about 183. Both bis-9 and the ISUP/SIP mapping draft
> mention only 180 for generating ringback tones - local or 
> remote. The issue
> here, I guess, is that we don't distinguish between remote 
> ringback and
> whatever early media - for which I guess(?) 183 CAN be used.
> 
> And, what about if there are SDPs in other 18x responses?
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> Flemming Andreasen wrote:
> 
> > I've been struggling with this too - it would be nice with 
> an update to
> > the unify draft (or something else) that explains how 
> everything works
> > between bis, manyfolks, update, and offer/answer.
> >
> > Mark Watson wrote:
> >
> > >
> > >
> > > Christer,
> > >
> > > As I understand it, the current situation is as follows:
> > >
> > > From the point of view of the UAC (assuming an SDP offer 
> in the INVITE
> > > for simplicity), then if
> > > (i) an SDP answer is received before the 200 OK of the 
> INVITE (e.g. in
> > > 183, 180 , UPDATE, 200 OK to UPDATE etc.), and
> > > (ii) a=sendrecv or a=sendonly in this answer, and
> > > (iii) any manyfolks pre-conditions have been met (i.e. 
> this could be
> > > an answer at the end of several offer/answer exchanges 
> negotiating and
> > > updating preconditions)
> > >
> > > then there is Early Media, and the UAC SHOULD (?) play this to the
> > > caller.
> > >
> >
> > Will this be the case irrespective of whether you got a 180 
> or a 183 ?
> > My understanding was, that if you get a 180, then you will generate
> > local ringback until you receive RTP (or whatever else you may have
> > negotiated in your media stream(s)), whereas with 183, you do not
> > generate local ringback.
> >
> > As an aside, I personally worry about the robustness of 
> this coupling
> > between signaling and presence of a single RTP packet.
> >
> > >
> > > If there is no Early Media, or if the Early Media is on hold (SDP
> > > answer contains a=recvonly or a=inactive) AND a 180 has 
> been received,
> > > then the UAC SHOULD (?) play local ringing.
> > >
> > > So, if the UAS does not want to generate Early Media then 
> it has the
> > > following choices:
> > > (a) do not supply SDP answer until actual call Answer, or
> > > (b) supply early SDP answer with a=recvonly or a=inactive
> > >
> >
> > Again, I thought there was a distinction between 180 and 183 here ?
> >
> > >
> > > Now, (b) is not much use to a UAS trying to negotiate media with
> > > pre-conditions, since the direction attribute in this 
> exchange will
> > > affect the resources that are reserved, and therefore 
> needs to reflect
> > > the requirements of the eventual session.
> >
> > I don't think that's necessary, since manyfolks has its own 
> direction
> > attributes independent of the media stream direction 
> attributes. Thus
> > you could specify an inactive stream and require sendrevc 
> reservation
> > for it. What is not clear however, is how a UAC can negotiate
> > bidirectional codec support without accepting early media in both
> > directions.
> >
> > >
> > > Therefore it would need to place the media on hold *after* the
> > > pre-conditions have been met, using an UPDATE.
> > >
> > > A workaround at the UAC for dealing with a UAS which did 
> not do this
> > > is that, even if the offer/answer has been completed with 
> a=sendrecv
> > > the UAC pays attention to whether any RTP packets are 
> actually being
> > > received - if there are none, then it generates local ringing.
> > >
> > > Unfortunately, such a workaround is not really applicable 
> to one class
> > > of UACs for whom local ringing is quite important, namely 
> distributed
> > > PSTN to SIP gateways (consisting of Media Gateways and a 
> Media Gateway
> > > Controller as per Megaco model). This is because the 
> information about
> > > presence/absence of actual RTP packets is only available 
> at the media
> > > layer (MG) which does not make decisions for itself about 
> issues such
> > > as tones/announcements/inband ringing.
> >
> > That can be addressed pretty easily by defining the proper 
> event(s). The
> > question is how robust this whole sceheme is in the first 
> place though.
> >
> > >
> > > So, I can only hope that all UAS developers implementing 
> Manyfolks are
> > > aware of the need to put the media on hold as soon as the
> > > pre-conditions have been met (unless thay are going to 
> generate real
> > > Eraly Media).
> > >
> > > A solution to this would be a way of explicitly indicating at the
> > > SIP/SDP layer that a media stream, although not on hold, was
> > > 'provisional', or did not contain actual media yet. I did 
> not think
> > > the Content-Disposition in Manyfolks has formally been given this
> > > meaning. If it has, I'm not sure what 'undoes' this 'provisional'
> > > status - it shouldn't be the 200 OK to the INVITE because 
> the whole
> > > point of UPDATE was to separate media changes from 
> session changes -
> > > so it would have to be another offer/answer without the special
> > > Content-Disposition. But then are people aware they need 
> to do this at
> > > Answer time ?
> > >
> >
> > We used to have a Content-Dispostion of "precondition" in 
> manyfolks to
> > make a distinction here, but it got removed for some reason.
> >
> > -- Flemming
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Flemming Andreasen <[email-masked]>
Date: Sun, 16 Jun 2002 18:43:20 -0400

> very well not render this using audio at all.

Could you point me to where in SIP this is stated ? Also, how come the unify
draft (in Figure 10) contains an example that explicitly uses 183 for inband
ringback ? The call-flows draft shows this as well.

> way and, say, a deaf user.

I would assume that most deaf users would be using a relay or transcoding
service of some kind (e.g TDD) rather than having a plain old audio
telephone conversation, and hence I'm not sure it makes much difference in
that case.

-- Flemming

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Jun 2002 15:24:24 +0300

Hi,

Assume that the UAC receives an 183, including an SDP, and the UAS may start
sending early media (eg an announcement). After that the UAC receives 180 from
the same UAS, WITHOUT SDP. Now, according to the spec the UAC should generate a
local ringback tone. However, in this case the UAC would stop forwarding the
early media because it received a 180 without an SDP (it did not receive an SDP
with "inactive" mode).

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 17 Jun 2002 09:02:47 -0400

Line 4560 says "The UA receiving the INVITE is trying to alert the user. The
response MAY be used to initiate local ringback".

Thus from a call signaling state point of view, the UAC does not consider
the caller "alerted" unless it sees a 180. A UAC that renders any sort of
visual indication of ringing would not do so with a 183.

The spec says the 180 MAY initiate local ringback, not SHOULD. It seems to
me that if the UAC receives SDP in either a 183 or 180 and there is RTP
flowing, then it should play that RTP to the caller. The caller will hear
whatever the UAS is sending. It does not matter that it is ringback or other
audio.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Flemming Andreasen" <[email-masked]>
To: "Adam Roach" <[email-masked]>
Cc: "'Christer Holmberg'" <[email-masked]>; "Mark Watson"
<[email-masked]>; <[email-masked]>
Sent: Sunday, June 16, 2002 6:43 PM
Subject: Re: [Sip] Local vs Remote ringback on 180

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 17 Jun 2002 09:05:48 -0400

----- Original Message -----
From: "Christer Holmberg" <[email-masked]>

> local ringback tone.

Its say MAY, not SHOULD.

> However, in this case the UAC would stop forwarding the

Why would it do that? If the offer/answer has completed and there is an RTP
flow established, it would continue unless there was another SDP
offer/answer exchange. The session state (of the RTP) is not tied to call
signalling state in this way.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Jun 2002 23:04:45 +0300

Hi,

> >Assume that the UAC receives an 183, including an SDP, and the UAS may
> >start sending early media (eg an announcement). After that the UAC receives
> >180 from the same UAS, WITHOUT SDP. Now, according to the spec the >UAC
> should generate a local ringback tone.
>
> Its say MAY, not SHOULD.
>
> >early media because it received a 180 without an SDP (it did not receive
> >an SDP with "inactive" mode).
>

True. However, if the UAC would generate a local ringback tone it probably
wouldn't like to mix it with the early media sent by the MGC. My understanding
is that the SDP in the 180 really doesn't have anything to do with the
offer/answer mechanism to do as such - it simply indicates if the UAC
may/should/whatever generate a local ringback, or if remote ringback will be
generated.

However, if I do receive a 180 without SDP, AFTER I've received a 183 WITH SDP,
I would like to be sure that the remote party will not continue generate remote
ringback/early media. IF the remote party does that, the SDP should be included
also in the 180.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Jun 2002 23:08:04 +0300

Hi,

> whatever the UAS is sending. It does not matter that it is ringback or other

My issue now is when the UAC receives 183 (with SDP) AND 180 (no SDP) - a rather
normal(?) scenario, I'd say.

I do understand the differences in 183 and 180 from a signalling point of view.
I think the possible early media (including remote ringback) is the issue.

Thanks for your comments!

Christer Holmberg
Ericsson Finland