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

From: "Mark Watson" <[email-masked]>
Date: Tue, 11 Jun 2002 15:29:35 +0100

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.

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

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.

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.

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 ?

Regards,

Mark

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: 11 June 2002 09:27
> To: [email-masked]
> Subject: [Sip] Local vs Remote ringback on 180
> 
> 
> 
> Hi,
> 
> Bis-09 only talks about local ringback tone generation when 180 is
> received. The ISUP-SIP draft defines that a remote ringback tone is
> generated if the 180 contains an SDP message body.
> 
> However, with the new answer/offer rules, direction indicators
> (sendrecv, inactive etc) manyfolks model etc, I wonder if such
> assumption really works. There may be situations where a node 
> must/must
> not/want/doesn't want to include SDP in 180 - no matter the ringback
> tone.
> 
> Bis-09 defines two headers, Alert-Info and 
> Content-Disposition, but the
> way they are currently defined I don't think they can be used for this
> purpose either.
> 
> There probably are some ways to get around this, eg by using 
> re-INVITEs
> and/or UPDATEs, but I really don't think that's what we want to do....
> 
> Comments?
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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: Fri, 14 Jun 2002 12:01:11 -0400

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:

> 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
> (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)
>

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.
>

Again, I thought there was a distinction between 180 and 183 here ?

> 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.

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 15 Jun 2002 00:53:41 +0300

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Jun 2002 18:22:21 -0400

> negotiated in your media stream(s)), whereas with 183, you do not

Egads, this is all getting out of hand.

First off, the 180 is an indication from the UAS that the called party 
is being "alerted" for some definition of alerted (screen pop, ring, 
etc.). How that information is used at the UAC is a matter of user 
interface. Last I checked, SIP didn't specify user interfaces. It merely 
says that you can do the obvious thing, which is play a local ringback.

> Again, I thought there was a distinction between 180 and 183 here ?

The offer/answer exchange defines the flow of media in a session, and 
that is irrespective of the response code it appears in. The response 
code provides status updates about the UAS. That is orthogonal to the 
offer/answer model.

> bidirectional codec support without accepting early media in both

You are making a distinction between early media and regular media, when 
there isn't and shouldn't be one. This was the real idea behind the 
unify model. If I offer you to receive media, that means, I am willing 
to receive media, period.

> make a distinction here, but it got removed for some reason.

For good reason. The reason was that manyfolks was trying to be 
"special" and outside of the general offer/answer model. That is no 
longer the case. By making it all fall under the general offer/answer 
model, a lot of things became easy (like integration with 3pcc), since 
we only had one model, rather than a dizzying number of them (once you 
added in early media too, which was also special for a while. No longer).

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2002 08:47:27 +0300

Hi,

> says that you can do the obvious thing, which is play a local ringback.

I'm not sure it's that easy eg when we talk about a SIP/PSTN gateway, because
it's not only about how the GW informs the caller but also how the MG handles
the media.

Chapter 7.2.3 of draft-ietf-sipping-isup-02.txt says:

"If the reception of a `180 Ringing' response without media
description, the MG generates the ringback tone to be heard by the
caller.

If the MGC receives any 1xx response (except 100)  with a session
description present for media setup, it sets up the session being
described.  The call progress media (e.g.  ringback tone or
announcement) is generated by an entity downstream (in the SIP
network or by a PSTN exchange in SIP bridging situations)."

As a general rule, for a basic SIP implementation, I assume this works fine.

My original issue, however, was if this really works in more advanced
scenarios. There may be situations, due to offer/answer negoatiations,
manyfolks, and/or PRACK for which we must include an SDP in a 180 response,
which really hasn't anything to do with the ringback.

My other issue was, what happens if we have received a 183 with SDP, ie
early-media may be established, and then we receive a 180 without SDP? Again,
for normal UACs this may not be a big problem, but for a GW it may. The GW
doesn't know if the UAS will stop transmitting early-media, and wants to GW
to generate a local ringback tone, or if the UAS will continue transmitting
early-media, and only wants to GW to indicate that the called party has been
alerted.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Jun 2002 02:54:08 -0400

> which really hasn't anything to do with the ringback.

This is purely an issue for PSTN interop. If there is a session 
established, there is a session. Playing local alerting makes no sense. 
Therefore, I would suggest that the sip-isup draft recommend that local 
ringback be used only if the session is not established yet.

> for normal UACs this may not be a big problem, but for a GW it may.

See above.

  The
> GW

I can't imagine a case where a PSTN gateway receives a call, and 
generates a 18x with SDP to establish an early session (presumably 
because there is media in the circuit in the reverse direction), and 
THEN decides it needs the calling gateway to generate local ringback.

-Jonathan R.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2002 10:19:22 +0300

Hi,

> ringback be used only if the session is not established yet.

This would probably work fine in most cases, especially when the UAC receives
the early media and the 180 from the same node. Later in this mail I describe
a scenario where this may not work.

> >The GW doesn't know if the UAS will stop transmitting early-media, and
> wants to
> >GW to generate a local ringback tone, or if the UAS will continue
> >transmitting early-media, and only wants to GW to indicate that the called
> party has
> >been alerted.
>

I am not sure how it will work on the PSTN side, but let's assume the
following SIP scenario.

I try to call my boss. I reach the company "switch" (which, I guess, in this
case has be implemented as some kind of SIP B2BUA) which sends me a 183 (with
SDP) and start transmitting early media telling me that I have now reached
this company, please wait, press this button for this, press that button for
that etc etc etc. Then, the switch "forwards" the INVITE to the actual SIP
phone I'm calling to. Now, this SIP phone is not able to generate any early
media at all, so it sends a 180 (without SDP). Now I assume the switch could
only forward the 180 to the caller (via the PSTN GW), stop transmitting the
early media, and expect the PSTN GW to generate a local ringback tone, since
the called party has been reached.

Now, one can argue that this is a complicated scenario, which has nothing to
do with the basic SIP etc etc. BUT, from the caller's point of view this is a
normal session setup. It receives the 183 (with SDP) and 180 (without SDP)
within the same dialog, and has no idea what is happening at the remote site.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 19 Jun 2002 11:22:50 -0400

> says that you can do the obvious thing, which is play a local ringback.

So to be clear: There is no requirement to send back a 180 when the far-end
is providing in-band ringback. By virtue of the fact that the offer allowed
media to be sent to the UAC, we can simply start sending in-band ringback,
irrespective of which response code was sent back last (say 183 etc. in case
we had used manyfolks).

> to receive media, period.

The trouble is, that in some QoS enabled environments (PacketCable for
example), you don't want to allow use of bidirectional media until the call
is answered (and charging starts), however you want to make sure that
bidirectional media can in fact be supported (succesful codec negotiation)
before alerting the called party. How do you solve this with the tools at
hand ?

-- Flemming

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Jun 2002 08:21:23 +0300

Hi,

> irrespective of which response code was sent back last (say 183 etc. in case

We should remember that the remote party may also be a GW, so "dropping" ISUP
messages (ie not map them to a specific 18x response) will affect the ISUP/SIP
mapping, and the ISUP transparency (ISUP MIME) mechanism.

Regards,

Christer Holmberg
Ericsson Finland

> hand?

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 20 Jun 2002 08:48:02 -0400

----- Original Message -----
From: "Christer Holmberg" <[email-masked]>
<snip>
> within the same dialog, and has no idea what is happening at the remote
site.
The RTP session is controlled by SDP offers and answers. If a session is
established, there would need to be a new offer/answer exchange to change
it. Stopping the RTP flow because the 180 does not have SDP is the wrong
thing to do. Scenarios like this can be done with the UPDATE method which
allow the UAS to change the session. The UAS is explicitly forbidden from
sending subsequent offers in 18x responses (bis-09 line 2119), but it could
send them in UPDATE requests.

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 20 Jun 2002 08:38:56 -0400

----- Original Message -----
From: "Flemming Andreasen" <[email-masked]>
> irrespective of which response code was sent back last (say 183 etc. in
case
That does not seem correct to me. There is no way for the signaling layer to
know that there is in-band ringback. The only standard mechanism to tell the
caller that the calling party is being alerted is the 180 response. The
signaling layer does know whether or not the session (RTP) has been
established. If one has not been established when the UAC receives the 180,
it MAY generate ringback locally. If a session is established, the fact that
there is no SDP in the 180 does not change that.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Jun 2002 00:26:01 +0300

Hi,

> send them in UPDATE requests.

First, I agree that the UAS is forbidden from sending a subsequent offer in a
18x, and I also think that using something like
UPDATE for this purpose is too "expensive".

However, let's assume the following thing: we do NOT update the session.

So, if the UAC receives a 183 with SDP an early session can be established, and
there MAY be early media - nobody says there MUST be early media. Then, when the
UAS sends 180 without SDP the session still exists from a signalling point of
view, but the UAS indicates that I will stop sending early media and wants the
UAC to generate a local ringback tone. I don't think this idea would break any
rule, would it (the session still exist, but the UAS simply indicates it won't
send any early media - even if it would be "allowed" to do so from a SIP point
of view).

Then, if the UAS for whatever reason is going to start transmitting early media
again, it could send eg a new 183, with the same SDP as in the previous 183.
Again, this SDP would not be a new offer, simply an indication that the GW
should stop generating local ringback, and start "passing" the RTP media to the
PSTN side again (in general, eg in a PSTN GW case, even if we have an early
media session established between the GW and the UAS, the GW may still, for
whatever reason, choose NOT to send any media to the PSTN side...).

How does this sound?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Jun 2002 00:29:35 +0300

> there is no SDP in the 180 does not change that.

Like I wrote in the other mail, even if the session is established, the UAS
could use the 180 without SDP to indicate that it will not send any early
media/local ringback, and that the UAC should generate a local ringback tone,
until another response, provisional or final, is received.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 20 Jun 2002 18:16:45 -0400

----- Original Message -----
> > > I try to call my boss. I reach the company "switch" (which, I guess,
in
> > this
> > > case has be implemented as some kind of SIP B2BUA) which sends me a
183
> > (with
> > > this company, please wait, press this button for this, press that
button
> > for
> > > only forward the 180 to the caller (via the PSTN GW), stop
transmitting
> > the
> > > Now, one can argue that this is a complicated scenario, which has
nothing
> > to
> > > do with the basic SIP etc etc. BUT, from the caller's point of view
this
> > is a
> > > within the same dialog, and has no idea what is happening at the
remote
> send any early media - even if it would be "allowed" to do so from a SIP
point

How does the UAS tell the UAC that it will stop sending media without
updating the session description? A 180 does not mean that the UAS will stop
sending media. What you are proposing would require that the meaning of 180
change and then the UAC would be required generate local ringback (it MAY
now). Or are you proposing that there will be additional info in the
response that will tell the UAC the media will stop? Either way it is not
backward compatible with either 2543 or bis-09. Also, there would be two
mechisms to do the same thing.

> whatever reason, choose NOT to send any media to the PSTN side...).

I'm sorry, I really do not like it because it changes the way session state
is maintained. I think is is much cleaner to do session state maintenance in
a consistent way with SDP offers and answers. I don't agree that using
UPDATE is too expensive. The 2 extra messages would only happen in scenarios
where you need to stop or change the media.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 20 Jun 2002 21:41:23 -0400

> until another response, provisional or final, is received.

Details aside, I agree that if there is a way to have locally generated ringback
replaced by far-end ringback, there must also be a way to have far-end ringback
replaced by locally generated ringback. I also agree that this should all be
driven by signaling.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 20 Jun 2002 13:24:47 -0400

> there is no SDP in the 180 does not change that.

How do you define "RTP session establishment" ? Are you saying, that if the
INVITE contains an offer to receive media, and the 180 includes an answer to
send media, then this is by definition an indication of early media and hence
there shall not be any local ringback ?

-- Flemming

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Jun 2002 13:42:29 +0300

Hi,

Bob Penfield wrote:

> sending media.

It DOES indicate that the UAC may/should/whatever generate local ringback, so my
proposal was that it at the same time shoud indicate that the UAS is not sending
early media -. again, even if the session on a SIGNALLING level remains
unchanged.

> What you are proposing would require that the meaning of 180 change and then
> the UAC would be required generate local ringback (it MAY
> now).

The UAC would not be required to play ringback. The text bis can still remain as
"MAY play ringback tone". That would be an implementation issue (also, the
decission can be based what kind of node the UAC is, where in the network it is
situated etc etc etc), but the main point is that the UAC would be aware that
remote early media/ringback is NOT sent.

> Or are you proposing that there will be additional info in the response that
> will tell the UAC the media will stop? Either way it is not

My original question WAS if the SDP is a good way to indicate local/remote
ringback in the first place, but that is really not related to my proposal above
(where I do assume that the SDP is still used as a ringback indicator).

> >Then, if the UAS for whatever reason is going to start transmitting early
> >media again, it could send eg a new 183, with the same SDP as in the previous
>
> >183. Again, this SDP would not be a new offer, simply an indication that the
> GW
> >should stop generating local ringback, and start "passing" the RTP media
> >to the PSTN side again (in general, eg in a PSTN GW case, even if we have an
> >early media session established between the GW and the UAS, the GW may still,
>
> >for whatever reason, choose NOT to send any media to the PSTN side...).
> >
> > How does this sound?
>
>
> a consistent way with SDP offers and answers.

I don't think it changes the session state. The session still remains (like I
said earlier, just because we have a session it doesn't mean that media MUST be
sent). The UAC would simply choose not to forward any possible media received
(if the UAS, even if it sent 180 without SDP still for whatever reason sends
media) to the listener (to the PSTN network in the case of a GW).

> I don't agree that using UPDATE is too expensive. The 2 extra messages would
> only happen in scenarios

I still don't understand why I would have to update the signalling session state
just because I choose not to send early media at some stage...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Jun 2002 13:47:58 +0300

Hi,

> replaced by locally generated ringback. I also agree that this should all be

I agree. I don't think it's a good idea to make the decission based on received
media (RTP packages). Even if the UAS stops sending early media, and wants the 180
to generate local ringback, it may still send comfort noise eg, which the media
handler can not separate from "real" media. When the UAC recieves 180 without SDP it
MAY simply choose not to "forward" the RTP packages to the listener, and instead
generate local ringback. Again, from a SIP signalling point of view the session
changes unchanged, though.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 21 Jun 2002 11:59:15 -0400

OK, one last time, then I will shut up. This is my opinion/understanding of
how this should work based on bis-09, offer/answer, 100rel, and update
drafts.

There are 2 layers here. The SIP messages control the state of the
dialog(s). The SDP contained in the SIP messages control the state of the
multimedia session.

When a UAC has made an SDP offer and received an SDP answer that indicates
that the UAS is sending one or more streams, then the UAC can expect to
receive RTP packets on the accepted streams. This is independent from which
SIP messages the SDP is in.

If the answer was contained in a reliable provisional response, a subsequent
response without SDP does not affect the state of the multimedia session as
established by the previous offer/answer.

Therefore, a reliable 183 with the SDP answer will establish the multimedia
session. A subsequent 180 without SDP does not change the state of that
multimedia session. It simply indicates that the called party of the
"dialog" is being alerted. The UAC should still be ready to receive RTP on
the previously accepted streams. It cannot assume that the UAS has stopped
the media flow. The only mechanism defined in the specs for the UAS to
indicate that it will stop sending media is an UPDATE with a new offer.

Now, as the whether the UI on the UAC actually plays the received RTP, I
agree that this is an implementation issue since the specs do not define
UIs.

cheers,
(-:bob

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

----- Original Message -----
From: "Christer Holmberg" <[email-masked]>
To: "Flemming Andreasen" <[email-masked]>
Cc: "Bob Penfield" <[email-masked]>; "Jonathan Rosenberg"
<[email-masked]>; "Mark Watson" <[email-masked]>;
<[email-masked]>
Sent: Friday, June 21, 2002 6:47 AM
Subject: Re: [Sip] Local vs Remote ringback on 180

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 23 Jun 2002 13:19:50 +0300

Hi Bob,

> OK, one last time, then I will shut up.

I'll TRY to do the same :)

If people think this is not worth discussing I will assume it's all
implementation issue and stop the thread. IF people want to discuss it more,
maybe we can do it private, and/or in Yokohama?

> This is my opinion/understanding of how this should work based on bis-09,
> offer/answer, 100rel, and update
> drafts.
>

Agree.

> established by the previous offer/answer.

If you mean that it doesn't change the state from a SIP signalling point of view
I still agree :)

However, if you mean that it doesn't change what is sent to the listener either
I think what is written in some drafts is wrong. It IS said (at least that is my
understanding) that SDP/no-SDP in 180 DOES indicate if a remote ringback tone
will be generated or not.

> the previously accepted streams.

I never said it shouldn't accept media - I simply said the UAC could choose not
to play that media to the caller, and may instead choose to generate a local
ringback tone. Again, from a SIP point of view the early session is still
"active".

> It cannot assume that the UAS has stopped the media flow.

Well, this is where you hit the orginial question of this thread :)

So, we can NOT have a way to indicate there there will be no "useful" media
(again, the session IS active and unchanged, and the UAS CAN still send RTP
packages), and that we instead will have to change the whole signalling state of
the session?

> The only mechanism defined in the specs for the UAS to

I agree, but I think that that is a separate issue. I am not talking about
making "forbidding" the UAS to send early media (ie changing the media mode to
"inactive", or something similar), I am simply talking about indicating that the
possible media is of no interest, that the UAC MAY choose not to play it to the
caller, and that the UAC MAY choose to generate a local ringback tone.

> agree that this is an implementation issue since the specs do not define

I agree it could be an implementation issue, but in that case I wonder why the
bis-09- and ISUP/SIP mapping drafts talk about SDP in 180 and ringback tone
generation in the first place the way it is written now... I am just proposing a
clarification on that.

Regards,

Christer Holmberg
Ericsson Finland