Subject: [Sipping] RFC 3398: REL cause

From: Sumit Garg <[email-masked]>
Date: Wed, 12 Mar 2003 15:48:13 -0500

Hi all,

According to the rfc 3398(SIP-ISUP mapping, section 7.1.3 and 7.2.2),for a
net to Phone call, when ACM timeout timer
 (T7- 20 - 30 s) expires, the ISUP leg  REL cause should be 102 (protocol
error, recovery on timer expiry) and corresponding SIP response should be
504 Server Timeout.
However, if one goes by Q.764 and table 1 of Q.850 the correct REL cause for
ISUP would be 31(normal unspecified)
and for the SIP leg it would then correspond to  480 (Temporarily
Unavailable). Apparently 102 is used mostly for
SUS-RES.

What should be the values used?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
Sumit Garg 
Aastra Telecom US
8 Federal Street 
Billerica, MA 01821 
978-436-4244
email: <<mailto:[email-masked]>> 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: "Jesske, R" <[email-masked]>
Date: Thu, 13 Mar 2003 13:50:44 +0100

Hi,
both is not correct. (From my point of view)

Because T7 will be started when the latest address message is sent. (See Q.764)

Expiry of T7 is caused due to the fact that no ACM is received (from the destination) because in the destination (normal case) address information is missing.

In Q.699 Table 23(DSS1-ISUP mapping) this case interworking unit is described as following:
Determination that the called number information received is incomplete, after an IAM message has already been sent 
--> therefore REL with Cause 28 is send in forward and Backward direction.

And Q.850 says:

Cause No. 28 - Invalid number format (address incomplete)
This cause indicates that the called party cannot be reached because the called party number is not in a valid format or is not complete.
NOTE - This condition may be determined:
-	immediately after reception of an end of pulsing (ST) signal; or
-	on time-out after the last received digit.

If this scenario should also apply also for the SIP-ISUP interworking Q.699 could be taken as reference, because Q.764 doesn't point to this fact in the interworking case:
Therefore on the ISUP leg Cause 28 shall be sent and on the SIP leg 484 should be sent, as it is stated in the cause code mapping.

For completeness: In normal cases ISUP Timer T35 will normally expire before T7 will, therefore normally a REL with Cause 28 will be received from the destination. 

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Sumit Garg [mailto:[email-masked]]
> Gesendet: Mittwoch, 12. März 2003 21:48
> An: [email-masked]'
> Betreff: [Sipping] RFC 3398: REL cause
> 
> 
> Hi all,
> 
_______________________________________________
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: Sumit Garg <[email-masked]>
Date: Thu, 13 Mar 2003 08:32:48 -0500

Hi,
I don't quite agree with that.
I believe that if the Address Information was found to be incomplete at the
Destn exchng
then the Originating exchange would have recd. a REL with Cause 28 (Due to
T35 expiry on the Destn).

Any intermediate/Destn exchng would be generating REL with cause 28 only if
they don't
 have information to route the msg.

A timeout would occur on Intermediate/Originating exchng only in abnormal
cases like
 hardware failure etc; in this case the address info supplied would have
been correct for that exchng (otherwise T35
should have expired and not T7 and we would have got REL cause 28); 

Thus, I believe REL cause 28 on T7 expiry would again be wrong.

My only issue with 102 is that, this is not the RELEASE cause generated in
the scenario in a pure ISUP
network. If we consider a large network with multiple intermediate SS7
exchanges between the destn
and the SS7-SIP gateway; ACM timeout on any one of them would be conveyed to
the gateway as 31 and hence
translate to 480. 
 Thus, I fail to understand why the gateway should behave any differently
and convey different release
causes to the SS7 and SIP world. It would be more logical if it just sent 31
and 480.

-Sumit

-----Original Message-----
From: Jesske, R [mailto:[email-masked]]
Sent: Thursday, March 13, 2003 7:51 AM
To: [email-masked]; [email-masked]
Subject: AW: [Sipping] RFC 3398: REL cause

Hi,

Because T7 will be started when the latest address message is sent. (See
Q.764)

Expiry of T7 is caused due to the fact that no ACM is received (from the
destination) because in the destination (normal case) address information is
missing.

In Q.699 Table 23(DSS1-ISUP mapping) this case interworking unit is
described as following:
Determination that the called number information received is incomplete,
after an IAM message has already been sent 
--> therefore REL with Cause 28 is send in forward and Backward direction.

And Q.850 says:

Cause No. 28 - Invalid number format (address incomplete)
This cause indicates that the called party cannot be reached because the
called party number is not in a valid format or is not complete.
NOTE - This condition may be determined:
-	immediately after reception of an end of pulsing (ST) signal; or
-	on time-out after the last received digit.

If this scenario should also apply also for the SIP-ISUP interworking Q.699
could be taken as reference, because Q.764 doesn't point to this fact in the
interworking case:
Therefore on the ISUP leg Cause 28 shall be sent and on the SIP leg 484
should be sent, as it is stated in the cause code mapping.

For completeness: In normal cases ISUP Timer T35 will normally expire before
T7 will, therefore normally a REL with Cause 28 will be received from the
destination. 

Best Regards

Roland

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 13 Mar 2003 15:45:04 -0000

I had some problem trying to identify the problem that is trying to be solved here, and that is because it is out of scope.

The text in section 7.2.2 of RFC 3398, that states

"A REL message with cause value 102 (protocol error,
   recovery on timer expiry) SHOULD be sent to the PSTN. "

is a purely ISUP / BICC protocol procedure and nothing to do with any interworking. Interworking documents should not attempt to rewrite the protocols on either side of the interworking point. Therefore this sentence SHOULD be deleted from any future version of RFC 3398. Can the authors please note this in the appropriate bug list.

Looking at the BICC specification, I cannot actually see a point where it specifies a cause value to be included in the ISUP REL message, and therefore presumably it is up to the implementor to choose an appropriate one. 

I would believe that #28 would be inappropriate, but that belief is irrelevant to this list, as this is an ISUP response to an ISUP timer expiry.

For 7.1.3, I guess these are more informative, although I would have preferred a different terminology to "MG Releases PSTN Trunk" which implies to me that the trunk is released as part of interworking, when it is a purely ISUP / BICC protocol action that is causing this.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> From: Sumit Garg [mailto:[email-masked]]
> Sent: 13 March 2003 13:33
> To: [email-masked]
> Subject: RE: [Sipping] RFC 3398: REL cause
> 
> 
> Hi,

---

From: Sumit Garg <[email-masked]>
Date: Thu, 13 Mar 2003 10:44:52 -0500

I totally agree with you on that. RFC 3398 should try to change ISUP
protocol.
Q.764 does not mention any specific Release cause but the one indicated by
Q.850 (Table 1)
seems to be 31.

thus, caused the confusion.
All will be well if it were removed from the next version.

-Sumit

-----Original Message-----
From: Drage, Keith (Keith) [mailto:[email-masked]]
Sent: Thursday, March 13, 2003 10:45 AM
To: 'Sumit Garg'; [email-masked]
Subject: RE: [Sipping] RFC 3398: REL cause

I had some problem trying to identify the problem that is trying to be
solved here, and that is because it is out of scope.

is a purely ISUP / BICC protocol procedure and nothing to do with any
interworking. Interworking documents should not attempt to rewrite the
protocols on either side of the interworking point. Therefore this sentence
SHOULD be deleted from any future version of RFC 3398. Can the authors
please note this in the appropriate bug list.

Looking at the BICC specification, I cannot actually see a point where it
specifies a cause value to be included in the ISUP REL message, and
therefore presumably it is up to the implementor to choose an appropriate
one. 

I would believe that #28 would be inappropriate, but that belief is
irrelevant to this list, as this is an ISUP response to an ISUP timer
expiry.

For 7.1.3, I guess these are more informative, although I would have
preferred a different terminology to "MG Releases PSTN Trunk" which implies
to me that the trunk is released as part of interworking, when it is a
purely ISUP / BICC protocol action that is causing this.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Mar 2003 12:43:01 -0500

Some notes below.

Jon Peterson
NeuStar, Inc.

> Sent: Thursday, March 13, 2003 7:45 AM
> I had some problem trying to identify the problem that is 
> trying to be solved here, and that is because it is out of scope.
> 
> is a purely ISUP / BICC protocol procedure and nothing to do 
> with any interworking. Interworking documents should not 
> attempt to rewrite the protocols on either side of the 
> interworking point. Therefore this sentence SHOULD be deleted 
> from any future version of RFC 3398. Can the authors please 
> note this in the appropriate bug list.
> 

You are quite correct on this matter, Mr. Drage.

> Looking at the BICC specification, I cannot actually see a 
> point where it specifies a cause value to be included in the 
> ISUP REL message, and therefore presumably it is up to the 
> implementor to choose an appropriate one. 
> 
> I would believe that #28 would be inappropriate, but that 
> belief is irrelevant to this list, as this is an ISUP 
> response to an ISUP timer expiry.
> 

Agreed both that #28 is bad and that this is largely irrelevant to SIP-ISUP
interworking. Well, if literally nothing is specified for this case in the
relevant ITU-T specs, then it couldn't hurt for us to make a suggestion, but
making a normative one is inappropriate.

> For 7.1.3, I guess these are more informative, although I 
> would have preferred a different terminology to "MG Releases 
> PSTN Trunk" which implies to me that the trunk is released as 
> part of interworking, when it is a purely ISUP / BICC 
> protocol action that is causing this.
> 

7.1.3 is useful in so far as it's nice to know that 504 is sent in the
backwards direction in this instance, and so on.

One more note below.

> > It would be more logical if it just sent 31
> > and 480.
> > 
> > -Sumit
> > 
> > 

I'm not sure #31 is so great for this either. But leaving that aside, 480
represents a radically different condition in SIP networks (which is very
close to cause #19). It would not be appropriate to send a 480 response
here.
_______________________________________________
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: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 13 Mar 2003 18:04:23 -0000

See below with some additional fairly minor comments.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> From: Peterson, Jon [mailto:[email-masked]]
> Sent: 13 March 2003 17:43
> To: 'Drage, Keith (Keith)'; 'Sumit Garg'; [email-masked]

<snipped>

> making a normative one is inappropriate.
I would disagree with making even a suggestion in the IETF document. My understanding of ISUP / BICC and DSS1 is that if the cause code is not specified for the specific release instance, then an appropriate cause should be chosen by the implementor. Making even a suggestion in an IETF document may imply to some implementors that they should absolutely follow this.

If it is considered that a specification or suggestion is needed (and I dont really think it is), then the appropriate contribution should be made to ITU-T SG11 to change Q.1701.4 (I am unsure whether Q.764 is currently being maintained).

And certainly just deleting the sentence is the easiest fix to agree.

> backwards direction in this instance, and so on.
Yes, I guess I would not delete it, but in the future we may want to consider making it slightly more general, something along the lines of "ISUP protocol error in MGC, e.g. T7 expiry". I assume 504 would apply in all these sort of cases.

<rest snipped>

---

From: Sumit Garg <[email-masked]>
Date: Thu, 13 Mar 2003 13:33:33 -0500

Some notes at the end:

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Thursday, March 13, 2003 12:43 PM
To: 'Drage, Keith (Keith)'; 'Sumit Garg'; [email-masked]
Subject: RE: [Sipping] RFC 3398: REL cause

Some notes below.

Jon Peterson
NeuStar, Inc.

>close to cause #19). It would not be appropriate to send a 480 response
-------------

I am pasting the section of table 1 from Q.850 which defines the Causes to
be used.
Cause
Value    No        Definition                  Diagnostics  Application

 1111    31         Normal, unspecified                        DSS1,ISUP

References       Location           Remarks
Q.931		     RLN                Call  information failure

2.1.1/Q.764      TN, INTL, RLN      indicating the failure
2.1.2/Q.764                          of a call due to the
 2.8.1/Q.764                         lapse of a timeout  
2.8.2/Q.764                          or a fault not covered
 2.9.3/Q.764                         by specific causes
2.9.6/Q.764                          (examples: expiry of timers
2.9.8.2/Q.764                        Q.764 not covered by
2.9.8.3/Q.764                        specific causes, release of
2.1.8/Q.764                          interconnected circuit, etc.)
 2.2.4/Q.764

Thus for the ISUP side the most likely cause would be 31.
So I mapped this 31 as per RFC3398 to get 480 as the SIP release cause;
 which per se is not all that bad...
It would just cause the request to be made again (I hope) after some
time..and then
we would hopefully not have an ACM timeout. 
504 for sure is better; but consider a case where the ACM timeout occurs
on a switch between the SS7-SIP gateway and the destination. The Gateway
would still
recv 31 and map it to 480 evoking the behaviour which is closer to Release
Cause 19 ;-)

So would it really matter if the gateway itself sent the release cause of
480 instead
of 504 on timeout??

I totally agree that the RFC should not make any suggestion towards the
causes to be
be used on the protocols being interworked. That should be done only in
their respective
specs/RFCs.

--Sumit

---

From: "Jesske, R" <[email-masked]>
Date: Fri, 14 Mar 2003 07:28:21 +0100

HI,
I can agree that this is not stated within Q.764, Q.1902 and in the Q.1912.SIP draft (the ITU SIP-ISUP/BICC interworking). Also I can agree that this is not an IETF matter how to release a call on ISUP side.

The only hint with regard to this issue is the Q.699 as I stated earlier. 

In Q.699 Table 23(DSS1-ISUP mapping) the interworking is described as following:
Determination that the called number information received is incomplete, after an IAM message has already been sent 
--> therefore REL with Cause 28 is send in forward and Backward direction.

        DSS1                       IWU                      PSTN
        1|---------SETUP----------->|                          |
         |                          |                          |
         |                          |------------IAM---------->|2
         |                          |<=========Audio===========|
         |                          |    *** T7 Expires ***    |
         |                          |                          |
        4|<----------REL------------|------------REL---------->|3
         |         Cause 28         |          Cause 28        |

The only indication where I know that this fackt will be indicated to the Interworking unit is the expiry of T7.

The other cause as proposed by Sumit (31) is more common and could be also valid.

Due to the fact that this is a ITU issue, this will be discussed at the next ITU Meeting in Paris (April). 

Best Regards 

Roland

> Gesendet: Donnerstag, 13. März 2003 19:34
> An: 'Peterson, Jon'; 'Drage, Keith (Keith)'; Sumit Garg;
> [email-masked]
> Betreff: RE: [Sipping] RFC 3398: REL cause
> 
> 
> Some notes at the end:
> 
> >relevant ITU-T specs, then it couldn't hurt for us to make a 
> suggestion,
> but