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

From: Michael Hammer <[email-masked]>
Date: Mon, 01 Apr 2002 10:40:42 -0500

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: Adam Roach <[email-masked]>
Date: Mon, 1 Apr 2002 17:19:01 -0500

> 2. Need a SIP status code that interworks to ISDN cause 31 "Normal

No, you don't.

For normal call clearing, you'll have a flow something
like:

SIP            MGC            PSTN
 |----INVITE--->|              |
 |              |-----IAM----->|
 |              |<----ACM------|
 |----CANCEL--->|              |
 |<----200------|              |
 |<----487------|              |
 |              |-----REL----->| with cause=31
 |              |<----RLC------|

Or:

SIP            MGC            PSTN
 |----INVITE--->|              |
 |              |-----IAM----->|
 |              |<----ACM------|
 |<----180------|              |
 |              |<----ANM------|
 |<----200------|              |
 |-----ACK----->|              |
 |              |<----REL------| with cause=31
 |              |-----RLC----->|
 |<----BYE------|              |
 |-----200----->|              |

So far, no response code mapping is needed.

The only call flow that would possibly use what
you ask for would start something like this:

SIP            MGC            PSTN
 |----INVITE--->|              |
 |              |-----IAM----->|
 |              |<----REL------| with cause=31

To which anyone who knows ISUP will respond: "WHAT?!?!?
I sent an IAM and got **NORMAL CLEARING** back as a
response? What sort of crack were they smoking when
the wrote *that* code?"

For some reason, we decided not define behavior for
impossible situations. I suspect any reasonably implemented
MGC will clean this up in some appropriate fashion
(probably a reset towards the PSTN and a 500 class
message towards the SIP network), raise an O&M alarm,
and possibly take the trunk in question out of service...
but that's completely up to the implementor.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 1 Apr 2002 17:33:42 -0500

> Some SIP nodes will get rid of the ISUP body.

Has anyone around here mentioned that B2BUAs aren't usually a good
idea lately?

> Moreover,
> looks like most switches today will not look at the ISUP body 
> in SIP msg to
> interwork to ISUP.

...but any node that isn't using our draft for ISUP mapping
won't magically start using the tables in our document after
we fix them. They chose their own mapping.

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

Your request isn't unreasonable, although it is of limited benefit
(it only makes sense when you'll be transiting from PSTN through a SIP
network, going through B2BUAs, and terminating in another PSTN network;
even then won't preserve cause codes except in certain isolated cases).

In general, the cause code mapping has been the most controversial
section of the document to date, with most codes provoking multiple,
conflicting suggestions about what mapping makes the most sense. By
doing a wholesale remapping of the codes to meet your criteria, we
will probably open up a whole slew of arguments about which mappings
are most appropriate. If that's something Jon has the bandwidth to
deal with, great -- but I suspect it's a bit too much work for
a very minor improvement.

/a