Subject: [Sipping] Comments on ISUP to SIP mapping

From: [email-masked]
Date: Mon, 27 May 2002 17:25:33 EDT

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.

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?

6.2.4.1 Cause code mapping:

The following should be deleted:
26 (Q.850 says DSS1 only)

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

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.

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.

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.

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.

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.

Mike Pierce
Artel

---

From: Michael Hammer <[email-masked]>
Date: Tue, 28 May 2002 10:32:00 -0400

Mike,

Agree with your assessment of the SUS/RES procedure.  INVITE/200/ACK seems 
rather heavy-handed for what is more of a call rather than media-related 
procedure.

You need to ask what mechanism would "guarantee" the ordering of the INFO 
messages.  Unless you use a Transport layer that provides such a service, 
you may be safer having the gateways send only one INFO at a time and 
waiting for an ACK (200 response) for each one.  Whether this is viable 
depends on the RTT versus the service intent.

Mike H.

At 05:25 PM 5/27/2002 -0400, [email-masked] wrote:
>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.
>
>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?
>
>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.
>
>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.
>
>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.
>
>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.
>
>Mike Pierce
>Artel

_______________________________________________
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