Subject: RE: [Sipping] Question on ISUP to SIP mapping draft

From: Romel Khan <[email-masked]>
Date: Mon, 1 Apr 2002 16:54:04 -0500

Some SIP node are not designed to look at the encapsulated
ISUP.....(complicates some things pointlessly). Some SIP nodes will get rid
of the ISUP body. So by the time the terminating SIP endpoint gateway (that
interworks to SS7) receives the SIP message there is no ISUP body. Moreover,
looks like most switches today will not look at the ISUP body in SIP msg to
interwork to ISUP.

Is there any particular hindrance towards making a relevant bunch of these
SIP Status code to/from ISUP cause code bidirectional interworking (using
sec 6.2.4.1 as starting base)? If I were to be able to vote I would request
bidirectional whereever possible. Of course, majority of the cases looks
like multiple ISDN cause maps to a single SIP status code, e.g. cause
34,41,etc to SIP 503; SIP 503 to one of those, such as, cause 41 is
reasonable. But if it is one to one mapping in sec 6.2.4.1, it is reasonable
to have it map the other way round. Examples are: 
Already defined:
SIP 486 <==> ISDN cause 17 
SIP 484 <==> ISDN cause 28

Requesting:
-- SIP 408 <==> ISDN cause 18

-- Sec. 6.2.4.1 defines ISDN cause 19,20,31 ==> SIP 480, then SIP 480 to
ISDN cause 18 as in sec. 7.2.6.1 is unreasonable. Mapping to ISDN cause 19
or 20 or 31 is the reasonable choice.

Thanks,
Romel 
Net2Phone

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Monday, April 01, 2002 10:41 AM
To: Romel Khan
Cc: [email-masked]; [email-masked]'
Subject: Re: [Sipping] Question on ISUP to SIP mapping draft

Romel,

That is not the only case where such non-bi-directional mapping occurs.

I would recommend using only the encapsulated ISUP for transit 
situations.  The response codes should only be used to ISUP cause codes 
when the SIP message source is a SIP node.

Mike

At 03:05 PM 3/31/2002 -0500, Romel Khan wrote:
>1. Mapping ISDN cause to SIP status in section 6.2.4.1 states that cause 18
>"no user responding" to SIP 408 Request Timeout. This is reasonable.
>However, in section 7.2.6.1, for SIP to ISUP, it shows 408 to ISDN cause
102
>Recovery on timer expiry. This is unreasonable. This interworking should be
>bidirectional:
>SIP 408 <==> ISDN cause 18 "No User Responding"
>
>An example of why it is unreasonable: With a SIP B2BUA where there is an
>inbound leg and an outbound leg for a call going to a Softswitch which
>terminates SS7. Callee starts ringing and does not pick up the phone within
>a period which causes the ring timer in the Softswitch to expire. The
>Softswitch then sends 408 to the B2BUA, which will send back the 408 on the
>inbound leg. If the PSTN connectivity to the Inbound is SS7 or ISDN, don't
>want the corresponding REL/DISC msg to interwork with cause 102 but rather
>the cause should be 18 "No User Responding". Why should SIP 480 map to ISDN
>cause 18 in this case? Why not please keep some of these interworking same
>both ways (bidirectional) ==> simplifies many implementer's life, minimizes
>departure from the spec.,enhances interoperability.
>
>
>2. Need a SIP status code that interworks to ISDN cause 31 "Normal
>Unspecified".
>
>
>Thanks,
>Romel
>
>_______________________________________________
>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

_______________________________________________
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: Michael Hammer <[email-masked]>
Date: Mon, 01 Apr 2002 17:30:47 -0500

Romel,

There is no control over the received ISUP message's choice of cause 
value.  Because of the many-to-one mapping problem, trying to force it to 
be bi-directional, can only mean that there must be a unique response code 
for every ISUP cause code.  I'm not sure that is necessary.

It is not good for the SIP nodes to discard what it cannot understand.  I 
believe proper behavior is to ignore and transmit on.

In any case, if a transit situation requires the ISUP, then the Requires 
header should probably be used to avoid arbitrary dropping of the ISUP 
body.  Otherwise, you will get the less-than-transparent experience you cite.

The interesting question is how do you know at the ingress that you are 
going to an egress gateway versus a smart end-point.  Presumably, ENUM is 
point you to a smart endpoint, but responses from the SIP network may 
divert you to a PSTN number not local to your gateway that then requires 
TRIP or local configuration to select the egress gateway.  Or you are only 
a transit network to begin with.

Thoughts?

Mike