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

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

Gonzalo,

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

The interesting case, of course, is the one you don't list.  If SDP has
been received, and either explicitely says "a=sendrecv" or does not
contain the "a=inactive" nor "a=recvonly", AND the user is being alerted
(180 received).  Do you play local ringback or not?  Both choices are wrong.

Suppose this were not just a "local policy", but instead was mandated
behavior that the UAS could depend on.  How can the UAC and UAS combine
to provide the correct results --- (I'm assuming the UAC doesn't know
in advance whether the UAS will be doing local or remote ringback; if your
crystal ball works, use it, otherwise send SDP offer with "a=sendrecv").
  If the action in this case is to play local ringback:
Consider the case when the UAC places a call to a PSTN gateway, or some
other UAS that intends to do remote ringback.  This case leads to the race, 
between the signaling message (180) and the media.  If the media arrives 
first, then case #1 applies and all is OK. if the signaling arrives first, 
we get locally generated ringback which is then preempted by the remote 
ringback.  Result: bad user experience.
  If the action in this case is to not play local ringback:
Consider the case when the UAC places a call to another SIP endpoint that
does not intend to do remote ringback.  If this "normal" UAS sends SDP
with a=sendrecv and then sends 180, there will be no ringback.  So the SDP
from the UAS needs to be a=inactive.  Now the 180 generates local ringback.
But when the called party answers, the UAS needs to do an UPDATE/200-OK
exchange to change the SDP to a=sendrecv.  This kills the post-cutthrough
delay, and clips the "hello."  Result: bad user experience.

If the UAS included a flag with the 180 that indicates whether it will
be doing in-band-ringback/announcements or not, then the UAC can
do the right thing.  The UAS certainly knows when it will be starting
to transmit media packets; all it needs to do is say so.

Bill Marshall
[email-masked]

p.s.  I really don't think the intricacies of this "local policy" are
covered by the three sentences in isup-05 section 8.2.3 which explain
the "SHOULD generate ringback tone".

-----original message-----
Date: Tue, 13 Aug 2002 16:45:32 +0300
From: Gonzalo Camarillo <[email-masked]>
To: William Marshall <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sipping] new draft-ietf-sipping-isup-05

Hi,

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

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

_______________________________________________
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: Al Varney <[email-masked]>
Date: Tue, 13 Aug 2002 17:25:43 -0500

>(180 received).  Do you play local ringback or not?  Both choices are wrong.

    That's why, in my opinion, a PSTN gateway (ISUP, MF or whatever) should 
never send 180 in the first place.  The PSTN will ALWAYS deliver in-band 
audible ring tone, and I don't see any advantage of ever triggering local 
ringback to a SIP UAS on such calls.  (I was not around for any earlier 
discussion on this topic, so I may be missing some fundamental concept here.)

    The "early ACM" case (section 7.2.5) will work for all ISUP voice 
calls.  SIP callers would then experience exactly what ISDN or analog 
telephone callers experience -- call progress tones from the terminating 
end of the call and no clipping on answer.  Section 7.2.6 and the 
"alerting" state in the state machine in 7.2 could then be 
removed.  (Removing the "alerting" state from 7.2 doesn't constrain the 
behavior of a SIP UAS -- it only simplifies the ISUP gateway).

    ISDN terminals could do local ringback, but I've never observed it (for 
voice calls).  Unfortunately, the ACM indication "subscriber free" is not 
100% synonymous with an audible ring tone being sent in-band.  A subscriber 
line can be free but various conditions can result in a tone/announcement 
rather than ring tone.  The CPG with "alerting" (in 7.2.9) could be used to 
more reliably trigger ISDN local ringback, but since the audio path is 
already established, and the terminating end is always sending ring tone, 
and it only works for ISDN destinations, there is no advantage.  Instead, 
the CPG usually only results in updating an ISDN display.

      Unfortunately, even with this change, mapping of an ISUP CPG with 
"alerting" to a 180 (in 7.2.9) still presents a race condition that could 
trigger local ringback before media arrives.  Since this CPG isn't 
generated on calls to analog lines (and thus cannot be relied on for all 
calls), maybe the 180 indication isn't that useful?

Al Varney

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Aug 2002 10:08:05 +0300

Hi,

> discussion on this topic, so I may be missing some fundamental concept here.)

First, now you DO associate the media with the 180 response code, which I think
is wrong. I think the 180 response code itself simply indicates that the remote
user has been alerted - nothing else. The local/remote ringback, and the early
media, is then a separate issue.

Second, even if the PSTN network always will deliver in-band ring tone, the
gateway MAY choose not to forward it to the SIP network. For example, in a
forking environment it MAY have been configured not to do so, to prevent media
mixing at the caller's node. Or something similar...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 14 Aug 2002 10:55:29 +0300

Bill,

> (180 received).  Do you play local ringback or not?  Both choices are wrong.

I do list this example. It is number 1. There is media coming
(sendrecv), so regardless of the status code that has been received (180
or 183) you do not play local ringback.

If the UAS did not intend to send early media, it should have set the
stream to inactive.

> crystal ball works, use it, otherwise send SDP offer with "a=sendrecv").

Remember that the direction attribute that the UAC sends can be
downgraded by the UAS in the answer (offer/answer model). Therefore,
your UAC does not need a crystal ball at all. The direction attribute to
be used will be the one the answerer chose.

> ringback.  Result: bad user experience.

You cannot change this, whatever flag you use. The UAC sends an INVITE
and suddently it begins receiveing media, without having received any
SIP response besides the 100 Trying from its outbound proxy... what do
you do? No flags will help you in this situation. Again, this is up to
your local policy.

But this is a more general problem. What if I put a call on hold
(a=inactive), but I still receive media... again, what to do is up to my
local policy...

> delay, and clips the "hello."  Result: bad user experience.

The SIP sequence you have described is exactly how you would implement
this scenario using current SIP. IMO, the only thing needed is a
recommendation in the SIP spec saying that you may want to play what you
receive over an inactive stream (at least for a short while) in order to
avoid media clipping. Would you be happy with this solution? (no new
flags are needed).

I believe that this is the best solution to this problem. The flag some
have proposed would have basically the same meaning, so we could save
creating it.

Opinions?

> to transmit media packets; all it needs to do is say so.

The solution I have proposed would solve this problem without the flag.
As I said in previous mails, the flag would save a UPDATE/200 OK
exchange, but the flag is not really needed for solving the problem. The
problem wit the flag you propose is that it breaks the offer answer
model. Right now, the offer or the answer you receive is to be used
"right now". With your flag, you would be sending an answer (or offer)
to be used only when a 200 OK had been received... or even worse, you
would be saying that the UAC should treat the first RTP packet as if a
200 OK had been received. Are you also going to propose to get rid of
the 200 OK, since, at the end of the day, it would not bring extra
info??

I would rather stick to the current approach. That is, by inspecting the
last offer/answer exchange I know what is *currently* going on.

> the "SHOULD generate ringback tone".

It has been said many times, and even in this thread Jon answered this
same question once more. Anyway, the isup-sip mapping draft does not
intend to define every SIP or ISUP mechanism that may be used in an ISUP
to SIP call. We only reference mechanisms that are defined elsewhere.
That's why, for instance, we have not copy/pasted RFC 3261 and Q.767 in
the draft. Early media needs to be defined in the SIP spec, or,
eventually, if we discovered that it is a complex enough problem, in a
separate document... but never in the ISUP SIP mapping draft.

Best regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Aug 2002 11:34:25 +0300

Hi,

> or 183) you do not play local ringback.

One thing there seems to be some disagreements on if sendrecv, indicating we have
a two-way media path, means that there REALLY WILL be early media (eg remote
ringback).

Since we have a SIP header (Alert-Info) indicating an alternative location to get
the ringback tone/information, I don't see why we can't have a flag (or, extend
the use of Alert-Info) to indicate if the UAS sends early media or not. That would
solve some of the stuff we're discussing, and at least I don't think it would
"break" anything :)

> If the UAS did not intend to send early media, it should have set the

Again, that means that a node that...

1) supports PRACK
2) does not want to send early media

...MUST (since the first answer must be sent in the first 18x) send an extra
UPDATE/re-INVITE when the call is accepted.

My question is: Do we really want that???????? IF we want it, I'll accept it and
won't say another word about it :)

Also, this is not a strange thing that almost never will happend - I think this
would affect a huge number of the SIP phones. I am not the correct person to say
this, but I assume many SIP phones support PRACK, but I guess relatively few also
generate remote ringback). I also don't know how many SIP phones support UPDATA,
but those who don't would have to send re-INVITE when the call is answered to,
which is even more "clumsy" than UPDATE for this purpose.

Also, due to the must-buffer-200-until-PRACK-is-received thing, which already may
cause delays, this could add even more delay.

The media clipping issue related to the
what-about-if-media-is-received-before-the-answer problem I think it's difficult
for us to solve on a protocol level. I think the easiest way would be to solve it
on an applicatoin level. The server could for example send the answer a little
before it starts sending media, which would at least reduce the risk of the media
reaching the caller before the SIP message. Or something like that...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 14 Aug 2002 13:14:13 +0300

Christer,

> a two-way media path, means that there REALLY WILL be early media (eg remote

There is no disagreements. If a media stream is sendrecv, you may
receive media at any moment.

All the proposals I hear try to change the meaning of the offer/answer
exchange using a flag, a header field, or whatever... The offer/answer
exchange is intended to give the current picture of the session,
regardless of whether it is an early dialog or a fully established one.

In all your proposals, a header field or flag says that what you see in
the offer/answer is not really valid... but it will be valid when a
certain event happens (namely, the reception of a 200 OK), in the
future. I do not like this coupling.

In addition, you seems to be very worried about sending an UPDATE/200 OK
to make the stream sendrecv at the same time you send the 200 OK for the
INVITE... in the first place, why did you establish early media if you
did not want to send anything? One possible reason is manyfolks, where
you can request sendrecv QoS for an inactive stream, and then make it
sendrecv when you send the 200 OK for the INVITE. Do you have any other
scenario in mind?

Anyway, the extra UPDATE/200 OK is the price you pay for having in synch
the actual media plane and your view of it (offer/answer exchange) at
every momment.

What you are proposing is telling the other end what will happen in the
future, so I can skip sending signalling messages when that event
occurs, and that is not a good idea.

I guess that your way of implementing calls on hold would be to send a
re-INVITE with your flag on, saying: "Now I make the stream inactive,
but when you receive an RTP packet, it will mean that the call is not on
hold anymore, so act as if you had received a re-INVITE making the
stream sendrecv again", and you will save sending the second
re-INVITE... as I said, this seems like a bad idea to me.

I would suggest folks think of general solution for general problems,
rather than thinking of "optimizations" for particular problems.

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Aug 2002 13:49:39 +0300

Hi,

> receive media at any moment.

[CHH] Previously you said sendrecv means that media WILL be sent, and now you say
(which I agree on) that it means media MAY be sent. And, that "MAY" is the problem -
the UAC doesn't know if media will be sent or not, and it MAY need that information to
decide if to generate local ringback or not.

> future. I do not like this coupling.

[CHH] Believe me - I am NOT trying to change the offer/answer exchange. I am (and I
assume others talk about a similar thing, becuase this time I didn't bring this issue
up in the first place :) only taking about adding a flag (or, using the Alert-Info
header) to give the UAC some extra INFORMATION about the early media, ie if early media
is sent or not. BUT, no matter IF early media is sent or not, the state of the media
session is still the same - sendrecv.

> did not want to send anything?

[CHH] If I use PRACK, and send 18x, I HAVE to. It's a MUST - both in the offer/answer
model ("the answer must be sent in the first reliable response") and the PRACK spec.

> One possible reason is manyfolks, where you can request sendrecv QoS for an inactive
> stream, and then make it
> sendrecv when you send the 200 OK for the INVITE. Do you have any other scenario in
> mind?

[CHH] Yes, again - when you use PRACK. Then you MUST send the answer in the FIRST 18x
message - NO MATTER if you are not going to start sending media until the 200 is sent.

I don't know how many times I have said this now... :)

> the actual media plane and your view of it (offer/answer exchange) at

[CHH] As I have said many times, It's not only about sending the UPDATE/200. I also
mentioned delay issues (adding to those we already have because of PRACK) that it could
bring.

> occurs, and that is not a good idea.

[CHH] What am I telling about the future??? The only thing I do is establishing a
two-way media session, and tell/inform the UAC there is no early media sent... :)

> re-INVITE... as I said, this seems like a bad idea to me.

[CHH] That is NOT what I'm saying. It has been said before, in the previous discussion
on this, that the receiving of RTP packets can not always be used to determine if there
is early media or not.

Then, when the call is answered to, the 200 indicates that the call has now been
established, and that the UAC can now expect to receive media. The UAC will not stop
generating any possible local ringback - but that has been the case as long as we've
had SIP, so it's no new functionality related to this...

Anyway, it would be nice to hear what others think. Like I said, if nobody sees all
this as a problem, I don't want to spend time on it, and then I AM ready to accept
everything as it is :) What about those who proposed the flag, and/or (re-)brought up
this whole ringback issue, in the first place?

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Ed Luff" <[email-masked]>
Date: Wed, 14 Aug 2002 11:03:39 -0400

Hi,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Christer Holmberg
> Sent: Wednesday, August 14, 2002 6:50 AM
> To: Gonzalo Camarillo
> Cc: William Marshall; [email-masked]
> > >a two-way media path, means that there REALLY WILL be early media
(eg
> remote
> [CHH] Previously you said sendrecv means that media WILL be sent, and
now
> you say
> (which I agree on) that it means media MAY be sent. And, that "MAY" is
the
> problem -
> the UAC doesn't know if media will be sent or not, and it MAY need
that
> information to

IMO Christer has highlighted the root cause of the issue above, and that
is the issue with the "MAY" statement in the definition of the
offer/answer method, and its affect on specific implementations.

I have been monitoring this email thread, which I believe Jon Peterson
started back on the 9th of August (please correct me if I'm wrong) where
he stated "...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;

IMO, (and granted I have not seen the proposed syntax for the flag), I
believe that if we consider taking this up one level, ie, that instead
of having a flag which explicitly indicates 'ringback', that we instead
consider a flag which changes the current "MAY send/receive early media"
to a "MUST send/receive early media" in regards to sending/receiving
early media.  I am proposing this as I have been intently trying to find
a mechanism for the UAS to tell the UAC to send early media to the
destination described in the offer.

Prior to reading this email thread, I was considering a proposal to
extend the SDP spec, (or SDPng), to include the support of a new
attribute called 'a=recvonly-ping' as the foundation for a mechanism
that would allow the offer/answer method to greatly assist in solving
the firewall/NAT traversal issues in the media plane.

To sum up, I would like to propose that we add a flag, which can be used
to improve the offer/answer method to essentially strengthen the "MAY
send/rcv" early media to a "MUST snd/rec" early media.  The flag would
apply equally to the "sendrecv", "sendonly" and "recvonly" cases.  This
should allow enough flexibility in the offer/answer method to solve a
number of problems that exist due to the vagueness of the current "MAY"
definition. 

Hopefully this is in line with Gonzalo's statement for a "solution for
general problems, rather than thinking of "optimizations" for particular
problems."

Cheers,
Ed
> [CHH] Believe me - I am NOT trying to change the offer/answer
exchange. I
> am (and I
> assume others talk about a similar thing, becuase this time I didn't
bring
> this issue
> up in the first place :) only taking about adding a flag (or, using
the
> Alert-Info
> header) to give the UAC some extra INFORMATION about the early media,
ie
> if early media
> is sent or not. BUT, no matter IF early media is sent or not, the
state of
> the media
> [CHH] If I use PRACK, and send 18x, I HAVE to. It's a MUST - both in
the
> offer/answer
> model ("the answer must be sent in the first reliable response") and
the
> PRACK spec.
> 
> > One possible reason is manyfolks, where you can request sendrecv QoS
for
> an inactive
> scenario in
> [CHH] Yes, again - when you use PRACK. Then you MUST send the answer
in
> the FIRST 18x
> message - NO MATTER if you are not going to start sending media until
the
> 200 is sent.
> mentioned delay issues (adding to those we already have because of
PRACK)
> that it could
> Then, when the call is answered to, the 200 indicates that the call
has
> now been
> Anyway, it would be nice to hear what others think. Like I said, if
nobody
> sees all
> this as a problem, I don't want to spend time on it, and then I AM
ready
> to accept
> everything as it is :) What about those who proposed the flag, and/or
(re-
> )brought up

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 15 Aug 2002 08:56:42 +0300

Hi,

Ed continues:

>...that we instead
>early media. 

I would suggest people to think twice before making statements like
these. Let's say that we are using SIP terminals with silence
suppression, and we establish a sendrecv stream. Now, because I am shy,
I do not say anything... I guess you propose that my SIP terminal pulls
out a gun, points it to my head, and forces me to generate media
packets, because otherwise, I will violate the protocol... I am afraid
we would have many protocol violations in Scandinavia... and maybe not
so many in South Europe ;o)

Believe me. The MAY you are referring to is perfectly fine.

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Aug 2002 09:08:23 +0300

Hi,

> Believe me. The MAY you are referring to is perfectly fine.

I agree with Gonzalo. But, at same time, the MAY is also the problem, and one
of the reasons we're having this discussion in the first place...

Regards,

Christer Holmberg
Ericsson Finland

Ps. Gonzalo, do you use the early media session for talking in South Europe???
In Scandinavia we unfortunatlely have to fully establish the call first, and
then pay for talking ;)

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 15 Aug 2002 09:28:41 +0300

Hi,

> Ps. Gonzalo, do you use the early media session for talking in South Europe???

We usually record long messages in our answering machines, that are
played as early media when somebody calls and we are not home...
however, I do not want to break any protocol if I record only silence as
my greeting message.

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Aug 2002 09:37:20 +0300

Hi,

> however, I do not want to break any protocol if I record only silence as

The point is that IF you still have indicated (using whatever mechanism) that you
will send early media, the client won't generate local ringback. Then, if you have
recorded only silence, the caller will hear only silence. But, if you haven't even
recorded a message (silence or not), you would not indicate you are going to send
early media in the first place...

But, currently, if you open a sendrecv early stream, and since you now MAY send
early media, how is the client to know if you actually will do it or not? It's a
difference in sending an empy message (in which case the caller probably won't hear
anything), and in not sending a message at all (in which case the client most likely
will generate local ringback)

Christer Holmberg
Ericsson Finland

---

From: Michael Hammer <[email-masked]>
Date: Thu, 15 Aug 2002 14:30:16 -0400

All,

I am trying to catch up after having been at the VoIP summit here in 
Washington (the rest of my waking hours spent getting to and from there), 
but have resisted answering until I got to end of thread, but feel the urge 
anyway.

Someone said that 180 should never be sent by a gateway.  Perhaps they were 
looking at only ingress GW to SIP phone.  If you don't have an explicit 
signaling of alerting to the egress gateway, then I have no basis for 
sending an alerting signal out-of-band into the PSTN from the egress 
GW.  Therefore, all alerting better be in-band.

One factor that I have not seen discussed is that in a multi-media 
environment, there can be many media paths in various send/receive 
states.  Taking the egress GW viewpoint, I don't want to be assuming 
anything about what is or is not being sent in-band in the backward 
direction.  The "no-flag" proponents seem to think that I can draw some 
conclusion from such.  I beg to differ.  This making of assumptions based 
on the state of send/receive generally forces the ingress GW to modify the 
type of Offers and Answers that need to be sent, and has a worse influence 
on the Offer/Answer model.

If I have to rely on the state of send/receive to decide things then the 
behavior at the egress GW is simply that if upon receipt of the 180, if any 
or many media streams is at that time active (or transitioned to active by 
SDP in the 180) in the backwards direction, then I generate a call signal 
to the PSTN that alerting is occurring and assume that at least one of the 
media streams carries the in-band alerting.  I inject no signaling, and it 
is up to the destination to stop the in-band signaling (wherever that is) 
when the ANM/200 OK comes through.

Only an explicit indication to inject alerting inband can override 
that.  As I may be serving millions of destination PSTN users, I do not 
expect that there will be any individual local calling party policy.

The signaling is from the called party, so they will be the ones to decide 
if it will be delivered In-band or Out-of-band.  If they intend for the 
alerting to be transmitted out-of-band and then injected in-band at some 
point, then what is injected and that it is to be injected need to be 
signaled.  That is all the proposed flag needs to indicate.  This can not 
be derived by looking in-band.  Upstream nodes toward the calling party 
only need to know (in the case of no in-band alerting) is whether to inject 
anything or not.  Absent any such signaling the default assumption is that 
alerting will be in-band.  Any downstream party that doesn't understand 
that and act accordingly won't drive any alerting back to the calling party.

So the question boils down to does 180 infer only that alerting is 
occurring somewhere, or is it intended to indicate that alerting needs to 
be injected in-band?  I understand that Alert-Infor can indicate that for 
some cases, but perhaps not all.

It has been suggested that a 180 with no backward media cut-through means 
inject ringing.  In that case, I would expect ringing to continue to be 
injected until the 200 OK is received, independent of any subsequent 
Offer/Answers that occur subsequent to start of ringing.  If that is not 
desirable, then one must create some explicit signaling indication prior to 
the 200 OK that tells me to stop ringing.  Again, I don't want to assume 
anything about a potential N media streams.  I don't want to get into 
reading tea leaves.  That is a waste of resources at the MGC.

In general, I agree with Bill Marshall's assessment of this.

Mike