Subject: [Sipping] sipping-isup-05 -> -06

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 19 Aug 2002 08:27:02 -0400

Well, I certainly wasn't expecting such a huge response when I asked the
list to take a look at sipping-isup-05. But given that there were
significant changes between sipping-isup-03 and -05 due to IETF Last Call
and the IESG responses, I'm really glad that the SIPPING WG could mobilize
for a thorough review on short notice and after the official conclusion of
last call. Based on these comments, we have a couple of important amendments
that capture these last corrections.

First, on the advice of Al Varney, Mark Watson and others we are reversing
our recommendation on the setting the interworking indicator in the FCI and
BCI parameters. We now believe that the interworking indicators, if set
improperly, could significantly impede SIP-ISUP transparency. The
interworking indicators, originating access indicators and ISDN user part
indicator bit mappings are therefore revised in 7.2.1.1, 7.2.6 and 8.2.3 to
reflect our improved understanding.

Second, Bill Marshall pointed out that our changes to the previous early
media text introduced the possibility of a race condition arising when
locally-generated ringtone was produced at around the same time as backwards
media is received. Accordingly, we have amended this text in 7.2.6 and 8.2.3
to reintroduce the 183 response code as the code that should be sent when
locally-generated ringtone is undesirable or inappropriate.

Third, thanks to Mike Pierce's eternal vigilence, the Security
Considerations have been enhanced in a few respects. We now mention that a
tel URL in a SIP mesage could contain values (including the telephone number
and the CIC) which in some networks should not be selectable by an end-user
- a combination of authentication with proper policies could prevent
unauthorized usage. Similar text on policy is attached to the cause code
paragraph. The text on optionally disallowing backward media until ANM now
mentions clipping. Last but not least some words have been added to the end
about port saturation.

Finally, a few smaller editorial changes will also be introduced, thanks to
comments received on the list and in private. One particular fix of note is
the removal of the mention of Q.767 from Section 2.

Thanks again to the group for an overwhelming response and for sage advice.
At this point, the WG chairs tell me the draft will resume IESG review and
we can expect results from the IESG soon. So I think we need to view this as
far as we can take these discussions for the time being. Once we've gotten a
little more operational experience under our collective belts, we can
revisit the recommendations of this document and enhance as necessary.

Jon Peterson
NeuStar, Inc.

_______________________________________________
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: Mon, 19 Aug 2002 09:42:42 -0500

>revisit the recommendations of this document and enhance as necessary.

    Fair enough.  I'll wait a bit to send my response to your "Al Varney on 
early media" comments, since it won't be affecting the Draft-06 
content.  Maybe you'll have more time then to consider the issue.  And, as 
you suggest, maybe others will have some chance to experience the impact on 
callers of not hearing the actual pre-answer audio.

    You've indicated the "early media" discussion is going on 
elsewhere.  Is this on SIPPING, SIP, MMUSIC or some other list?  I don't 
know much about the subject (except for how ISUP/PSTN behaves), but maybe 
seeing the discussion would help me understand the issues.

Al Varney

---

From: Michael Hammer <[email-masked]>
Date: Mon, 19 Aug 2002 12:52:29 -0400

Jon,

The size of the response shows the importance of the work you are doing 
here.  We appreciate your taking the extra effort to address all these 
comments.  I feel satisfied that the issues have been well-aired.  Look 
forward to finalizing this and getting feedback on the results from 
implementations.

Mike

---

From: "Mark Watson" <[email-masked]>
Date: Tue, 27 Aug 2002 17:15:22 +0100

Jon,

Who was it said 'You can please some of the people all of the time, or all
of the people some of the time, but ...' ?

I was lucky enough to miss the early media thread, and unlucky enough to
have just read through it.

I think the point was made by Gonzalo several times that it is important to
preserve the functional indication that the called party is ringing,
independent of Early Media, because terminals have other ways than audio of
indicating call progress to the user.

In fact, in the PSTN, with ISUP, the most common case is that both Early
Media (the ring tone applicable in the called country) and a functional
indication of ringing (ACM 'subscriber free') are available. I would not
support a change so that 183 was used in this case, as the 'subscriber free'
indication is then lost.

As I understand it, the only problem which has been raised with the existing
mechanism, aside from messaging inefficiency, is that when these two events
(ringing indication & early media) are triggered simultaneously, SIP has no
mechanism to communicate them simultaneously. The UAC receives the events
separately in random order leading to some non-deterministic behaviour.

There are thus two solutions:
1) Define a mechanism to send the events simultaneously
2) The UAS sends the events in an order of its choosing, getting
confirmation of receipt of one before sending the other

(1) corresponds to sending the new SDP offer in the 180 - not supported in
3261, but could be supported in a future Early Media extension
(2) means you wait for the 200 OK to the UPDATE turning the media on before
sending the 180.

I think the new indicators suggested are just kludgy versions of (1). I'd
prefer to do it properly and allow simultaneity in session and bearer events
to be communicated in the protocol.

So, without new extensions there are three approaches:
1) Don't worry about the non-determinsitic behaviour
2) Use 183, and loose the 'subscriber free' indication
3) Wait for confirmation of your UPDATE before sending a 180

and I suppose if you really don't care about extra messaging you can combine
2 & 3:
4) Send 183/UPDATE simultaneously & then send 180 when the 200 OK (UPDATE)
is received.

At the very least these should be described. I don't think any are ideal, so
I'm not sure whether we should recommend one.

Regards...Mark

> -----Original Message-----
> From: Peterson, Jon [mailto:[email-masked]]
> Sent: 19 August 2002 13:27
> To: [email-masked]'
> Subject: [Sipping] sipping-isup-05 -> -06
> 
>

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 27 Aug 2002 13:35:51 -0500

Mark (and others interested in early media),
Please allow me to point you to a recent thread in the SIP archive on this subject: "RE: [Sip] Local vs Remote ringback on 180", most of which transpired on Aug 21 and Aug 22.  I started the recent continuation of that thread based on the potential impact to the manyfolks draft.  Please review the outcome of that discussion.
 
Regards,
Richard Ejzak

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Tuesday, August 27, 2002 11:15 AM
To: 'Peterson, Jon'; [email-masked]'
Subject: RE: [Sipping] sipping-isup-05 -> -06

Jon, 

Who was it said 'You can please some of the people all of the time, or all of the people some of the time, but ...' ? 

I was lucky enough to miss the early media thread, and unlucky enough to have just read through it. 

I think the point was made by Gonzalo several times that it is important to preserve the functional indication that the called party is ringing, independent of Early Media, because terminals have other ways than audio of indicating call progress to the user.

In fact, in the PSTN, with ISUP, the most common case is that both Early Media (the ring tone applicable in the called country) and a functional indication of ringing (ACM 'subscriber free') are available. I would not support a change so that 183 was used in this case, as the 'subscriber free' indication is then lost.

As I understand it, the only problem which has been raised with the existing mechanism, aside from messaging inefficiency, is that when these two events (ringing indication & early media) are triggered simultaneously, SIP has no mechanism to communicate them simultaneously. The UAC receives the events separately in random order leading to some non-deterministic behaviour.

There are thus two solutions: 
1) Define a mechanism to send the events simultaneously 
2) The UAS sends the events in an order of its choosing, getting confirmation of receipt of one before sending the other

(1) corresponds to sending the new SDP offer in the 180 - not supported in 3261, but could be supported in a future Early Media extension

(2) means you wait for the 200 OK to the UPDATE turning the media on before sending the 180. 

I think the new indicators suggested are just kludgy versions of (1). I'd prefer to do it properly and allow simultaneity in session and bearer events to be communicated in the protocol.

and I suppose if you really don't care about extra messaging you can combine 2 & 3: 
4) Send 183/UPDATE simultaneously & then send 180 when the 200 OK (UPDATE) is received. 

At the very least these should be described. I don't think any are ideal, so I'm not sure whether we should recommend one.

Regards...Mark 

> From: Peterson, Jon [ mailto:[email-masked] <mailto:[email-masked]> ] 
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping <https://www1.ietf.org/mailman/listinfo/sipping>

---

From: [email-masked]
Date: Tue, 27 Aug 2002 18:09:00 EDT

In a message dated 8/27/02 12:56:07 PM Eastern Daylight Time, 
[email-masked] writes:

> support a change so that 183 was used in this case, as the 'subscriber 
> free' indication is then lost.
> As I understand it, the only problem which has been raised with the 
> existing mechanism, aside from messaging inefficiency, is that when these 
> two events (ringing indication & early media) are triggered simultaneously, 
> SIP has no mechanism to communicate them simultaneously. The UAC receives 
> the events separately in random order leading to some non-deterministic 
> behaviour.
> 

I have to whole-heartedly agree. Whatever else is done, it is necessary to 
separate the establishment of "early media" and the notification (by message) 
to the calling side that the called party is free (available and ringing) or 
that it is busy (with in-band call-progess tones). This separation was 
provided in ISDN and no one wants to go backwards from where ISDN was. 
Regardless of what is done to establish "early media" before answer, the 
message with the current meaning of 180 must remain where it is. As the 
definition of 183 says in RFC 3261: it "is used to convey information about 
the progress of the call that is not otherwise classified". It should not be 
used when the gateway knows it is "Ringing".

I don't think there are any non-deterministic behaviours with the "random 
order" of arrival of the 180 response and the in-band tone or announcement 
(audible ringing), unless some originating terminal tried to interpret the 
in-band audible signal and do something as a result. As I remember, ITU-T 
explicitly recommended not to do this, partly due to the wide variety of 
tones in the world. SIP should also strongly recommend that no terminal 
should try to interpret in-band call progress tones from the other end.

I'm sorry if I could not follow the whole e-mail discussion on "early media". 
It seemed to be going every direction, but I presumed (hoped) that it was 
being settled. I thought that the requirement to keep these separate was 
clear and would be met. But it seems that it wasn't.

Mike Pierce
Artel

---

From: [email-masked]
Date: Tue, 27 Aug 2002 18:12:09 EDT

Mike Pierce
Artel

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 27 Aug 2002 19:52:27 -0500

... you do realize that the comments Mark is making are responses to the
recent thread, not an analysis of the mechanism described in
sipping-isup-06, correct? As far as I can tell sipping-isup-06 is not guilty
of any of the sins you detail below. I think I just phrased this
unfortunately in the summary that Mark was replying to: I said that 183 is
sent when locally-generated ringback is undesirable, but I gather that Mark
believed that therefore I meant 180 will not be sent as a mapping to ACM
with 'subscriber free' when there is any media (like audible ringing) on the
line. However, sipping-isup-06 recommends sending 180 as a mapping to
'subscriber free' ACMs.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 27, 2002 3:12 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sipping] sipping-isup-05 -> -06

I have to whole-heartedly agree. Whatever else is done, it is necessary to
separate the establishment of "early media" and the notification (by
message) to the calling side that the called party is free (available and
ringing) or that it is busy (with in-band call-progess tones). This
separation was provided in ISDN and no one wants to go backwards from where
ISDN was. Regardless of what is done to establish "early media" before
answer, the message with the current meaning of 180 must remain where it is.
As the definition of 183 says in RFC 3261: it "is used to convey information
about the progress of the call that is not otherwise classified". It should
not be used when the gateway knows it is "Ringing". 
[Peterson, Jon] Indeed, we recommend that 183 should not be sent when the
gateway knows that there is ringing on the line. The only times 183 is sent
are times when the gateway has no idea what the in-band audio is
communicating.
 
I don't think there are any non-deterministic behaviours with the "random
order" of arrival of the 180 response and the in-band tone or announcement
(audible ringing), unless some originating terminal tried to interpret the
in-band audible signal and do something as a result. As I remember, ITU-T
explicitly recommended not to do this, partly due to the wide variety of
tones in the world. SIP should also strongly recommend that no terminal
should try to interpret in-band call progress tones from the other end. 
[Peterson, Jon] We also note in the draft that it would be very difficult
for a gateway to figure out what in-band call progress tones mean. The
particular non-deterministic behavior that Bill was referring to,
incidentally, is the possibility that 180 could be sent to a SIP phone from
a gateway, that the phone could begin generating local alerting, and that
subsequently in-band audio (like a busy tone) could be sent to the terminal.
When the phone receives this early media, we expect that it will interrupt
its locally-generated tones and render the media to the user (since neither
the gateway nor the terminal knows what that media contains - if it is a
busy signal, continuing to play locally-generated ringing indefinitely would
be unfortunate). This could create an awkward transition from (local)
ringing to busy tones, or reorder, or what not. We're trying to minimize the
chances of that transition, and fix some related side-effects of naive early
media transmission.

I'm sorry if I could not follow the whole e-mail discussion on "early
media". It seemed to be going every direction, but I presumed (hoped) that
it was being settled. I thought that the requirement to keep these separate
was clear and would be met. But it seems that it wasn't. 
[Peterson, Jon] I'm not sure that I understand your requirement, but I don't
think we make any of the mistakes you describe above, anyway.

Mike Pierce 
Artel

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 28 Aug 2002 13:58:23 +0100

Richard,

Yes, I looked at that thread.
 
However, I have decided to ignore all sip/sipping emails which are not
offer/answer compliant. It saves time and I and others have spent too long
explaining on this list why almost any sentence which attempts to explain
things in terms of '18x with/without SDP' is meaningless. This applied to
too many emails in that thread (not necessarily yours).
 
The problem raised on 21/8 of linkage between 180 and the media status is a
non-problem anyway, since, err, there is no such linkage anywhere in the
specifications. The outcome that the 'problem' can be solved using MIME
encapsulated data seems very clear in the ISUP encapsulation case, and not
really appropriate in other cases.
 
...Mark

-----Original Message-----
From: Ejzak, Richard P (Richard) [mailto:[email-masked]]
Sent: 27 August 2002 19:36
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]'
Subject: RE: [Sipping] sipping-isup-05 -> -06

Mark (and others interested in early media),
Please allow me to point you to a recent thread in the SIP archive on this
subject: "RE: [Sip] Local vs Remote ringback on 180", most of which
transpired on Aug 21 and Aug 22.  I started the recent continuation of that
thread based on the potential impact to the manyfolks draft.  Please review
the outcome of that discussion.
 
Regards,
Richard Ejzak

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Tuesday, August 27, 2002 11:15 AM
To: 'Peterson, Jon'; [email-masked]'
Subject: RE: [Sipping] sipping-isup-05 -> -06

Jon, 

Regards...Mark 

> revisit the recommendations of this document and enhance as necessary. 
<https://www1.ietf.org/mailman/listinfo/sipping>

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 28 Aug 2002 14:15:44 +0100

Mike,
 
The problem with the random order of arrival for the signals is that if the
180 arrives before the indication of Early Media, then the UAC may play
local ringing for a short time, and then switch to the early media (which
may be a different ring cadence, or an announcement).
 
Both in this case, and on Answer, I would recommend sending the UPDATE with
the new a=sendonly/sendrecv first, since it is the change in the media
stream which is most important to communicate.
 
Also, some threads seemed to assume that if a UAC is generating local
ringing, it would cease doing this if it received RTP. Firstly, if the
stream is not on hold, then I don't think it would start generating local
ringing anyway (it will think there is media). Secondly, PSTN gateways
gateways may be distributed into MGC and MG using Megaco. The MG is not (and
should not) be intelligent enough to switch from local ringing generation to
cut-through due to receipt of RTP. Also there is no event to report receipt
of RTP up to the MGC. Thirdly, we have discussed before that arrival or not
of RTP packets it not a reliable way to communicate functional indications,
especially when you consider codecs with DTX.
 
So, whilst a UAC must be prepared to receive media *on an active stream* at
any time, I don't think you will ever generate local ringing if you have an
active stream. So you will never switch from ringing to playing media due to
the mere arrival of RTP.
 
What is that state of a steam where there has been an offer, but no answer -
'active' ? 'on hold' ? :-)
 
...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 27 August 2002 23:09
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]; [email-masked]
Subject: Re: [Sipping] sipping-isup-05 -> -06

Mike Pierce 
Artel

---

From: Michael Hammer <[email-masked]>
Date: Wed, 28 Aug 2002 11:09:30 -0400

Mark,

You don't define "active stream", but I presume that you mean a completed 
Offer/Answer exchange and not the receipt of actual RTP packets.

So can I sum it up this way:

Receipt of RTP packets has no impact, since on Offer could have been made, 
but not accepted yet.

Receipt of an Answer that puts the two nodes in agreement that there is at 
least a backwards cut-through path means that only in-band alerting should 
be used.

Absent an in-band path, receipt of a 180 causes the originating gateway to 
inject local ringing.

The implication of the above is that the terminating GW should withhold an 
Answer (or use Offer/Answer to put on hold) when sending 180 if it intends 
the originating GW to inject local ringing.  If it intends to use in-band 
alerting, then the 180 should be sent after (or coincidentally) the Answer 
is sent establishing via SDP the active stream.

Mike

At 02:15 PM 8/28/2002 +0100, Mark Watson wrote:
>Mike,
>
>The problem with the random order of arrival for the signals is that if 
>the 180 arrives before the indication of Early Media, then the UAC may 
>play local ringing for a short time, and then switch to the early media 
>(which may be a different ring cadence, or an announcement).
>
>Both in this case, and on Answer, I would recommend sending the UPDATE 
>with the new a=sendonly/sendrecv first, since it is the change in the 
>media stream which is most important to communicate.
>
>gateways may be distributed into MGC and MG using Megaco. The MG is not 
>(and should not) be intelligent enough to switch from local ringing 
>generation to cut-through due to receipt of RTP. Also there is no event to 
>report receipt of RTP up to the MGC. Thirdly, we have discussed before 
>that arrival or not of RTP packets it not a reliable way to communicate 
>functional indications, especially when you consider codecs with DTX.
>
>So, whilst a UAC must be prepared to receive media *on an active stream* 
>at any time, I don't think you will ever generate local ringing if you 
>have an active stream. So you will never switch from ringing to playing 
>media due to the mere arrival of RTP.
>
>What is that state of a steam where there has been an offer, but no answer 
>- 'active' ? 'on hold' ? :-)
>
>...Mark
>>>I think the point was made by Gonzalo several times that it is important 
>>>to preserve the functional indication that the called party is ringing, 
>>>independent of Early Media, because terminals have other ways than audio 
>>>of indicating call progress to the user.
>>>existing mechanism, aside from messaging inefficiency, is that when 
>>>these two events (ringing indication & early media) are triggered 
>>>simultaneously, SIP has no mechanism to communicate them simultaneously. 
>>>The UAC receives the events separately in random order leading to some 
>>>non-deterministic behaviour.
>>
>>
>>I have to whole-heartedly agree. Whatever else is done, it is necessary 
>>to separate the establishment of "early media" and the notification (by 
>>separation was provided in ISDN and no one wants to go backwards from 
>>where ISDN was. Regardless of what is done to establish "early media" 
>>before answer, the message with the current meaning of 180 must remain 
>>where it is. As the definition of 183 says in RFC 3261: it "is used to 
>>convey information about the progress of the call that is not otherwise 
>>classified". It should not be used when the gateway knows it is "Ringing".
>>
>>order" of arrival of the 180 response and the in-band tone or 
>>announcement (audible ringing), unless some originating terminal tried to 
>>interpret the in-band audible signal and do something as a result. As I 
>>remember, ITU-T explicitly recommended not to do this, partly due to the 
>>wide variety of tones in the world. SIP should also strongly recommend 
>>that no terminal should try to interpret in-band call progress tones from 
>>the other end.
>>
>>media". It seemed to be going every direction, but I presumed (hoped) 
>>that it was being settled. I thought that the requirement to keep these 
>>separate was clear and would be met. But it seems that it wasn't.
>>
>>Mike Pierce
>>Artel
>>

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 28 Aug 2002 17:39:52 +0100

Jon,
 
Whilst I agree with the notes you've provided below, I'm afraid that my
comment does affect sipping-isup-06 (I can hear you sigh over 8 time zones
:-). I'll try to be more explicit.
 
I am concerned about the case where I receive an ACM with 'subscriber free'
and in-band audio. I want the caller to hear the audio. I also do not want
to lose my functional indication of the subscriber's status. Explicit
examples of Early Media with ringing are: provision of appropriate ring-tone
for the called country (not very important, I agree. Perhaps even
undesirable) and provision of special ringing tones/announcements for
services such as Call Waiting or when you are in a queue.
 
I must say that I did not realise that at the ISUP->SIP gateway, 8.2.3
specifies that receipt of 183 can cause 'subscriber free' to be indicated in
the resulting ACM - surely this is not right ? 183 does not mean that the
called party is free/alerting. 183 means, well, er..., not  much, actually .
 
Back to the SIP->ISUP node. -05 indicates in 7.2.6:
 
'When it transmits a 180, the gateway also MAY begin to transmit early media
in order to offer special announcements and tones played by the PSTN.' and
'When a 180 is sent without any early media, it is assumed that any
necessary ringback tones will be generated by the SIP user agent to which
the gateway is responding.'
 
whereas in -06 it now says  only :
 
'When a 180 is sent, it is assumed that any necessary ringback tones will be
generated locally by the SIP user agent to which the gateway is responding
(which may in turn be a gateway).'
 
Both indicate that on receipt of 'subscriber free' indication, I SHOULD send
180, which is good, but I now have to break this 'SHOULD' if I have in-band
media.
 
So, I agree with the introduction of 183 for the case where no 'subscriber
free' indication is received (actually, I thought this was already
specified!), but we should also allow the case of 180 + early media as per
-05. Yes, there is a problem because the 180 & the media could arrive in
either order. If you think this is serious, I have suggested 3 solutions
below.
 
I propose the following amendments.
 
In 7.2.6, replace the sentence quoted above with:
 
'When a 180 is sent, it may be assumed that any necessary ringback tones
will be generated locally by the SIP user agent to which the gateway is
responding, or, if appropriate early media extensions are supported and
in-band tones/announcements are available from the PSTN, the gateway MAY
offer Early Media to the caller to play the early media.'
 
Regards...Mark

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 27 August 2002 19:58
To: Watson, Mark [MOP:EP10:EXCH]
Subject: RE: [Sipping] sipping-isup-05 -> -06

Although I've tried to stay out of the recent discussions about EM on the
SIP list, I'll respond to this, as it doesn't seem to be a commentary on
sipping-isup-06, but rather some remarks on the recent thread.
 
A few notes below.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Tuesday, August 27, 2002 9:15 AM
To: 'Peterson, Jon'; [email-masked]'
Subject: RE: [Sipping] sipping-isup-05 -> -06

Jon, 

In fact, in the PSTN, with ISUP, the most common case is that both Early
Media (the ring tone applicable in the called country) and a functional
indication of ringing (ACM 'subscriber free') are available. I would not
support a change so that 183 was used in this case, as the 'subscriber free'
indication is then lost.
[Peterson, Jon] Agreed. There some important differences between the ISUP
and SIP (a novel pronouncement there) that make it very reasonable to send a
status indication and media simultaneously in the PSTN, however. When you
send an IAM, you must reserve a TCIC, and therefore commit some resources to
the call. When an ACM with 'subscriber free' is sent, why not send redundant
media over the TCIC that has already been reserved? The SIP case is
profoundly different. No resources are committed when an INVITE is sent. In
a forking case, for example, if every endpoint that wanted to express that
it was ringing also sent 'naive' early media, that could be problematic
bandwidth-wise. Receiving early media also makes it very difficult for a UAC
to decide which provisional response (in a forking case) is the 'best' one,
and therefore what sort of feedback it should provide to the user. Of
course, we say in sipping-isup-06 that when 'subscriber free' is sent in an
ACM, then '180' should be used by the gateway, not 183.

As I understand it, the only problem which has been raised with the existing
mechanism, aside from messaging inefficiency, is that when these two events
(ringing indication & early media) are triggered simultaneously, SIP has no
mechanism to communicate them simultaneously. The UAC receives the events
separately in random order leading to some non-deterministic behaviour.
[Peterson, Jon] Well, there's the problem I just mentioned above as well.
The non-deterministic behavior is only really a problem when you have no
idea what the nature of the media is (BCI of 'no indication' or OBCI of
'in-band info' or CPG with Event of 'in-band info'). Then we can get this
unnatural transition from locally-generated ringtone resulting from a 180
to, say, a busy signal being played in-band, that Bill rightly noted was
undesirable. We've argued (and introduced into the draft) that this can be
avoided if 180 is not sent when we have no idea what the nature of the media
is.

I think the new indicators suggested are just kludgy versions of (1). I'd
prefer to do it properly and allow simultaneity in session and bearer events
to be communicated in the protocol.
[Peterson, Jon] Yeah, we're not going to do anything with new indications,
at least not in sipping-isup-06. 

and I suppose if you really don't care about extra messaging you can combine
2 & 3: 
4) Send 183/UPDATE simultaneously & then send 180 when the 200 OK (UPDATE)
is received. 
[Peterson, Jon] I think even this is complex enough that it would
essentially entail an early media extension. 

At the very least these should be described. I don't think any are ideal, so
I'm not sure whether we should recommend one.
[Peterson, Jon] We did recommend something in sipping-isup-06 that is, we
think, the reasonable thing to do in the absence of an early media
extension.

Regards...Mark

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 28 Aug 2002 22:56:31 -0400

I am inclined to sigh when I see wording suggested for a draft that is not
going to be modified at this time...  but the specific language you propose
seems like so slight a change, it's hard for me to tell whether or not it
would really make a big difference either way.
 
In sipping-isup-06 (notably in 5.5) the limitations of 'naive' early media
are described, and a normative MAY for support of an early media extension
(with a pointer to the UPDATE draft) is given. Note that the changes that
were made between -04 and -05 to the text on backwards media (in 7.2.6 and
elsewhere) were intended to reduce conflicts between sipping-isup-0x and the
offer/answer model, and to eliminate any legacy language that would
obviously impede the use of an early media extension with these gateway
behaviors. 
 
So, there's no question that an early media extension could revise the
media-related behavior of a UAC that receives a 180, and I don't think
sipping-isup-06 rules this out. We could add some language to very slightly
tweak this in 7.2.4; your suggested fix, or maybe this even smaller one:
 
'When a 180 is sent, it is assumed, in the absence of any early media
extension, that any necessary ringback tones will be generated locally by
the SIP user agent to which the gateway is responding (which may in turn be
a gateway).'
 
... but I don't think this would really make that much difference given that
this section references 5.5. Since this doesn't even introduce any normative
change, it doesn't seem like a very high priority fix to me.
 
On a side note, I am at something of a loss to find the text in 8.2.3 that
suggests that a 183 should be mapped to ACM with 'subscriber free'.
Actually, the only text I could find specifically about 183 in that section
is:
 
'If a gateway receives a 183 response while it is playing backwards media,
then when it generates a mapping for this response, if no encapsulated ISUP
is present, the gateway SHOULD indicate that in-band information is
available (for example, with the Event Information parameter of the CPG
message or the Optional Backward Call Indicators parameter of the ACM).'
 
The text may not specifically rule out setting 'subscriber free' for 183,
but it doesn't encourage it either. Maybe if we get the chance, we could add
to the first chart in this section (the one with the Response Recieved
column on the left side) which 'called party's status indicator' field
should be sent for the various ACMs listed on the right.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Wednesday, August 28, 2002 9:40 AM
To: [email-masked]'
Subject: FW: [Sipping] sipping-isup-05 -> -06

Jon,

 

 

 

 
 
Regards...Mark

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 27 August 2002 19:58
To: Watson, Mark [MOP:EP10:EXCH]
Subject: RE: [Sipping] sipping-isup-05 -> -06

A few notes below.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Tuesday, August 27, 2002 9:15 AM
To: 'Peterson, Jon'; [email-masked]'
Subject: RE: [Sipping] sipping-isup-05 -> -06

Jon, 

Regards...Mark

---

From: "Mark Watson" <[email-masked]>
Date: Thu, 29 Aug 2002 08:55:50 +0100

Hi Jon,
 
I don't think it's as trivial a change as you suggest. The -06 text fairly
clearly implies that Early Media cannot be used at the same time a 180 is
sent (because 'it is assumed' that the far end terminal will generate
ringing, with no qualification that this might not apply if EM is used). If
this is not intended, I would rather we clarified that Early Media is still
applicable. Of course I prefer my text, but your proposed change below is
good too.
 
In section 8.2.3, it suggests that 'subscriber free' is set for all cases
other than 'Early ACM' (third table, which shows the indicator settings). In
the first table, it shows 183 mapping to just 'ACM', in contrast to 181
which maps to Early ACM. I guess we could change this to 'Early ACM', or as
you suggest add a column showing the subscriber status indicator. I've a
suspicion that the ACM sent from a forwarding node is not, strictly, an
'Early' ACM. I have only previously seen the term 'Early ACM' used for an
ACM sent from a transit node, before the terminating exchange of the called
subscriber has been reached.
 
Some other comments below...
 
Regards...Mark

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 29 August 2002 03:57
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]'
Subject: RE: [Sipping] sipping-isup-05 -> -06

I sympathise the your desire to get this completed, and I apologise for
missing the discussion which lead to this change, but I think the current
text appears to rule out Early Media with 180, which is a significant thing,
even if it is not normatively stated.  

 

 

Yes, well, 'if we get the chance' we can modify the other text too :-) 

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Wednesday, August 28, 2002 9:40 AM
To: [email-masked]'
Subject: FW: [Sipping] sipping-isup-05 -> -06

Jon,

 

 

 

 
 
Regards...Mark

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 27 August 2002 19:58
To: Watson, Mark [MOP:EP10:EXCH]
Subject: RE: [Sipping] sipping-isup-05 -> -06

A few notes below.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Tuesday, August 27, 2002 9:15 AM
To: 'Peterson, Jon'; [email-masked]'
Subject: RE: [Sipping] sipping-isup-05 -> -06

Jon, 

Regards...Mark