Subject: [SIP] Question concerning SIP/ISUP interworking

From: Anna Simpson <[email-masked]>
Date: Mon, 18 Sep 2000 10:49:19 +0100

Hi, I have been studying SIP / ISUP interworking draft documents and I have a quesiton concerning
the SIP response / cause mappings.

Working from "Best Current Practice for ISUP to SIP mapping", March 2000
http://www.softarmor.com/sipwg/drafts/draft-camarillo-sip-isup-bcp-00.txt
section 6.2.4 on page 21 shows
Release 31, normal unspecified is mapped to the SIP response 404, Not found.

Could anyone explain why this mapping was chosen?

Thanks
Anna

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 18 Sep 2000 15:36:02 +0300

Hi,

In order to understand this cause value is better to use negative
statements:

Cause 31 belongs to the normal class. So, it does not belong to the
following classes:
resource unavailable class, service or option unavailable class,
protocol error class and interworking class.

This gives a rough idea about the semantics of this cause value. Or to
be more precise, it gives an idea about which are not the samentics of
this cause value.

Inside the normal class, there are specific cause values that are used
for specific situations:

1 – Unallocated (unassigned) number
2 – No route to specified transit network (national use)
3 – No route to destination
4 – Send special information tone
5 – Misdialled trunk prefix (national use)
6 – Channel unacceptable
7 – Call awarded and being delivered in an established channel
8 – Preemption
9 – Preemption – circuit reserved for reuse
16 – Normal call clearing
17 – User busy
18 – No user responding
19 – No answer from user (user alerted)
20 – Subscriber absent
21 – Call rejected
22 – Number changed
23 – Redirection to new destination
25 – Exchange – routing error
26 – Non-selected user clearing
27 – Destination out of order
28 – Invalid number format (address incomplete)
29 – Facility rejected
30 – Response to STATUS ENQUIRY

Then, cause value 31 is defined as:

31 – Normal, unspecified

Therefore, cause value 31 is applicable when there is a normal release
whose cause does not fall into the previous mentioned categories. It is
a general purpose cause value.

One might think inmediately that 400 Bad Request would be appropiate,
but if this status code is used the UA that sent the INVITE might think
that the systax of the INVITE was not correct.

Actually you are right, and 404 does not suit this fine either.

The best option might be 480 Temporarily Unavailable. This way the UA
would try again after some time...

Any ideas against or in favour of this change?

We have been pretty busy lately but we intend to relase a more or less
definitive version of this draft soon.

Regards,

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: Gonzalo Camarillo <[email-masked]>
Date: Mon, 18 Sep 2000 17:22:18 +0300

Hi,

If during an ongoing call a REL is received it will be mapped to a BYE
request. The situation we are dealing with is when a REL comes back
after sending a IAM.

 INVITE  |
-------->|  IAM
         |------->
         |  REL
Response |<------
<--------|
   ACK   |
-------->|

In this scenario a response has to be sent (rather than a BYE). That's
why the mapping cause value/status code is needed.

Best regards,

Gonzalo

Anna Simpson wrote:
> 
> Gonzalo,
> 
> I am assuming that rel 16, normal call clearing would map to a BYE request.
> 
> Is there any reason why a rel 31 could not be treated the same?
> 
> I shall dig around and try and find some more information on when to use a REL 31
> to see if this helps.
> 
> thanks for replying so quickly
> Anna
> 
> Gonzalo Camarillo wrote:
> 
> > Hi,
> >

---

From: Anna Simpson <[email-masked]>
Date: Mon, 18 Sep 2000 15:13:23 +0100

Gonzalo,

---

From: "Adam B. Roach" <[email-masked]>
Date: Mon, 18 Sep 2000 14:04:31 -0500 (CDT)

I think you have to look at the context.

In the case that I've sent an IAM to the ISUP network, a REL before a
CON or ACM indicates an error of some sort. The concept of "normal
call clearing" in an error situation doesn't make sense, and a switch
really isn't expected to behave this way.

In the case that the call hase already been set up, *all* REL messages
are mapped to a BYE (I beleive this is covered in the draft), regardless
of the release code. If the call *hasn't* been setup, you shouldn't
send a BYE: I'm not sure how many implementations would react gracefully 
if they sent an INVITE, and received a BYE without any intervening 
INVITE response. Many will probably be okay, but this really isn't well 
defined behaviour.

You're correct in your assertion that an unxpected release code
during call setup should map to some error code which usually contains a
"Retry-After" header; this will be taken into consideration for the next 
draft. Thanks for the feedback.

/a

>I am assuming that rel 16, normal call clearing would map to a BYE reques=
>t.
>
>I shall dig around and try and find some more information on when to use =
>a REL 31
>to see if this helps.
>
>> 1 =96 Unallocated (unassigned) number
>> 2 =96 No route to specified transit network (national use)
>> 3 =96 No route to destination
>> 4 =96 Send special information tone
>> 5 =96 Misdialled trunk prefix (national use)
>> 6 =96 Channel unacceptable
>> 7 =96 Call awarded and being delivered in an established channel
>> 8 =96 Preemption
>> 9 =96 Preemption =96 circuit reserved for reuse
>> 16 =96 Normal call clearing
>> 17 =96 User busy
>> 18 =96 No user responding
>> 19 =96 No answer from user (user alerted)
>> 20 =96 Subscriber absent
>> 21 =96 Call rejected
>> 22 =96 Number changed
>> 23 =96 Redirection to new destination
>> 25 =96 Exchange =96 routing error
>> 26 =96 Non-selected user clearing
>> 27 =96 Destination out of order
>> 28 =96 Invalid number format (address incomplete)
>> 29 =96 Facility rejected
>> 30 =96 Response to STATUS ENQUIRY
>>
>> 31 =96 Normal, unspecified
>>
>> whose cause does not fall into the previous mentioned categories. It is=
>
>> but if this status code is used the UA that sent the INVITE might think=
>
>> > Hi, I have been studying SIP / ISUP interworking draft documents and =
>I have a quesiton concerning
>> > Working from "Best Current Practice for ISUP to SIP mapping", March 2=
>000
>> > http://www.softarmor.com/sipwg/drafts/draft-camarillo-sip-isup-bcp-00=
>=2Etxt
>> > Release 31, normal unspecified is mapped to the SIP response 404, Not=
> found.
>> >

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 19 Sep 2000 08:32:15 +0300

Hi,

A small review of this thread:

In the draft, for ISUP to SIP calls we send a CANCEL if no 200 response
for the INVITE has been received. I believe that this is the best
behavior, as Adam pointed already out. It is OK if a UA decides to send
a BYE instead, but we do not need to cover this case in the draft (for
ISUP to SIP calls).

Anna was asking about SIP to ISUP calls. In this situation, the gateway
will send responses to the INVITE, so CANCEL is not applicable here.

>really isn't expected to behave this way.

This is correct in the fixed network. However, when there is
interworking with GSM for instance, the user has a chance of sending a
REL before the ACM if he does not want to take the call.

Anyway, as you said, this is already covered in the draft.

Regards,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 19 Sep 2000 16:26:59 +0300

Hi,

Anna Simpson wrote:
> 
> All,
> 
> This is my understanding from your emails and the spec.
> 
> If a call is established, e.g. a 200 [OK] has been received in
> response to
> the INVITE then a BYE message will be sent.

Yes.

> For a SIP to ISUP call the 200 [OK] is sent on receiving the CON or
> ANM
> over ISUP.

Yes.

> For an ISUP to SIP call the 200 [OK] is received when the SIP node
> answers
> the call and will be mapped to an ANM or CON, as appropriate.

Yes.

> 
> For the calling or called party to now release a BYE would map to a
> REL(16)
> and vice versa.

Yes.

> 
> Adam stated once a call is set up all REL messages are mapped to a
> BYE.
> If this is so then the BYE will need to contain information to
> distinguish between
> different REL messages otherwise information can be lost. (however
> this is a seperate
> issue).

Actually you don't usually need this information in the SIP network, but
if you still want to have it available you can embed the REL in the body
of the BYE, for instance.

> If the call is still being setup then either a response is seen or a
> CANCEL.
> (A BYE could be used but is not the preferred option).
> e.g.
> SIP to ISUP
> calling tears down before called answers then a CANCEL is sent and
> mapped to
> a REL 16.ref 6.1.9. in the spec.

Yes.

> 
> If the call ends for another reason then a SIP response is sent.

I do not think I follow you. A SIP response is sent from the server. A
CANCEL is sent by the client.

> 
> If I have the above correct then I am back to the original question of
> why
> map a REL 31 to a 404 response.
> I have been searching through the ITU specs to try and find examples
> of
> when a rel 31 is used, rather than just saying when another normal
> cause value
> is inappropriate.
> I found this example in Q.764, 2.2.4
> If a call set-up fails and an in-band tone or announcement has to be
> returned to the
> calling party from an exchange or called party, the exchange or user
> concerned
> connects the in-band tone or announcement to the transmission path. If
> a time-out
> occurs at the exchange providing the in-band tone or announcement, the
> exchange
> sends a release message to the preceding exchange with cause value 31
> (normal
> unspecified).
> To me this does not look like a 404 NOT FOUND.
>

As I said in a previous mail, I find 480 more appropiate. We'll change
it.

> However I am clueless as to which response would be more appropriate
> if we
> cannot use a CANCEL or BYE.

You cannot use them because you are a server, not a client, and you have
to terminate the transaction that was initiated by the INVITE received.

Anyway, I believe that the call flows and the state machines in the
draft describe this pretty clearly.

Best regards,

Gonzalo

> During the definition of SIP was it ever considered that there should
> be catch
> all responses, that would say mimic this ISUP catch all cause values?
> Or is this something that is not needed by SIP.
> 
> Thanks for your thoughts so far, this discussion has been very
> beneficial to
> my understanding of SIP.
> 
> Anna

---

From: Anna Simpson <[email-masked]>
Date: Tue, 19 Sep 2000 14:42:39 +0100

Gonzalo,

Thanks, I think I am finally getting there.

I shall go back and look at the Server vs Client releases.

Thanks again
Anna

---

From: Anna Simpson <[email-masked]>
Date: Tue, 19 Sep 2000 14:00:56 +0100

All,

If a call is established, e.g. a 200 [OK] has been received in response to
the INVITE then a BYE message will be sent.
For a SIP to ISUP call the 200 [OK] is sent on receiving the CON or ANM
over ISUP.
For an ISUP to SIP call the 200 [OK] is received when the SIP node answers
the call and will be mapped to an ANM or CON, as appropriate.

For the calling or called party to now release a BYE would map to a REL(16)
and vice versa.

Adam stated once a call is set up all REL messages are mapped to a BYE.
If this is so then the BYE will need to contain information to distinguish between
different REL messages otherwise information can be lost. (however this is a seperate
issue).

If the call is still being setup then either a response is seen or a CANCEL.
(A BYE could be used but is not the preferred option).
e.g.
SIP to ISUP
calling tears down before called answers then a CANCEL is sent and mapped to
a REL 16.ref 6.1.9. in the spec.

If I have the above correct then I am back to the original question of why
map a REL 31 to a 404 response.
I have been searching through the ITU specs to try and find examples of
when a rel 31 is used, rather than just saying when another normal cause value
is inappropriate.
I found this example in Q.764, 2.2.4
If a call set-up fails and an in-band tone or announcement has to be returned to the
calling party from an exchange or called party, the exchange or user concerned
connects the in-band tone or announcement to the transmission path. If a time-out
occurs at the exchange providing the in-band tone or announcement, the exchange
sends a release message to the preceding exchange with cause value 31 (normal
unspecified).
To me this does not look like a 404 NOT FOUND.

However I am clueless as to which response would be more appropriate if we
cannot use a CANCEL or BYE.
During the definition of SIP was it ever considered that there should be catch
all responses, that would say mimic this ISUP catch all cause values?
Or is this something that is not needed by SIP.

Thanks for your thoughts so far, this discussion has been very beneficial to
my understanding of SIP.

Anna