Subject: RE: [Sipping] Comments on ISUP to SIP mapping

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 28 May 2002 18:09:49 -0500

It's true, there hasn't been much discussion of this draft lately - probably
because it completed working group last call some time ago now, and much of
the correspondence about this draft, for whatever reason, has historically
taken place off the list. We are however preparing a few changes based on
some straggling comments in preparation for IESG last call, so this would be
a good time to point out any issues.
 
A few points inline below.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, May 27, 2002 2:26 PM
To: [email-masked]
Subject: [Sipping] Comments on ISUP to SIP mapping

Comments on draft-ietf-sipping-isup-01 (Feb 2002) 

Looking back over this draft and reviewing the archives, I didn't find a lot
of discussion. Hope that these issues haven't been addressed already. 

2. Scope: The reference for ITU-T ISUP would be better as Q.761-764 rather
than Q.767, which is old. 
[Peterson, Jon] Q.767 was selected as a baseline because it is used for
normalized, international ISUP transit. Still, a lot of detail from national
variants has crept in. And the documents you name above are also referenced
by the text (see references [10] and [18]) when they are needed.

6.1.4 It is unknown how it could occur that the originator sends an INVITE,
but then fails to respond to the 200 sent back (answer). This error case is
not shown in other call flows examples. If the 200 fails once, it seems
reasonable to release the call. Is the same repetition required for the BYE?

[Peterson, Jon] I think the error conditions in which this would occur are
pretty obvious (I am using a somewhat flaky SIP phone, I send an INVITE and
then my phone reboots, for example). We are trying to characterize
interworking behavior for gateways, and personally I think this is a
reasonably valuable case. The idea that a call should be released if one 200
OK response fails to be delivered seems pretty ungenerous to me. SIP
requires retransmissions of requests and responses (with some dependencies
on underlying transport), yes, see Section 17 of RFC3261.

6.2.4.1 Cause code mapping: 

The following should be deleted: 
26 (Q.850 says DSS1 only) 
[Peterson, Jon] As a note attached to this listing in 6.2.4.1 says, 26 is
used in American networks for some number portability purposes (see, for
example, GR-317) - this is one of the national variant cases that has crept
in. Its mapping is included because cause code 26 actually shows up a fair
amount in the field in our experience.

The following cause codes should be added, since they can be returned by
ISUP: 
8 Preemption 
46 Precedence call blocked 
63 Service or option not available 
69 Requested facility not implemented 
90 Non-existent CUG 
91 Invalid transit network selection 
[Peterson, Jon]  So, why 8, but not 9? Why not '4 Send Special Information
Tone'? There are a number of ISUP codes listed in Q.850 that we have no
mapping for, and which you do not mention above. Note that we have a default
SIP response code in the draft today for all cause codes that aren't listed
- '500 Server Internal Error' - so there is a determinate SIP response code
for any ISUP cause code that is received. The result of receiving a 500 is
that a client MAY retry their request in a few seconds. I believe this is
probably the best mapping for all of the above - with the possibly exception
of 91. There was no corollary in SIP to the TNS - and hence, the TNS has
been proposed as a tel URL parameter in James Yu's draft, but it still isn't
entirely clear that any SIP response code (other than designing a new 'TNS
invalid' status code) would be appropriate for a poorly-formed TNS. I don't
know what to do with that, really - 500 is probably as good as any other
code in RFC3261, anyway.

6.2.6 In many network, there is no timing for receipt of answer. It is a
local option. For example, it may be applied to long-distance and not on
local calls. 
[Peterson, Jon]  T9 is provided for the purposes of completing the FSM.
6.2.6 describes one of the possible state transitions - not the only way
that you can leave the 'Alerting' state. In any event, it is also true that
the caller could cause a state transition by hanging up if there is never
any T9 - but that isn't what 6.2.6 is concerned with. Still, a mention
somewhere in the document that some networks do not use T9 might be helpful.

6.2.8 It isn't clear why "480 temporarily unavailable" would be used "to the
SIP network" in the case of time out waiting for answer. The error response
should say explicitly "no answer from user", just like cause 19 in ISUP.
This fact could be very important to a SIP device trying to use another
feature, such as automatic call back or displaying the correct status to a
user. 
[Peterson, Jon] The implications of a 480 don't seem inappropriate to me for
this case at all. The description for 480 in RFC3261 begins:

   The callee's end system was contacted successfully but the callee is
   currently unavailable 

I'm not sure how to differentiate that from 'no answer from user'. The text
for 480 also says that:
 
   The user could
   also be available elsewhere (unbeknownst to this server). 
 
This would seem to provide the right sort of information to a SIP device
trying to use another feature (most importantly forking). So in other words,
I think 480 is a very good match for 19. Was there something specific you
read in the 480 text in RFC3261 that made you think it wasn't a good fit?
 
9.2.2 It would be acceptable here for the SUS to stop at the MGC/MG which
could then apply a timeout and send the BYE to SIP only when the timeout
expires or a REL is received from the PSTN. There is no need to go through
the INVITE/200/ACK procedure for every SUS, which is the normal call release
sequence when the called analog phone hangs up first. In a way, the SUS was
a way to handle the awkward timeout procedures for release in the PSTN. This
does not have to be carried through to SIP. 
[Peterson, Jon]  I'd be the first to say that the proposed INVITE-based SUS
method is cumbersome, sure. That's why we have two options presented in the
text - either using the re-INVITE system, or using the INFO method. There is
some text in 8.1, where SUS and RES mappings are first defined, that starts
with the following:

   If media suspension is not required by the MGC receiving the SUS from
   the PSTN, the SIP INFO [9] method can be used to transmit an
   encapsulated SUS rather than a re-INVITE.  

Do we also need a third method, in which the SUS and RES are consumed by a
gateway, rather than passing through the SIP network via ISUP encapsulation?
Well, as I'm sure you're aware, SUS is also used for other purposes than
setting a timer in advance of a standard release. When SIP is bridging
between two PSTN netowrks, sending the SUS and RES across provides some
valuable information in these cases, I think. I suspect that the two options
we have already specified are probably sufficient.
 
It could be argued that the example in 9.2.2 should use the INFO method
rather than the INVITE system. The INVITE system is used througout the
examples.
 
10.3 It is unknown why the continuity check should not apply to any IP media
paths. It may be more important there than in the circuit-switched world in
which the higher level multiplex systems provide sufficient supervision of
the path. 
Further, it states that "if the continuity check fails" then an INVITE
should not be sent. The normal procedure, to reduce the call setup time, is
to send the forward call setup signaling immediately before the continuity
check is complete. Only in the rare case of a failure is it necessary to
release a call setup that has begun. 
[Peterson, Jon]  The most obvious problem with allowing continuity to pass
into a SIP network is that a call from a SIP gateway may land on a vanilla
SIP phone. Should we expect Pingtel and Cisco et al to implement continuity
procedures? All of SIP-ISUP mapping becomes much easier if you assume that
SIP can only bridge between ISUP realms - but the scope of our document
requires that we consider that calls originating in an ISUP network may
terminate in a SIP network and vice versa.
 
One might also question whether or not playing a continuity tone is really
the best way to manage QoS in an IP environment. Some other proposals have
been made in this working group and elsewhere for general systems to assure
QoS in SIP. ISUP, which is effectively used only to set up audio media
paths, can use a DSP-based test to determine the integrity of the media path
definitively. SIP, however, deals with many different sorts of media, and
should presumably have a more general QoS mechanism (perhaps based on
network QoS). So if we were going to map continuity to anything, I suspect
it would be something along those lines.
 
Either waiting for a COT before sending the INVITE or sending an INVITE
preemptviely and risking a CANCEL are clunky- we just had to choose one. The
difference here between SIP and ISUP is that an IAM goes to a switch, which
then chooses to alert a terminal as appropriate, whereas an INVITE usually
goes to an endpoint, which will begin alerting as soon as it receives the
INVITE. Hence, in one of the SIP QoS proposals the concept of
'preconditions' was proposed in order to prevent alerting until certain
preconditions (similar to continuity) were fulfilled. The point is that
sending an INVITE when you don't know whether or not continuity has
completed has a very different implication in SIP than the parallel case
does in ISUP.

12.1 This notes that SIP does not ensure that INFO messages are delivered in
order. Then how are any other messages delivered in order? It is not a good
idea to say that this "is not likely to happen and its effects are
negligible in most situations". This is what gets the whole protocol into
trouble later. Either the order of the messages is guaranteed, or other
provisions need to be made. 
[Peterson, Jon] This is a question about whether or not INFO messages (or
indeed, any non-INVITE transactions) should be able to overlap - if they can
overlap, then their delivery order is not determinate (though it is, as we
said, "unlikely" that the messages will arrive in a different order than
they are sent) over some transport layers. We debated for a long time in the
SIP working group if non-INVITE transactions that take place within a dialog
(like the transmission of an INFO) should be allowed to overlap or not.
Eventually, we decided to allow overlapping non-INVITE transactions in SIP
in general.

You also have to ask yourself, though, if there is some specific ISUP
message that would end up being mapped to an INFO method that would cause
any delivery order concerns for you. Gateways could be implemented that send
only one INFO method at a time as well.

Mike Pierce 
Artel

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 29 May 2002 07:39:01 +0200

Hi all,

2. Scope: The reference for ITU-T ISUP would be better as Q.761-764 rather than Q.767, which is old. 
[Peterson, Jon] Q.767 was selected as a baseline because it is used for normalized, international ISUP transit. Still, a lot of detail from national variants has crept in. And the documents you name above are also referenced by the text (see references [10] and [18]) when they are needed.

[Jesske, Roland] 
 Q.767 is a minimum set of Q.761-764. If you are referring to Q.761-764, implicit you are also referring to Q.767. [10] is Q.764 1993 and [18] Q.763 1997 --> I think you should refer to the newest and complete Q.761-Q.764. At the ITU Webpage you never find the standards from 1993 and 1997, you will find only the 1999 Standards. 
 
My proposals is to change the references regarding Q.761-764 to:
 
[10] International Telecommunications Union, "Signaling System No.

7; ISDN User Part Signaling procedures", ITU-T Q.764, September 

1997 December 1999,  <http://www.itu.int> http://www.itu.int.

[18] International Telecommunications Union, "Formats and codes of

the ISDN User Part of Signaling System No. 7", ITU-T Q.763,

March 1993 December 1999, <http://www.itu.int>.

[21] International Telecommunications Union "Signalling System No. 

7 - ISDN User Part general functions of messages and signals", 

ITU-T Q.762, December 1999, <http://www.itu.int>.

[22] International Telecommunications Union " Signalling system No. 7

-ISDN user part functional description ", ITU-T Q.761, December

1999, <http://www.itu.int>.

Best Regards 
 
Roland

_______________________________________________
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: Frank Miller <[email-masked]>
Date: Wed, 29 May 2002 10:11:58 -0400

I don’t know if anyone is interested,
but we have been implementing the SIP-to-ISUP mapping draft recently and have
added some support for additional ISUP commands, i.e. the maintenance commands
in Telcordia GR-246 (the work is targeted at North American ILECs).  An
Internet draft, draft-miller-sip-isup-annex, has been available on the IETF
website for about a month:

"Carrying
ISUP in SIP Messages (SIP-ISUP-ANNEX)", Frank Miller, 04/29/2002. (65393
bytes)

The title certainly needs to be changed to reflect the fact that it is
focused on maintenance commands only.  In addition, we have prepared a
similar draft that non-persistent TCAP to be carried as well.  That draft
is in formatting and will be published in the near future.  A Microsoft
word version is available if you send me an email…

FM

Frank W. Miller, Ph.D.

Chief Technical Officer

sentitO Networks, Inc.

[email-masked]

Phone: (301) 947-1900 x223

Mobile: (410) 404-8790

-----Original Message-----

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Peterson,
Jon

Sent: Tuesday, May 28, 2002 7:10
PM

To: [email-masked]';
[email-masked]

Subject: RE: [Sipping] Comments on
ISUP to SIP mapping

It's true, there hasn't
been much discussion of this draft lately - probably because it completed
working group last call some time ago now, and much of the correspondence about
this draft, for whatever reason, has historically taken place off the list. We
are however preparing a few changes based on some straggling comments in
preparation for IESG last call, so this would be a good time to point out any
issues.

A few points inline
below.

Jon Peterson

NeuStar, Inc.

-----Original
Message-----

From: [email-masked]
[mailto:[email-masked]]

To: [email-masked]

Subject: [Sipping] Comments on
ISUP to SIP mapping

Comments on
draft-ietf-sipping-isup-01 (Feb 2002)

Looking back over this draft and reviewing the archives, I didn't find a lot of
discussion. Hope that these issues haven't been addressed already.

2. Scope: The reference for ITU-T ISUP would be better as Q.761-764 rather than
Q.767, which is old.

[Peterson, Jon] Q.767 was
selected as a baseline because it is used for normalized, international
ISUP transit. Still, a lot of detail from national variants has crept in.
And the documents you name above are also referenced by the text (see
references [10] and [18]) when they are needed.

6.1.4 It is unknown how it could occur that the originator sends an INVITE, but
then fails to respond to the 200 sent back (answer). This error case is not
shown in other call flows examples. If the 200 fails once, it seems reasonable
to release the call. Is the same repetition required for the BYE?

[Peterson, Jon] I think the
error conditions in which this would occur are pretty obvious (I am using a
somewhat flaky SIP phone, I send an INVITE and then my phone reboots, for
example). We are trying to characterize interworking behavior for gateways, and
personally I think this is a reasonably valuable case. The idea that a call
should be released if one 200 OK response fails to be delivered seems pretty
ungenerous to me. SIP requires retransmissions of requests and responses (with
some dependencies on underlying transport), yes, see Section 17 of RFC3261.

[Peterson, Jon] As a
note attached to this listing in 6.2.4.1 says, 26 is used in American
networks for some number portability purposes (see, for example, GR-317) -
this is one of the national variant cases that has crept in. Its mapping is
included because cause code 26 actually shows up a fair amount in the field in
our experience.

The following cause codes should be added, since they can be returned by ISUP:

8 Preemption

90 Non-existent CUG

[Peterson, Jon]  So, why 8,
but not 9? Why not '4 Send Special Information Tone'? There are a number
of ISUP codes listed in Q.850 that we have no mapping for, and which you do not
mention above. Note that we have a default SIP response code in the draft today
for all cause codes that aren't listed - '500 Server Internal Error' - so there is a
determinate SIP response code for any ISUP cause code that is received. The
result of receiving a 500 is that a client MAY retry their request in a few
seconds. I believe this is probably the best mapping for all of the above -
with the possibly exception of 91. There was no corollary in SIP to the TNS -
and hence, the TNS has been proposed as a tel URL parameter in James Yu's
draft, but it still isn't entirely clear that any SIP response code (other than
designing a new 'TNS invalid' status code) would be appropriate for a
poorly-formed TNS. I don't know what to do with that, really - 500 is probably
as good as any other code in RFC3261, anyway.

6.2.6 In many network, there is no timing for receipt of answer. It is a local
option. For example, it may be applied to long-distance and not on local calls.

[Peterson, Jon]  T9 is
provided for the purposes of completing the FSM. 6.2.6 describes one of
the possible state transitions - not the only way that you can leave the
'Alerting' state. In any event, it is also true that the caller could
cause a state transition by hanging up if there is never any T9 - but that
isn't what 6.2.6 is concerned with. Still, a mention somewhere in the document
that some networks do not use T9 might be helpful.

6.2.8 It isn't clear why "480 temporarily unavailable" would be used
"to the SIP network" in the case of time out waiting for answer. The
error response should say explicitly "no answer from user", just like
cause 19 in ISUP. This fact could be very important to a SIP device trying to
use another feature, such as automatic call back or displaying the correct
status to a user.

[Peterson, Jon] The implications of a 480 don't seem inappropriate to me
for this case at all. The description for 480 in RFC3261 begins:

The callee's end system was contacted successfully but the callee
is

currently unavailable

I'm not sure how to differentiate that from 'no answer from user'. The text for
480 also says that:

The user
could

This would seem to
provide the right sort of information to a SIP device trying to use another
feature (most importantly forking). So in other words, I think 480 is a very
good match for 19. Was there something specific you read in the 480 text in
RFC3261 that made you think it wasn't a good fit?

9.2.2 It would be acceptable here for the SUS to stop at the MGC/MG
which could then apply a timeout and send the BYE to SIP only when the timeout
expires or a REL is received from the PSTN. There is no need to go through the
INVITE/200/ACK procedure for every SUS, which is the normal call release
sequence when the called analog phone hangs up first. In a way, the SUS was a
way to handle the awkward timeout procedures for release in the PSTN. This does
not have to be carried through to SIP.

[Peterson, Jon]  I'd be the
first to say that the proposed INVITE-based SUS method is cumbersome, sure.
That's why we have two options presented in the text - either using the
re-INVITE system, or using the INFO method. There is some text in 8.1,
where SUS and RES mappings are first defined, that starts with the following:

If media suspension is not required
by the MGC receiving the SUS from

Do we also need a third method, in which the
SUS and RES are consumed by a gateway, rather than passing through
the SIP network via ISUP encapsulation? Well, as I'm sure you're aware, SUS is
also used for other purposes than setting a timer in advance of a standard
release. When SIP is bridging between two PSTN netowrks, sending the SUS and
RES across provides some valuable information in these cases, I think. I suspect
that the two options we have already specified are probably sufficient.

It could be argued that
the example in 9.2.2 should use the INFO method rather than the INVITE system.
The INVITE system is used througout the examples.

10.3 It is unknown why the continuity check should not apply to any IP media
paths. It may be more important there than in the circuit-switched world in
which the higher level multiplex systems provide sufficient supervision of the
path.

Further, it states that "if the continuity check fails" then an
INVITE should not be sent. The normal procedure, to reduce the call setup time,
is to send the forward call setup signaling immediately before the continuity
check is complete. Only in the rare case of a failure is it necessary to release
a call setup that has begun.

[Peterson, Jon]  The most
obvious problem with allowing continuity to pass into a SIP network is that a
call from a SIP gateway may land on a vanilla SIP phone. Should we expect
Pingtel and Cisco et al to implement continuity procedures? All of SIP-ISUP
mapping becomes much easier if you assume that SIP can only bridge between ISUP
realms - but the scope of our document requires that we consider that calls
originating in an ISUP network may terminate in a SIP network and vice versa.

One might also question
whether or not playing a continuity tone is really the best way to manage
QoS in an IP environment. Some other proposals have been made in this working
group and elsewhere for general systems to assure QoS in SIP. ISUP, which is
effectively used only to set up audio media paths, can use a DSP-based test to
determine the integrity of the media path definitively. SIP, however, deals
with many different sorts of media, and should presumably have a more general
QoS mechanism (perhaps based on network QoS). So if we were going to map
continuity to anything, I suspect it would be something along those lines.

Either waiting for a COT
before sending the INVITE or sending an INVITE preemptviely and risking a
CANCEL are clunky- we just had to choose one. The difference here between
SIP and ISUP is that an IAM goes to a switch, which then chooses to alert a
terminal as appropriate, whereas an INVITE usually goes to an endpoint, which
will begin alerting as soon as it receives the INVITE. Hence, in one of the SIP
QoS proposals the concept of 'preconditions' was proposed in order to
prevent alerting until certain preconditions (similar to continuity) were
fulfilled. The point is that sending an INVITE when you don't know whether or
not continuity has completed has a very different implication in SIP than the
parallel case does in ISUP.

[Peterson, Jon] This is a
question about whether or not INFO messages (or indeed, any non-INVITE
transactions) should be able to overlap - if they can overlap, then their
delivery order is not determinate (though it is, as we said,
"unlikely" that the messages will arrive in a different order than
they are sent) over some transport layers. We debated for a long time in the
SIP working group if non-INVITE transactions that take place within a dialog
(like the transmission of an INFO) should be allowed to overlap or not. Eventually,
we decided to allow overlapping non-INVITE transactions in SIP in general.

You also have to ask yourself, though, if
there is some specific ISUP message that would end up being mapped to an
INFO method that would cause any delivery order concerns for you. Gateways
could be implemented that send only one INFO method at a time as well.

Mike Pierce

Artel

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 31 May 2002 19:59:00 -0500

I am at a bit of loss to explain where those dates came from; those weren't
the dates on the issues of the specification that we used for reference. In
any event, they've been updated now.

Jon Peterson
NeuStar, Inc.

> From: Jesske, R [mailto:[email-masked]]
> Sent: Tuesday, May 28, 2002 10:39 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: AW: [Sipping] Comments on ISUP to SIP mapping
> 
> 
> Hi all,
> 
> 2. Scope: The reference for ITU-T ISUP would be better as 
> Q.761-764 rather than Q.767, which is old. 
> [Peterson, Jon] Q.767 was selected as a baseline because it 
> is used for normalized, international ISUP transit. Still, a 
> lot of detail from national variants has crept in. And the 
> documents you name above are also referenced by the text (see 
>  Q.767 is a minimum set of Q.761-764. If you are referring to 
> Q.761-764, implicit you are also referring to Q.767. [10] is 
> Q.764 1993 and [18] Q.763 1997 --> I think you should refer 
> to the newest and complete Q.761-Q.764. At the ITU Webpage 
> you never find the standards from 1993 and 1997, you will 
> find only the 1999 Standards. 
>