Subject: [Sipping] early media race condition summary

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 15 Aug 2002 14:48:23 -0400

I appreciate this summary of the viewpoints on the list. Two notes:

1) Agreed that the draft that was produced during last call (-05) did not
address this issue (the race condition between early media and local
ringtone on 180) to everyone's satisfaction. However, it is my intention
that the final draft that is released as a result of last call comments will
resolve this issue to the satisfaction of the maximum number of people. No
sipping-isup-06 has been released yet, and when it is released, it will
reflect the outcome of this discussion. If necessary, we will delay the
release of sipping-isup-06 until this discussion has reached a reasonable
conclusion. I'm not looking to sweep anything under the rug, here. However,
if there are parties that are clearly participating in this discussion in
bad faith, and attempting to delay publication of the draft on some agenda
unrelated to its technical merits, I will not hold out to bring them to
consensus.

2) That much said, I believe the local ringtone vs. early media race
condition issue you have raised, Bill, is an important one that was indeed
raised in good faith, and that we should do something to fix it. This
problem is, however, not identical to the general early media problem, and
all of the general early media discussion that has followed has brought us
pretty far off-track. I made a proposal several days ago for a variant on
your option (1). Our discussion is focusing too much, I think, on what 180
or 183 means, or maps to, or something intangible along those lines. The
only practical reality that is of interest is what behavior we can expect a
UAC to exhibit when it receives such codes. 

Our discussion has focused on a proposed indication of whether or not early
media is present - which would seem to entail a need for some new protocol
element (header/response code/etc) that maps to the 'in-band call status'
indicators in ISUP. But I think there's another way around the race
condition: my suggestion is that what we really need is an explicit
indication of whether or not a UAC should begin local alerting or not - and
my contention is that RFC3261 has already defined one. If a UAC receives a
180, RFC3261 encourages the UAC to produce a local ringtone. But if a UAC
receives a 183, that same encouragement is not given. From my mail a few
days ago (I've added the <proposal> tags to highlight the recommended
change):

---

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'). <proposal> 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). </proposal> 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.

---

This fix for the race condition does not require any changes to the behavior
of all UACs - it works only off the guidance given RFC3261. Anything the
requires us to create new headers, or define new behaviors for old headers,
would require an extension that would need to be supported by any UAC that
might send a call to a gateway. In my opinion, a mechanism that required an
extension to talk to gateways would introduce a severe limitation to SIP-T.
This fix is also completely orthogonal to the issue of whether a UAC is a
gateway or a vanilla SIP phone, it should work equally well either way. This
fix does not change the semantics of 183 at all - it does not 'use the 183
as an indicator that early media is present', it merely states the rather
obvious fact that 183 does not instruct a UAC to begin local alerting, which
was the problem that Bill actually raised.

I'd also note that I still feel that whatever fix we apply to
sipping-isup-06 (if any) should not interfere with the development of a
future early media extension. I don't feel that this suggested 180/183
behavior has any potential to interfere in this fashion. My suggestion above
does not provide a generic early media solution - it is a fix for the
specific race condition raised by Bill. Let's fix early media elsewhere.

Based on what we know now, I think that the fix I describe above for this
race condition is the right fix. I intend to install it in sipping-isup-06.
If you have any comments or concerns about this problem and proposal (as
opposed to general ruminations on early media, etc), please provide them
soon-ish.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: William Marshall [mailto:[email-masked]]
> Sent: Thursday, August 15, 2002 6:08 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: [Sipping] new draft-ietf-sipping-isup-05
> 
> 
> Summary of this thread so far:
> 
> There seems to be general agreement that there is a problem with
> preempting/generating local ringback in the current isup-05 
> draft, and 
> that the alternative of clipping the media after answer is worse.
> There seems to be general agreement that this is a direct result
> of offer/answer when combined with PRACK and manyfolks, and the 
> interpretation of "a=sendrecv" as it pertains to alerting.
> 
> The sheer number of messages in this thread clearly indicates that
> the current draft did not resolve the comments on the subject
> during the last-call process.
> 
> Aside from a statement of several to just "get this draft out", there
> are three solutions proposed:
>   0)  do nothing and ignore the problem
>   1)  use a 183 instead of 180 if in-band ringback will be sent
>   2)  include a flag in the 180 if in-band ringback will be sent
> 
> And some comments appearing on the list relating to these three
> solutions (apologies in advance if I missed or mis-stated any 
> positions):
> 
> Bill Marshall wrote:
> > A "solution" that results in clipping the initial conversation is so
> > fundamentally broken that it doesn't deserve consideration at all.
> [and note that my original solution was choice #2]
> 
> Brian Rosen wrote:
> > I like the explicit Alert-Info much better than inferring it from
> > 183 vs 180 or other indirect mechanisms.
> 
> Christer Holmberg wrote:
> > 			My concerns are the idea of
> > 200/UPDATE, and also (which has been discussed before) the MUST of
> > buffering 200 before a PRACK has been received, and those 
> things I DO
> > think shall be solved on a protocol level.
> and
> > So, whatever solution we'll go for (if we'll go for any 
> solution at all...) 
> > I think it's important that we define it so it really only 
> affects gateways 
> > (and, of course, other nodes which may want to send early 
> media ... )
> 
> Jon Peterson wrote:
> > I am willing to put something that is roughly option
> > (1) in sipping-isup-06. It will appear in a few days.
> 
> Gonzalo wrote:
> > I have a big problem with (1). 
> [remainder of Gonzalo's arguments appear to be in favor of choice #0]
> 
> Al Varney wrote:
> >     Everyone:  We all want to finish this document.  While 
> I had some 
> > unease regarding the text in Draft-03 and -04, it is only 
> with Draft-05 
> > that the early media text made ISUP interworking problematic 
> ...
> >     In other words, in my opinion, Draft-04 worked with the 
> PSTN, and 
> > Draft-05 doesn't.
> 
> Anjan Bose wrote:
> > I agree that the more explicit the notification is, the 
> better. Having 
> > 	Alert-Info: <data:audio/basic;base64,AAAAAA>
> > as an indicator, is better than none, but how about having the
> > following as an indicator that the terminating subscriber's 
> line is ringing
> > and that in-band ringback is going to be sent:
> > 	Alert-Info: <data:audio/basic;in-band-ringback>
> 
> John Elwell wrote:
> > At present the QSIG draft maps a QSIG ALERTING to a SIP 180 
> response and
> > vice versa. I would not be happy with solution 1), ...
> 

_______________________________________________
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: David Oliver <[email-masked]>
Date: Thu, 15 Aug 2002 15:01:39 -0500

Jon,

Comments inline...

<...>
> Our discussion is focusing too much, I think, on what 180
> or 183 means, or maps to, or something intangible along those lines.
> The only practical reality that is of interest is what behavior we 
> can expect a UAC to exhibit when it receives such codes. 

Hopefully, the UAC will do something consistent with 3261 et al.

> Our discussion has focused on a proposed indication of whether or not
> early media is present - which would seem to entail a need for some
> new protocol element (header/response code/etc) that maps to the
> 'in-band call status' indicators in ISUP. But I think there's another
> way around the race condition: my suggestion is that what we really
> need is an explicit indication of whether or not a UAC should begin
> local alerting or not

Agreed.

> - and my contention is that RFC3261 has already defined one. If a UAC 
> receives a 180, RFC3261 encourages the UAC to produce a local ringtone. 

Here I disagree: "SHOULD" would encourage; "MAY" merely permits without
preferred any particular behavior.

> But if a UAC receives a 183, that same encouragement is not given. 

No permission is given, implicitly discouraging local ringback, which could
make way for early media. However, 183 does not necessarily indicate that
the equipment is actually attempting to alert the called user (c.f. the POTS
case, where ringback indicates that ring voltage is being applied to the
user's line), at least without additional headers. It would seem natural to
use 183 to indicate that, like 182/182, a more indirect attempt is being
made to contact the callee (e.g. "your party is being paged"), than by
ringing the user's phone.

<...>

Regards,

David C. Oliver
Principal Engineer
SecureLogix Corp
Email: <mailto:[email-masked]>
Tel:   +1.210.402.9669
Fax:   +1.210.402.6996

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 15 Aug 2002 17:11:51 -0500

Brief notes below.

Jon Peterson
NeuStar, Inc.

> From: David Oliver [mailto:[email-masked]]
> Sent: Thursday, August 15, 2002 1:02 PM
> To: 'Peterson, Jon'; 'William Marshall'; [email-masked]
> Subject: RE: [Sipping] early media race condition summary
> 
> 
> Jon,
> 
[snip]
> preferred any particular behavior.

Well, let's be fair - the passage (21.1.2) is very brief, and the ONLY
guidance given about handling the code whatsoever is that MAY. I think it is
also pretty universally acknowledged among telephony implementers that this
is the behavior when a 180 is received. I speak to this further in my '180
MAY ring?' note.

> ringing the user's phone.

The only problem here that I am aware of is the possible race condition
raised by Mr. Marshall. Again, I'm not trying to provide a general early
media solution, I am trying to solve the race condition (when a 180 is sent
at the same time as backward early media). Agreed that 183 does not indicate
that the PSTN is trying to alert a user - when in-band status information is
available on the PSTN side, that does not mean that any equipment is
actually attempting to alert any called user (the tones/announcements
provided could be anything... the gateway probably has no idea). In-band
status information could be a busy signal, for example. My proposal is to
map unknown in-band status information to 183, right? 183 is for generic
'Session Progress', not 'a more indirect attempt is being made to contact
the callee'.

It doesn't sound to me like you're disagreeing with my proposal... or if you
are, I don't understand how.

---

From: David Oliver <[email-masked]>
Date: Fri, 16 Aug 2002 10:15:07 -0500

Jon,

More brief(?) notes below.

Regards,
 
David O.

> From: Peterson, Jon [mailto:[email-masked]]
> Sent: Thursday, August 15, 2002 5:12 PM
<...> 
> > From: David Oliver [mailto:[email-masked]]
<..> 
> > Jon,
> > 
> [snip]
> > Here I disagree: "SHOULD" would encourage; "MAY" merely 
> > permits without preferred any particular behavior.
> > 
> 
> Well, let's be fair - the passage (21.1.2) is very brief, and 
> the ONLY guidance given about handling the code whatsoever is 
> that MAY. I think it is also pretty universally acknowledged
> among telephony implementers that this is the behavior when 
> a 180 is received. I speak to this  further in my '180
> MAY ring?' note.

I like brief passages: they tend to be unambiguous :-). I guess the logic
becomes "Don't expect early-media sent with a 180 to be delivered because
the response MAY have been to generate local ringback".

<...>

> In-band
> status information could be a busy signal, for example. 

I would hope that a 486/600 Busy Here/Everywhere would accompany a busy
signal or message. This would avoid duplicating the types of problems modems
have when calling a (South Western Bell operated) busy line, receiving a
voice-only message suggesting paying for a ringback service, and keeping the
line busy trying to connect with the announcement. (Some providers, such as
BT, overlay voice announcements with the standard tones, which lets machines
and people work with them).

> My proposal is to
> 'Session Progress', not 'a more indirect attempt is being 
> made to contact the callee'.

My issue with using 183 is that the unknown in-band status (ringback) is
accompanied by known out-of-band status (alerting), which is not conveyed
back to the user's client. This could defeat automated dialers such as used
by tele-marketers' (this could be a good justification!). Assuming 183
implies alerting could limit other possible uses.

> It doesn't sound to me like you're disagreeing with my 
> proposal... or if you are, I don't understand how. 

I will agree with any proposal that allows for the following three
situations to be distinguished (without resorting to tea-leaves):

1. Alerting: MAY play local ringback
2. Alerting: media conveys further information (e.g. remote ringback)
3. Other Session Progress: Body, headers or media MAY convey further
information (e.g. paging, waiting for conference bridge, waiting for
satellite to cross horizon...)