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

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 7 Aug 2002 13:58:10 -0400

I'd like to draw the attention of the list to the latest revision of the
SIP-ISUP mapping draft. This version reflects comments that have been
received during IETF last call, including those submitted by the IESG. The
most significant change resulting from those comments is the addition of an
RFC2119 boilerplate, and the introduction of normative language throughout
the draft. Numerous editorial corrections for clarity/readability have
accompanied these additions.

We also took a little time to clean up a few topics that have become clearer
in SIP since the SIP-ISUP draft had last been seriously revisited, including
early media, presentation restriction, expressing release reasons in CANCEL,
and a few others. Many of these had in the past been partially addressed in
the draft, but the enhancements were incomplete or even self-contradictory.
Hopefully the texts on interworking indications in the FCI/BCI and the cause
code to response code mappings are as free of obvious defects as they are
likely to get.

Finally, the Security Considerations now contain some analysis of the
effects of mapping various fields of the tel URL to ISUP parameters, in so
far as these tel URLs can be created more or less arbitrarily by end users.
There is some additional consideration of the effects of early media, and
some recommendations for gateway implementers and service providers
regarding operating systems that allow backwards media from end users.

Thanks to this list (and the previous homes of the draft, the SIP WG and
MMUSIC WG) for comments on this draft over the past four years.

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: "Mark Watson" <[email-masked]>
Date: Thu, 8 Aug 2002 14:04:42 +0100

Jon,

Well, it all looks very good, but it does not appear to have taken into
account my comment that we should not RECOMMEND setting of the FCI to
interworking encountered, because of the services this will break. I did not
spot anyone arguing with this request on the list.

If I remember rightly the version which initially left the WG gave some
guidance, but did not recommend one way or the other, and I think we should
stick with this.

A proposal and some comments on the wording below...

"When a gateway receives a message with (comprehensible) encapsulated
   ISUP, it MUST set the value of the FCI indicator parameter that is
   present in the message for all bits in the parameter related to
   interworking..."

MW> It does not say *to what* the value MUST be set! "..the FCI indicator
parameter that is present in the message" - present in the encapsulated
message or the one about to be sent ? I think what you meant to say was:
"... it MUST set the FCI indicators related to interworking in the outgoing
IAM to the same as the values received in the encapsulated ISUP message"

 (unless interworking has been encountered somewhere else
   in the call path, these indicators will most likely state that no
   interworking was encountered).  If usable encapsulated ISUP is not
   present in an INVITE received by the gateway, it is RECOMMENDED that

MW>change "it is RECOMMENDED that the set the" to "the gateway MAY set the"

   the set the 'interworking encountered' bit of the FCI to
   'interworking encountered' and set the two ISDN access parameters,
   the ISDN User Part Indicator and the Originating Access indicator, to
   state that ISDN is not available for the entire call path (values of
   'ISDN not used all the way' and 'Originating access non-ISDN',
   respectively).

   Note that when the ISUP parameters regarding interworking are set in
   the Forward Call Indicators (FCI) parameter of the IAM, this
   indicates that ISDN is interworking with a network which is not
   capable of providing as many services as ISDN does.  ISUP will
   therefore not employ certain features it otherwise normally uses.
   Gateway vendors therefore MAY provide a configurable option, usable
   at the discretion of service providers, that when encapsulated

MW> What does it mean for a 'configurable option' to be 'encapsulated'
anyway ??

   will signal in the FCI that no interworking has been encountered.

MW> Suggest we reword to: "Gateway vendors MAY choose to provide
interworking with the full ISDN service set, in which case the FCI
indicators MAY be set to indicate that no interworking has been encountered
and the originating access is ISDN."

   When
   ISUP feature transparency is available, `interworking encountered'
   MUST NOT be specified so that ISUP behaves normally.

MW>But we said above that the FCI indicators are set as in the encapsulated
ISUP - which may of course contain the value 'interworking encountered'.
Delete this sentence.

...Mark

> -----Original Message-----
> From: Peterson, Jon [mailto:[email-masked]]
> Sent: 07 August 2002 18:58
> To: [email-masked]'
> Subject: [Sipping] new draft-ietf-sipping-isup-05
> 
> 
>

---

From: Al Varney <[email-masked]>
Date: Thu, 08 Aug 2002 10:06:24 -0500

At 02:04 PM 8/8/02 +0100, Mark Watson wrote:
>interworking encountered, because of the services this will break. I did 
>not spot anyone arguing with this request on the list.

    I had some comments (on other areas) ready to go, but apparently the 
window is closed for them??  So here're my comments on Mark's comments.

>guidance, but did not recommend one way or the other, and I think we 
>should stick with this.
>
>"... it MUST set the FCI indicators related to interworking in the 
>outgoing IAM to the same as the values received in the encapsulated ISUP 
>message"
>

    [ALV] I agree with Mark's proposal -- maybe the wording should even be 
stronger, indicating that the FCI indicators in the encapsulated case are 
to be modified only as specified in Q.764 for an ISUP-to-ISUP tandem 
exchange.  This will prevent any "set/reset option" from creeping into that 
interworking scenario.  In the bridging case, NONE of the interworking 
indicators in the FCI/BCI should be changed by a gateway.  (For example, a 
gateway CANNOT change "interworking encountered" to "no interworking 
encountered", because interworking IS occurring elsewhere in the call path.)

    [ALV] Also, Mark's suggested text is just another example in this 
document where the "SIP bridging" and non-bridging text gets confusing.  It 
would be much clearer if the bridging stuff (which ends in the middle of 
the above paragraph) were clearly separated from the non-bridging 
stuff.  Starting a new paragraph at "If usable encapsulated ISUP is not 
present..." would help to make it clear that all the following text 
regarding optional setting/not-setting of the FCI applies ONLY to the 
non-bridging case.

    [ALV] The BCI handling for bridging/non-bridging should similarly be 
cleared up.  For calls in the opposite direction (ISUP to SIP), it appears 
a gateway always sends encapsulated ISUP and must act as a tandem exchange 
when sending the INVITE-with-encapsulated-IAM.  However, when SIP responses 
appear without encapsulated ACM/CPG, then the gateway must act as a 
terminating exchange.  Only in this instance could the option apply to 
force the ACM BCI interworking indicators be indicate no interworking and 
'terminating access ISDN'.

>indicators MAY be set to indicate that no interworking has been 
>encountered and the originating access is ISDN."

    [ALV] "Originating access is ISDN" is appropriately set only by the 
originating exchange (an end-user SIP to ISUP node).  The text should be 
clear that a bridging call should not clear any interworking indicators or 
set the originating access indicator.

>MW>But we said above that the FCI indicators are set as in the 
>encapsulated ISUP - which may of course contain the value 'interworking 
>encountered'. Delete this sentence.

    [ALV] Again, this is probably where the intent is for ISUP feature 
transparency between ISUP and end-user SIP (no encapsulated ISUP in the SIP 
messages).  In the bridging case, the phrase "ISUP feature transparency" 
would (mostly) mean that ISUP messages are transported across the node.

Al Varney

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 8 Aug 2002 13:01:34 -0500

In general, on this issue of whether or not the FCI SHOULD be set to
'interworking encountered' when encapsulated ISUP is not present, there were
voices on both sides of this issue (though not all have spoken in particular
in the past few weeks), including that of the SG11 communication. I'd prefer
that we RECOMMEND one way or another, and I believe the prevailing wind is
to recommend that 'interworking encountered' is specified. Since you cite
the text in question below, you are aware that we mention that implementers
could make this some kind of configurable option, letting service providers
choose to transmit 'no interworking' in these cases instead. Maybe as we
gain more operational experience (presumably between this round and Draft
standard), we'll be confident enough to mandate one of the two approaches.
 
Some other comments inline.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Thursday, August 08, 2002 6:05 AM
To: 'Peterson, Jon'; [email-masked]'
Subject: RE: [Sipping] new draft-ietf-sipping-isup-05

Jon, 

MW> It does not say *to what* the value MUST be set! "..the FCI indicator
parameter that is present in the message" - present in the encapsulated
message or the one about to be sent ? I think what you meant to say was:
"... it MUST set the FCI indicators related to interworking in the outgoing
IAM to the same as the values received in the encapsulated ISUP message"
[Peterson, Jon] *grr* Yes. Amazing how utterly impossible it is to rid texts
of bugs. That will be fixed.

MW> What does it mean for a 'configurable option' to be 'encapsulated'
anyway ?? 
[Peterson, Jon] God, another textual bug. Kill me now. That will also be
fixed.

MW> Suggest we reword to: "Gateway vendors MAY choose to provide
interworking with the full ISDN service set, in which case the FCI
indicators MAY be set to indicate that no interworking has been encountered
and the originating access is ISDN."
[Peterson, Jon] I like the semantics (if not the syntax) of my text better.
When we want to offer options, I'd rather encourage vendors to allow service
providers to make the decision, to trials things both ways, rather than
encouraging vendors to make an absolute decision for service providers.

   When 

MW>But we said above that the FCI indicators are set as in the encapsulated
ISUP - which may of course contain the value 'interworking encountered'.
Delete this sentence.
[Peterson, Jon] If 'interworking encountered' is specified in the ISUP, that
would be a case in which ISUP feature transparency is not available - I
don't read any implication here that you should override the value in the
encapsulated ISUP. This sentence is okay.

...Mark 

> From: Peterson, Jon [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> MMUSIC WG) for comments on this draft over the past four years. 
<https://www1.ietf.org/mailman/listinfo/sipping>

---

From: "Mark Watson" <[email-masked]>
Date: Thu, 8 Aug 2002 19:27:12 +0100

Jon,
 
The problem I have with this approach is that we are recommending something
which we *know* breaks services. Interworking SIP videotelephony with ISDN
videotelephony is not an unreasonable thing to want to do. I accept the
approach of suggesting an operator-configurable option, but noone has
identified any services which break if you set 'no interworking', whereas we
have identified services which break if you set 'interworking encountered'
so I find it hard to understand why we would recommend this.
 
Note also that the SG11 communication was written before any 'broken'
services were identified. If I am correctly informed, then at that meeting
it was believed that the 'interworking encountered' setting would not
prevent any service interworking. SG11 will discuss this issue at their next
meeting, indeed it has already been raised on their receiver list.
 
On the 'ISUP Feature Transparency' sentence, I read this as transparency
over the SIP-T portion of the call. If you mean ISUP is used 'all the way'
then I'm not sure what this sentence is instructing the gateway to do. The
only information the gateway has about whether ISUP is used all the way is
in the encapsulated indicators, so then this sentence is just duplicating
the requirement at the beginning that the outgoing indicators are set as per
the encapsulated data. Plus it's confusing, so I still say delete it.
 
...Mark

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 08 August 2002 19:02
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]'
Subject: RE: [Sipping] new draft-ietf-sipping-isup-05

 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Thursday, August 08, 2002 6:05 AM
To: 'Peterson, Jon'; [email-masked]'
Subject: RE: [Sipping] new draft-ietf-sipping-isup-05

Jon, 

   When 

...Mark

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 8 Aug 2002 15:13:12 -0400

There are some ISDNish services that I suspect will be broken, but I'm not
sure how important a consideration they really are. I mean, the
recommendations in the SIP-ISUP draft are not sufficient to allow
videotelephony interworking for any number of reasons, anyway.
 
But that much said, it isn't too hard to twist my arm on this point. I
certainly don't want to hamper the SIP-ISUP interworking process
unnecessarily. This does seem to be an issue where even experts are
guessing, and a SHOULD may be too strong. I'll downgrade the strength of
this language to MAY. It is probably best at this stage of interworking
development to present our guidance (which is detailed at some length in the
draft) without any normative muscle behind it.
 
On the 'ISUP feature transparency' sentence, yes, this is essentially a
restatement of the guidance given in the beginning of the paragraph rather
than a recommendation for particular gateway behavior. I'm not sure that it
is as misleading as you suggest, but I am also eager to close this issue so
I'll take your word for it and remove it.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Thursday, August 08, 2002 11:27 AM
To: 'Peterson, Jon'; [email-masked]'
Subject: RE: [Sipping] new draft-ietf-sipping-isup-05

Jon,

 
 
...Mark

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 08 August 2002 19:02
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]'
Subject: RE: [Sipping] new draft-ietf-sipping-isup-05

 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Thursday, August 08, 2002 6:05 AM
To: 'Peterson, Jon'; [email-masked]'
Subject: RE: [Sipping] new draft-ietf-sipping-isup-05

Jon, 

   When 

...Mark

---

From: Al Varney <[email-masked]>
Date: Thu, 08 Aug 2002 17:58:19 -0500

At 03:13 PM 8/8/02 -0400, Peterson, Jon wrote:
>The problem I have with this approach is that we are recommending 
>something which we *know* breaks services. Interworking SIP videotelephony 
>with ISDN videotelephony is not an unreasonable thing to want to do. I 
>accept the approach of suggesting an operator-configurable option, but 
>noone has identified any services which break if you set 'no 
>interworking', whereas we have identified services which break if you set 
>'interworking encountered' so I find it hard to understand why we would 
>recommend this.

    One could certainly hypothesize an analog service that breaks if you 
always indicate an ISDN endpoint for SIP user equipment.  As (rather lame) 
examples, a FAX service could support only ISDN digital FAX if the endpoint 
is ISDN, and analog FAX otherwise.  By always labeling SIP end-points as 
ISDN, they might have to support ISDN FAX service.  Similarly, some dial-up 
modem pools assume "originating ISDN" users want to communicate using 
digital data (even when identified as "3.1kHz audio" calls), rather than as 
a 56K modem.

    I don't think having SIP-ISUP gateways always behaving as "no 
interworking encountered" will break any services.  But having SIP terminal 
equipment always identified as "access ISDN" has a higher probability of 
doing so, particularly if the equipment cannot handle some ISDN service 
requests directed to it (the gateway cannot screen based on the SIP 
equipment capabilities, right?).

    In the absence of some means for SIP terminals to indicate "access 
ISDN", why not control these separate indicators with separate 
options?  (The option to indicate "access ISDN" should automatically force 
the "no interworking encountered/SS7-all-the-way" option.)

Al Varney

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 9 Aug 2002 10:33:10 +0100

Al,

I think Jon's last email represented a reasonable compromise, but also
please see notes below...

> ISDN, they might have to support ISDN FAX service.

I think the gateway will anyway need to interwork between some kind of
Fax-over-IP on the SIP side and whatever type of Fax is supported on the
ISDN side. In any case, it is quite possible for an ISDN calling terminal to
indicate that it wishes to use Analogue fax in the High Layer Compatibility.
I think the destination side would be non-compliant to Q.931 if it ignored
this. If we consider all possible non-compliances on the destination side we
will have a difficult job.

> Similarly, some dial-up 

Well, this would certainly be very non-compliant to Q.931.

> interworking encountered" will break any services.

We have identified one example by way of existance proof, which is the
procedures for fallback from e.g. 7kHz audio service (G.722 codec) to 3.1kHz
audio. There may be others.

> But 
> having SIP terminal 

ISDN services which can't be mapped to SIP can't work anyway. The gateway
would of course need to be able to correctly terminate the signalling for
services which did not interwork, but this is not a problem.

> the "no interworking encountered/SS7-all-the-way" option.)

An ISUP IAM with 'originating access ISDN' and 'interworking encountered'
would be very odd. There are no procedures in any ITU-T recommendation which
can cause this combination of indicators, and the semantics would be
contradictory. Unfortunately, to my knowledge, the ITU-T recommendations do
not specify how an exchange should behave in these cases.

It is certainly possible to indicate 'no interworking' and 'originating
access non-ISDN', but this will still break ISDN services which can be
interworked with SIP, since the terminator may assume that they cannot be
supported.

Remember, we are interworking between *completely different* systems. The
gateway must treat each side  as an independent call leg and ensure that the
procedures relevant to that system are followed. There is no sense in which
concepts which are local to one system (such as ISDN vs non-ISDN) can be
interpreted in an end-to-end sense, they are local to the particular system.

So, the question is just are we interworking SIP with the PSTN service set,
or with the ISDN service set ? I vote for more services, particularly as we
will in due course see services such as Videotelephony and wideband audio
widely supported within certain SS7 based networks (mobile ones).

Regards...Mark

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 9 Aug 2002 12:08:24 -0400

I think this is a very good idea, and wonder if we should use it
in the general case of any gateway or other device that connects
to something that provides inband alerting.  This has nothing to
do with ISUP - a plain jane analog gateway does this, and it's
annoying to get the local ringback and then the remote ringback.

I like the explicit Alert-Info much better than inferring it from
183 vs 180 or other indirect mechanisms.

Not quite sure where to document this, although I've been thinking
about writing a BCP for basic gateways after evaluating a lot
of them in the last several months and finding lots of differences
that don't seem useful, and generate special purpose code in
terminals that call through them.

Brian

> With in-band ringback there is a race condition with the 180-Ringing
> provisional response; the UAC may receive the 180 response and
> start a local ringback, then start receiving media and preempt it
> with the in-band ringback.  
> 
> This is not an acceptible user experience.
> 
> The UAS in this case knows that it will be generating a media
> stream as soon as it sends the 180, so it could clearly indicate
> this in the signaling message.  I believe use of 183 instead of 180
> was discussed in Yokohama, but isup-05 stayed with 180.
> 
> I'd like to propose a convention on use of the Alert-Info header
> in a 180-Ringing response, where one particular value of the header
> parameter indicates to the UAC that in-band media will be coming
> and that it should not start a local ringback.  This approach seems
> completely backwards compatible with all existing systems, and
> those that understand the convention can do the proper thing.
> Other solutions solicited.
>

---

From: Al Varney <[email-masked]>
Date: Fri, 09 Aug 2002 11:21:42 -0500

>please see notes below...

    I agree for the ISDN access part.  My final comments below on 
interworking -- if they don't convince you (and Jon) there's no reason to 
thrash on.

>Well, this would certainly be very non-compliant to Q.931.

    Tariff-avoidance usually involves some non-compliance (data tariff vs. 
speech).  This was just a contrived example to show "access ISDN" could 
lead to different behavior, and there might be cases where SIP terminals 
want to be "non-ISDN".  Since SIP can't signal the terminal's intention 
explicitly, and the known cases are rather obtuse, I agree with Jon's 
proposal for an option at the gateway to select "access ISDN" rather than a 
default "access non-ISDN".  I'd even agree with the default being "access 
ISDN".

    My real concern is in tying the 'ISDN access' indicator option to the 
setting of the 2 interworking indicators.  Non-ISDN access does NOT imply 
"interworking" in the ISUP world, nor should it (IMO) in the SIP 
world.  Having a SIP/ISUP gateway set "interworking encountered" is lying 
to the ISUP network.

>procedures for fallback from e.g. 7kHz audio service (G.722 codec) to 
>3.1kHz audio. There may be others.

    I'm confused.  I thought fallback relied on a "no interworking" 
indication (and ISDN access).  My argument is that a SIP-ISUP gateway 
should ALWAYS act as a "no interworking" exchange -- it should NEVER set 
"interworking encountered" or "ISUP user part not used all the way".  I 
believe you agree so far, right?

    Should agreement on that fail, I suggested separate options to control 
the interworking and ISDN access indicators.  But see below for the logic 
regarding always acting as a "no interworking" node, and having the option 
only control the 'ISDN access' indicator....

>would be very odd. There are no procedures in any ITU-T recommendation 
>which can cause this combination of indicators, and the semantics would be 
>contradictory. Unfortunately, to my knowledge, the ITU-T recommendations 
>do not specify how an exchange should behave in these cases.

    That's because following the recommendations (primarily Q.764) could 
never result is such a case.  And that's why I indicated that, IF 2 
separate options to control "interworking encountered" and "access ISDN" 
are implemented, the "access ISDN" option MUST override any option set to 
"no interworking".  I think we agree here, no?

>interworked with SIP, since the terminator may assume that they cannot be 

    Agreed.  But this IS the setting generated by the vast majority of 
Class 5 ISUP switches today for analog PSTN calls.  Such switches do NOT 
indicate "interworking encountered" unless interfacing to older (MF,DP) 
circuit signaling systems.  The "interworking encountered" indicator refers 
to interworking inside the PSTN; with few exceptions, the type of access 
interface does not influence this indicator.  PSTN calls between analog 
lines over ISUP trunks DO indicate "no interworking" and "ISDN user part 
used all the way".  Why shouldn't SIP be treated at least as well as analog 
access lines?

>gateway must treat each side  as an independent call leg and ensure that 
>the procedures relevant to that system are followed. There is no sense in 
>which concepts which are local to one system (such as ISDN vs non-ISDN) 
>can be interpreted in an end-to-end sense, they are local to the 
>particular system.
>
>So, the question is just are we interworking SIP with the PSTN service 
>set, or with the ISDN service set ? I vote for more services, particularly 
>as we will in due course see services such as Videotelephony and wideband 
>audio widely supported within certain SS7 based networks (mobile ones).

    OK, I agree with you -- but for those insisting on an option, I believe 
the option should ONLY control the "access ISDN" ISUP indicators in FCI and 
BCI.  In every case I can think of, a SIP-ISUP gateway is NOT an 
interworking exchange (in the ISUP sense), and there is no reason to ever 
have a SIP-ISUP gateway act as one.

    The logic behind this is similar to that used by ISUP exchanges today 
to determine the setting of the 3 individual indicators:

   -the non-bridging SIP case:
   Originating [sending IAM] and terminating [sending ACM] exchanges by 
definition set FCI/BCI to "no interworking encountered" and "ISDN user part 
used all the way".  In this case, the SIP side of the call is treated (for 
Q.764 purposes) as an access interface.  Here is where Jon's option for 
"access ISDN" or not would be used to determine the setting of the 'ISDN 
access indicator'.

   -bridging SIP case:
   Intermediate (or tandem) exchanges do not alter the settings of 'ISDN 
access', 'Interworking' or 'ISDN user part' indicator EXCEPT when 
interworking to pre-ISUP signaling systems.  In this case, the SIP side of 
the call is treated (for Q.764 purposes) as ISUP, since SIP is carrying the 
ISUP messages.  Thus it really is "SS7 all the way" between the originating 
and terminating exchanges/gateways (assuming no pre-ISUP trunks are involved).

    If ISUP-to-SIP calls always include encapsulated IAMs, the gateway 
cannot determine whether it is in a bridged or non-bridged call until it 
receives a SIP response.  If ACM/CPG/REL is encapsulated in the response, 
the gateway assumes the bridging case.  If no ISUP is encapsulated, it 
assumes the non-bridging case and can generate its own ACM/CPG with the 
correct BCI settings.

    Am I missing something fundamental here?  It seems so 
obvious.  Certainly more obvious than the settings for numerous other 
indicators ("echo control device", for example, is undocumented) and the 
issue of backwards media/180-Ringing.

Al Varney

---

From: William Marshall <[email-masked]>
Date: Fri, 9 Aug 2002 12:42:31 -0400 (EDT)

I'm glad you agree that an explicit notification is needed.

Mike Hammer wrote:
> Related to this, section 8.2.3 "18x received":
> 
> "Upon receipt of a 18x response without any SDP, the gateway SHOULD 
> generates [sic] the ringback tone to be heard by the caller on the PSTN 
> side (unless the gateway knows that ringback will be provided by some other 
> device on the PSTN side)."

This is one more place where offer/answer needs to be separated from
the procedures.  Whether the 18x contains an SDP or not is irrelevent
to the generation of ringback tone - it only matters that the offer/
answer exchange has been completed.

Bill Marshall
[email-masked]

-----original message-----
Date: Fri, 09 Aug 2002 10:14:15 -0400
To: William Marshall <[email-masked]>
From: Michael Hammer <[email-masked]>
Subject: RE: [Sipping] new draft-ietf-sipping-isup-05
Cc: [email-masked]

Bill,

In general, I agree that the indication of alerting and how the alerting is 
to be provided needs to be explicitly signaled for both the encapsulated 
ISUP case and the no-ISUP case.  That is, it requires an explicit element 
in both the SIP headers as it would be in the encapsulated ISUP.  Becasue 
the SDP may be part of the independent Offer/Answer and not related to 
providing tones and announcements, a call signaling element indicating 
local generation versus inband would avoid making likely false assumptions.

Related to this, section 8.2.3 "18x received":

"Upon receipt of a 18x response without any SDP, the gateway SHOULD 
generates [sic] the ringback tone to be heard by the caller on the PSTN 
side (unless the gateway knows that ringback will be provided by some other 
device on the PSTN side)."

It is possible that an ACM or CPG with "no indication" triggered this 18x.

Mike

At 09:22 AM 8/9/2002 -0400, William Marshall wrote:
>The latest version of this draft has gone a long way toward
>consistency with the offer/answer model of rfc3261, thereby
>allowing integration with the additional procedures for preconditions,
>and resolving the in-band vs. local ringback issue.  However, I
>don't think it is there yet.
>
>Bill Marshall
>[email-masked]

---

From: William Marshall <[email-masked]>
Date: Fri, 9 Aug 2002 12:49:45 -0400 (EDT)

Brian,

I would not object at all if this were to be incorporated into a BCP.
However, I think it also deserves some mention in the ISUP mapping draft.
At the moment the ISUP draft is being used as the best-current-practice
for gateways, and it would be nice if it were as complete as possible.

Bill Marshall
[email-masked]

-----original message-----
From: "Rosen, Brian" <[email-masked]>
To: "'William Marshall'" <[email-masked]>, [email-masked]
Subject: RE: [Sipping] new draft-ietf-sipping-isup-05
Date: Fri, 9 Aug 2002 12:08:24 -0400 

Brian

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 9 Aug 2002 18:13:26 +0100

Hi Al,

OK - I think I misunderstood some of your previous email. If I understand
better now, you are saying we should ALWAYS set 'no interworking
encountered' and 'ISUP used all the way', and that if there is an option it
should be to switch between 'Originating Access ISDN' and 'Originating
Access Non-ISDN'.

If this is correct, then I agree completely. (What a difference that 'no'
makes in front of 'interworking encountered' :-)

This is in contrast to the existing draft, in which the option affects all
three indicators.

I'm not sure what difference the iw indicator makes if we have 'Access
non-ISDN', but the principles below make sense.

Jon ?

Regards...Mark

> From: Al Varney [mailto:[email-masked]]
> Sent: 09 August 2002 17:22

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 9 Aug 2002 14:09:02 -0400

I'd go one step farther and say that the applicability of this probably
isn't even limited to gateways. This should be part of a general early media
solution, which is useful in a number of different SIP scenarios.

Jon Peterson
NeuStar, Inc.

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Friday, August 09, 2002 9:08 AM
> To: 'William Marshall'; [email-masked]

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 9 Aug 2002 14:08:07 -0400

The purpose of the early media clarifications in isup-05 was more to prevent
the text from interfering with any more fully-featured early media system,
rather than proposing such a system in detail. The pre-05 text was
wrong/unhelpful, and as it stands a gateway will at least do what any
RFC3261 user agent could be expected to do.

Alert-Info is intended to contain a URL that points to some sort of sound
file that a UAC would download and then play as an alternative ringtone.
While I'm not necessarily opposed to the idea of having some explicit
indication of whether or not a UAC should generate local ringback when it
receives a 18x, I don't think we should overload Alert-Info for this
purpose. 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; I suspect that this functionality might require a bit more
consideration before it is fully-baked.

I would note that the pre-emption of ringback with tones and announcements
can occur in many PSTN interworking scenarios, so while it is undesirable, I
wouldn't go so far as to say it's unacceptable as a user experience.

Jon Peterson
NeuStar, Inc.

> From: William Marshall [mailto:[email-masked]]
> Sent: Friday, August 09, 2002 6:22 AM
> To: [email-masked]

---

From: Al Varney <[email-masked]>
Date: Fri, 09 Aug 2002 17:40:48 -0500

At 06:13 PM 8/9/02 +0100, Mark Watson wrote:
>encountered' and 'ISUP used all the way', and that if there is an option 
>it should be to switch between 'Originating Access ISDN' and 'Originating 
>Access Non-ISDN'.
>

    I'm not sure SIPPING is the place for historical explanations (I've put 
it at the end, easy to ignore).  But there ARE ISUP services that work 
end-to-end even for analog lines, and could fail if interworking is 
indicated.  Worse, even simple behavior such as sending RELease messages 
can be altered.

    Certain call failures in USA networks may be handled differently if an 
"interworking" non-SS7 circuit is in the call path -- tones/announcements 
will be provided from the terminating exchange since the RELease that can't 
be delivered all-the-way back to the originating exchange.  The intent of 
this behavior is to prevent intermediate (long distance) exchanges from 
having to provide tone/announcements at the interworking point in the 
middle of the network.

    Look at draft section 6.15.  A RELease-with-cause is delivered to an 
originating SIP-ISUP gateway from the far-end ISUP network, and the gateway 
"maps" the cause to an appropriate SIP response/status code.   But setting 
"interworking encountered" in the IAM can block that behavior -- even for a 
routine cause value of USER BUSY.  I don't think folks want to have BUSY 
TONE played back through the network to a SIP user when a 4xx message could 
have been used.  (Not to mention that the SIP equipment will be unable to 
invoke any automatic handling of a "486 Busy here" status if a tone were 
delivered.)

    It seems to me that these sort of "alternative behaviors" are more 
likely (rather than totally broken services) if "interworking encountered" 
is used for SIP end-points.  SIP would be failing to fully exploit ISUP, 
but calls would still "work".

    However, the opinion of Jon and other draft authors is what really 
counts here.  I was remiss in failing to comment on the ISUP-SIP document 
prior to end of Last Call, and in failing to follow SG11 closely enough to 
realize their FCI/BCI input also failed to make this distinction.  In 
"retirement", one gets lazy.

Al Varney

--
    Why 2 ISUP interworking indicators:  The 2 interworking indicators are 
SS7 and ISUP end-to-end indicators (from originating exchange to 
terminating exchange), independent of the type of access interface to those 
exchanges.  Early in SS7, it seemed useful to have a per-call indicator of 
whether SS7 was available end-to-end.  This would allow exchanges to 
determine when it could depend on being able to signal (out-of-band) all 
the way from one end to the other for new services (or to improve old 
ones).  Thus even SS7 TUP (Q.724) has such an indicator -- TUP IAM and ACM 
messages have an "all SS7 path" indicator.

    Next came ISUP, adding explicit support for ISDN access, and lots of 
other non-ISDN capabilities.  Since it had to work with both TUP and 
pre-SS7 trunks, it too has an explicit "no interworking (SS7 all the way)" 
indicator for end-to-end SS7 connections (which might be a mixture of ISUP 
and TUP).  But since there might be new end-to-end ISUP services created in 
the future that would fail if TUP were in the connection, ISUP has a 2nd 
"ISDN user part used all the way" indicator to indicate end-to-end ISUP 
(with no TUP).

    Somewhat orthogonal to these indicators is the ISDN access 
indicator.  Since TUP has no means of carrying this indicator, an ISUP IAM 
can start out with "originating access ISDN", interwork with TUP and arrive 
at a terminating ISUP switch with the ISDN access indicator dropped.  But 
it still has "SS7 all the way" set, so the terminating exchange knows, for 
example, that it can reliably send at least TUP-supported messages back to 
the originating exchange.  (Thankfully, SS6 had no such SS6-all-the-way 
indicator to also be mapped into ISUP.)
--

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 9 Aug 2002 20:41:57 -0400

Thanks for this extremely valuable historical perspective. In response to
SG11's comments, I asked them for an assessment of the effects of setting
the Interworking indicators in FCI/BCI, and I must say I hadn't imagined it
could be this damaging. From what you say below it sounds as if much of our
mapping work (like cause code to status code mapping, for example) would
simply never be used if 'interworking encountered' was signaled in the FCI
of an IAM by a gateway. Obviously, we couldn't endorse this as a gateway
practice.

Although I hesitate to tweak our recommendations yet again at this stage of
the process, these data-points are very persuasive. I'll therefore add some
language to -06 that describes these considerations. The guidelines will
encourage populating the three protocol-support-related indicators in
FCI/BCI more or less as summarized in Mark's mail earlier today  - I'll need
to mull normative strengths a bit.

But I'll only do so if you all promise that this matter is now closed. :)
Seriously though, if there are other important fixes (related to FCI/BCI or
not), we need to get them on the list as soon as possible. Otherwise they
will have to be corrected in future revisions of this document.

Jon Peterson
NeuStar, Inc.

> Sent: Friday, August 09, 2002 3:41 PM
> To: [email-masked]

---

From: William Marshall <[email-masked]>
Date: Sat, 10 Aug 2002 20:53:04 -0400 (EDT)

Jon Peterson wrote:
> purpose. ...

If the PSTN G/W were to insert the following header in the 180-Ringing:

  Alert-Info: <data:audio/basic;base64,AAAAAA>

it would be completely within rfc3261; the sound file is contained inside
the URL, and consists of mu-law silence.  When the media starts arriving, it
preempts this locally-generated "ringback".  No overloading needed at all.

> wouldn't go so far as to say it's unacceptable as a user experience.

While I agree that preemption of ringback by a tone or announcement can
occur (like in 0.1% of calls), using this as an excuse to break the other
99.9% ....

While it would certainly be possible to require gateway vendors to insert
the above Alert-Info header in their 180-Ringing response, and thereby
fix the problem, it would be preferred if there was a somewhat more 
intuitive indication of what is expected.  

Bill Marshall
[email-masked]

-----original message-----
From: "Peterson, Jon" <[email-masked]>
To: "'William Marshall'" <[email-masked]>, [email-masked]
Subject: RE: [Sipping] new draft-ietf-sipping-isup-05
Date: Fri, 9 Aug 2002 14:08:07 -0400 

Jon Peterson
NeuStar, Inc.

---

From: "Bose, Anjan" <[email-masked]>
Date: Sat, 10 Aug 2002 22:39:43 -0400

Bill, Jon,
	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>

	It would be explicit to the UAC that it was about to receive in-band
ringback.

Anjan

-----Original Message-----
From: William Marshall [mailto:[email-masked]]
Sent: Saturday, August 10, 2002 6:53 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] new draft-ietf-sipping-isup-05

Bill Marshall
[email-masked]

-----original message-----
From: "Peterson, Jon" <[email-masked]>
To: "'William Marshall'" <[email-masked]>, [email-masked]
Subject: RE: [Sipping] new draft-ietf-sipping-isup-05
Date: Fri, 9 Aug 2002 14:08:07 -0400 

Jon Peterson
NeuStar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 12 Aug 2002 14:26:38 -0500

"... completely within rfc3261." Well, we can all read section 20.4 of
RFC3261 and judge for ourselves - I'm not interested in arguing this point
at great length, but I feel that if we want a header that is an explicit
(rather than implicit, overloaded and non-interoperable) indication that
early media will or will not be played, that header is not Alert-Info.
Telling a phone to play silence as an alert tone could have any number of
semantics (like, override any early media with this silence - I'm sure some
proxies, which can add Alert-Info at their discretion, would find this
interpretation useful). We would want a new header that was created for this
purpose.

Any fully-featured early media solution will require an extension to SIP,
and in the process of defining that extension any new header(s) could be
specified as necessary to provide an explicit indication of whether or not
early media will be provided. SIPPING-ISUP is however not the place to
define or frame that extension.

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

It might also make sense to recommend that gateways which support no early
media extension begin transmitting backwards media before sending a 18x
response when ISUP states that provisional in-band information is present.

Essentially, both of these measures would combat that race condition. Would
this be okay for now? With the understanding that fully-featured early media
systems in the future will attack this problem more directly?

Jon Peterson
NeuStar, Inc.

> Sent: Saturday, August 10, 2002 8:53 PM

---

From: "Bose, Anjan" <[email-masked]>
Date: Tue, 13 Aug 2002 14:52:34 -0400

Gonzalo,
		It does make things simpler and easier for software
engineers, since one can just have a case statement when the flag is
received and perform the necessary(if any) functions.
		The flag in itself doesn't enhance user experience, but
having local ringback and then remote ringback is a bit klunky.  All can be
addressed by checking the SDP, but the more explicit the indication, and
higher up in the message structure that the indication is, the easier,
simpler, and cleaner, the implementation becomes.
		A lot of things are possible in software, the only question
is whether we the implementation is as kludgey as PSTN telecom software
usually is or whether we can spec something that has the possibility of
actually being readable and easy to implement.

Anjan

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Tuesday, August 13, 2002 10:45 AM
To: Bose, Anjan
Cc: Christer Holmberg; Michael Hammer; Peterson, Jon; 'William
Marshall'; [email-masked]
Subject: Re: [Sipping] new draft-ietf-sipping-isup-05

Anjan,

I would argue that adding extra flags does not make things easier or
simpler, but I guess this depends on the point of view... anyway, how
would you see such a flag enhacing the user experience? That is, what do
you have in mind that you cannot do with UPDATE and the SDP direction
attribute that you will be able to make with the flag?

It will be useful to know the services we are missing in order to fix
our current mechanism.

Thanks,

Gonzalo

"Bose, Anjan" wrote:
> 
>         Gonzalo,
>                 But having a flag would make implantations clearer,
simpler,
> and easier to understand and enhance the user experience.
> 
> 
> Anjan
> 
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Tuesday, August 13, 2002 7:38 AM
> To: Christer Holmberg
> Cc: Michael Hammer; Peterson, Jon; 'William Marshall'; [email-masked]
> Subject: Re: [Sipping] new draft-ietf-sipping-isup-05
> 
> Christer,
> 
> > Yes, there ARE ways (using UPDATE for example) to first set the mode to
> > inactive/sendonly, and then change the mode to sendrecv when the called
> > party answers, but those methods are very "heavy"
> 
> OK, now it seems that you understood my previous messages. A flag would
> reduce traffic, but it will not add new information.
> 
> It is good to keep in mind that such a flag would be an optimization,
> not an enabler of things that cannot be done today.
> 
> Gonzalo
> 

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: William Marshall <[email-masked]>
Date: Wed, 14 Aug 2002 08:54:49 -0400 (EDT)

Gonzalo wrote:
> [Bill Marshall wrote]:
> >   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.
> 
> 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?

A "solution" that results in clipping the initial conversation is so 
fundamentally broken that it doesn't deserve consideration at all.

To make working code would require a local policy that "a=inactive" be
treated identically to "a=sendrecv", i.e. play the media.  This reduces 
to the original case, where local ringback is preempted by remote
ringback.  This is not a solution.

I remain convinced that there are only two solutions:
  1) use a 183 if remote ringback will be provided, instead of 180
  2) include some indication (e.g. Alert-Info) in a 180 if remote ringback
	will be provided

Since this whole problem of early media arises because of PSTN interworking,
the solution needs to be documented in the ISUP-SIP draft.  The issue was
raised during WGLC, but has not yet been adequately addressed in the draft.

Bill Marshall
[email-masked]

-----original message-----
Date: Wed, 14 Aug 2002 10:55:29 +0300
From: Gonzalo Camarillo <[email-masked]>
To: William Marshall <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sipping] new draft-ietf-sipping-isup-05

Bill,

William Marshall wrote:
> 
> 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.

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.

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

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.

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

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

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

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?

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

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.

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

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: [email-masked]
Date: Wed, 14 Aug 2002 10:57:55 EDT

To all,

The new -05 of sipping-isup does not resolve the comment I submitted on the 
IETF Last Call. There does not appear to be any attempt to deal with this 
comment. The comment, for those not on the IESG mailing list, was:

------------------------------------------------
Section 11 of this draft references RFC2806 which is currently undergoing a 
significant revision (draft-antti-rfc2806bis-05, which is very close to 
completion after much discussion). This tel:uri is very important to the 
operation of ISUP-to-SIP interworking and can not be ignored, or brushed off 
as "informational since it is optional" as reported in the recent meeting. 
Its use is very much required to provide the mapping described (in spite of 
the use of the word "should").

Section 11 must be significantly modified to be in line with the new tel:uri 
definition.
-----------------------------------------------

(Section 11 is now 12 in -05)

Instead, a new Section 12.2 was added which appears to further depend on the 
old, out-of-date definition of the tel:url in RFC2806.

The actual text of this new Section 12.2 further confuses the issue by 
describing the mapping from SIP to ISUP (e.g., handling of the called party 
number) as depending on what the GW has connectivity to, rather than 
dependent on where the particular call is routed by the GW. Whether the GW 
formats the number in ISUP as "national significant number" or 
"international" depends on the requirements of the trunk it routes the call 
to.

I don't understand the extensive use of "SHOULD" in this section (and 
others). If it can't be written as "If this occurs, the GW SHALL do that", 
then it is useless in defining interworking that is guaranteed to work.

The requirements to support ISUP to SIP and SIP to ISUP interworking need to 
be fully identified so that they can be fed back into the definition of the 
tel:uri. These documents can not progess separately.

Mike Pierce
Artel

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 15 Aug 2002 09:36:29 +0100

Jon,

I have been following this thread with interest, because the eventual
solution for SIP-ISUP interworking will probably need to be reflected in
SIP-QSIG interworking.

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), which involves the use of
183 rather than 180 for indicating alerting with remote ringback tone.
Although there will be some circumstances in which a QSIG or ISUP network is
unable to distinguish alerting from other situations (essentially when
interworking with a dumb analogue system behind the QSIG or ISUP network)
and will use PROGRESS/CPG, in most situations the QSIG/ISUP ALERTING/ACM
message will be used and gives a positive indication that alerting is
happening and allows other features applicable in this state (e.g.,
alternative actions on no reply) to be used. Take for example a call from
QSIG via SIP to ISUP. I would expect an ISUP ACM to result in a QSIG
ALERTING. This would be the case for direct interworking from QSIG to ISUP.
The presence of a SIP network in between should not alter this.

Regards,

John

--------------------------------------------------------------
John Elwell ([email-masked])
Siemens Communications Limited,
Technology Drive, Beeston,
Nottingham NG9 1LA, UK
Tel: +44 115 943 4989   Fax: +44 115 943 4969
--------------------------------------------------------------
	Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal responsibility for the
contents of this message. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Siemens
Communications Limited unless otherwise specifically stated.

> Sent: 14 August 2002 19:11
> To: 'William Marshall'; [email-masked]
> Cc: [email-masked]
> A few comments below.
> > Sent: Wednesday, August 14, 2002 8:55 AM
> > To: [email-masked]
> > Cc: [email-masked]
> [snip]
> As I stated in a mail a couple of days ago (since which this 
> thread has
> merrily rolled on by) I am willing to put something that is 
> roughly option
> (1) in sipping-isup-06. It will appear in a few days.
> 
> I also think option (2) is worth discussing further in the 
> context of a more
> fully-featured early media system.
> 
> Can we stop talking about this now?
> 
> It was raised in the context of PSTN interworking, but it is 
> not necessary
> confined to just SIP-ISUP interworking (it would apply 
> equally to other
> forms of PSTN interworking) and in my opinion it could arise for other
> services in SIP networks unrelated to PSTN interworking. 
> Again, I believe
> that we need a general solution for early media, but I do not 
> think we need
> to provide it in sipping-isup-06.
> 
> > 
> > Bill Marshall
> > [email-masked]
> >

---

From: [email-masked]
Date: Thu, 15 Aug 2002 09:55:56 EDT

In a message dated 8/14/02 10:58:04 PM Eastern Daylight Time, [email-masked] 
writes:

>     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 
> (IMO).  Draft-05 was announced by IETF (and Jon) on Aug 7, 2 days after 
> IESGLC.  

As Al noted, there were significant changes in -05. For those who don't look 
at file sizes, -05 is 26k bytes larger that -03 (which went to IETF LC), so 
there is a significant amount of addition.

I too have found problems in -05 which were not in -04. I'm writting up the 
comments. Regardless of the result of any discussion, I believe it is 
necessary to have a new Last Call when that many changes are made.

Mike Pierce
Artel

---

From: [email-masked]
Date: Thu, 15 Aug 2002 09:56:32 EDT

In a message dated 8/15/02 2:29:34 AM Eastern Daylight Time, 
[email-masked] writes:

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

[MAP] Now I'm really confused! A message played by your answering machine 
(the application) must be handled exactly like one spoken by you whan you 
pick up the phone (another application). There must be an answer in the 
protocol when the answering machine starts. Just like the call to the human 
application, early media might exist in this case to prevent speech clipping, 
not to allow the entire message to get through. I can't imagine any service 
provider allowing otherwise.

If anyone thinks that the purpose of early media is to let someone's 
answering machine message to get through without returning answer (or the SIP 
equivalent), then I think the discussion is certainly digressing from the 
known requirements. By the way, where is the agreed set of requirements for 
this?

Mike Pierce
Artel

---

From: [email-masked]
Date: Thu, 15 Aug 2002 09:58:48 EDT

In a message dated 8/14/02 11:27:53 AM Eastern Daylight Time, 
[email-masked] writes:

> Reading this long, long thread, one might conclude that SIP/ISUP mapping is 
> somehow a new and untested thing.  Actually, it has been out there and 
> implemented for years now, and guess what - it works!  Some of us have 
> commercial products that use it.
> 
> It is true that if you do three or four questionable things in a row, it is 
> possible to get clipping.  However, these cases can be avoided.  If you 
> want to know how, look at the call flows or talk to a vendor that 
> understands SIP/ISUP interworking.
> 
> Lets get this document finished - Gonzalo and Jon have done an excellent 
> job of fielding all these last minute questions and theoretical 
> discussions, but we need to move on.
> 

[MAP] I somehow do not see that many of the discussions that have occurred 
are "theoretical". They have dealt with real, live situations.

If SIP/ISUP interworking, with the full set of capabilities, is out there and 
working, then I don't know why there should be any of this discussion at all, 
or any thought of changing anything. But then, I suspect that various 
participants in this discussion have different ideas of what "working" means.

Regarding speech clipping, if the current RFCs/drafts clearly state what each 
entity "MUST" do to prevent it, then there is no problem. But I doubt that 
any mandatory operation is given, so the problem is not solved. (In other 
words, if three or four separate entities each do one "questionable" but 
allowed thing, can clipping occur?) For example, Section 7.2.6 of -05 says a 
lot of "MAY" and "SHOULD" regarding when the gateway begins sending media. 
There are no requirements. It seems to me from the ongoing discussion that 
the whole issue of "early media" is very much unsolved. Without a solution to 
these issues, SIP-ISUP interworking can not work (properly).

Mike Pierce
Artel

---

From: Adam Roach <[email-masked]>
Date: Thu, 15 Aug 2002 10:04:21 -0500

> This is not an acceptible user experience.

Huh. I've had exactly this happen on my cell phone before. I thought
of it as mildy odd (and tried to work out why the ringtone might
subtly change timbre mid-ring), but it didn't amount to anything
that I'd consider unacceptable or even mildly annoying.

Perhaps I'm just too accepting of the vagaries of technology.

/a

---

From: David Oliver <[email-masked]>
Date: Thu, 15 Aug 2002 10:36:43 -0500

> Summary of this thread so far:
<...>
> 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
<...>

A better variant of (0) / "get this draft out" is to release the draft with
a statement of this being an unresolved issue, needing to be resolved
elsewhere or in a later draft.

Option (1) has the problem that (per 3261/21.1.5) 183 Session Progress is
used to convey information that is not otherwise classified; "Ringing" (i.e.
trying to alert the user) *is* classified as 180, so this would be
inconsistent.

Option (2) is more consistent with 3261/21.1.2, which states that a 180
Ringing response MAY be used to initiate local ringback. For some
non-phone-like applications, such as messaging or videoconferencing, local
ringback wouldn't make sense, and the "MAY" allows local policy to omit it.

IETF standards do not specify user interfaces. However, for phone-like
applications, the standard should allow (though not require) implementations
to be able provide the user with a phone-like experience. The "MAY" in
21.1.2 does not prohibit providing local or far end ringback as appropriate,
but requires extra work (or telepathy) to achieve it. I believe that a flag
of "SHOULD" weighting indicating "do not initiate local ringback" is
appropriate; this would not preclude the initiation of other (e.g. visual)
status indications.

I therefore would agree with option (2), except that the problem and
solution are too general for ISUP, so option (0) with an explanatory note is
probably the right answer.

Regards,

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