Subject: Re: [Sipping] Progress on draft-jesske-sipping-etsi-ngn-reason-03

From: "Jesske, R" <[email-masked]>
Date: Tue, 1 Jul 2008 14:12:05 +0200

I'll try to reword the requirements:

REQ-1:
It should be possible to support PSTN-SIP-PSTN scenarios where the reason of a call release can be transferred though the SIP domain without any loss of information and no change of reason. 
REQ-2: 
It should be possible to provide correct announcements to a SIP user based on the reason for call clearing within the PSTN network or the PSTN user.

Is that better?

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von 
> [email-masked]
> Gesendet: Dienstag, 1. Juli 2008 03:37
> An: [email-masked]
> Betreff: Re: [Sipping] Progress on 
> draft-jesske-sipping-etsi-ngn-reason-03
> 
> 
>    From: "Jesske, R" <[email-masked]>
> 
>    REQ-GEN-1:  
> 
>       All simulation services must provide interoperability with the 
>       PSTN/ISDN. By interoperability we mean that, in the case that a 
>       simulation or supplementary service is provided to one 
> of the users 
>       when one of the endpoints is located in the PSTN and 
> the other is 
>       located in the NGN IMS network, the user should receive 
> the service 
>       without any degradation as if the service were provided 
> in the native
>       network. 
>    
> I'll warn you that this requirement statement is (from a SIP point of
> view) extremely vague, and you're not likely to get any traction from
> it.
> 
>    So the Reason header within responses will help to fulfil 
> this there are
>    certain cause values that are very specific for services. Like the
>    example within the draft pointing to the Closed User Group service.
>    
> It seems to me that what you are seeking is not the ability to carry a
> certain list of ISUP cause values (e.g., the ones listed in the I-D),
> but rather a means for carrying the ISUP cause value itself, a way to
> tunnel the ISUP cause value.in SIP, for SS7-SIP-SS7 double-gatewaying.
> 
> And if that's what you want, you should state it as a requirement.
> 
> Dale
> _______________________________________________
> Sipping mailing list  https://www.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://www.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: Jeroen van Bemmel <[email-masked]>
Date: Tue, 01 Jul 2008 19:17:34 +0200

Roland,

REQ-2 can be satisfied by answering the call in the PSTN and playing the 
correct announcement there. Perhaps there are additional requirements 
that would prohibit such a solution?

Regards,
Jeroen

---

From: [email-masked]
Date: Tue, 1 Jul 2008 14:08:03 -0400

REQ-1:
   It should be possible to support PSTN-SIP-PSTN scenarios where the
   reason of a call release can be transferred though the SIP domain
   without any loss of information and no change of reason. 

   REQ-2: 
   It should be possible to provide correct announcements to a SIP
   user based on the reason for call clearing within the PSTN network
   or the PSTN user.

   Is that better?

Yes, that is much clearer!

I assume that the ISUP reasons are two-digit codes, and there is no
intrinsic restriction on what two-digit combinations they can be.
That is, for REQ-1, codes 00 through 99 must be supported, even if
they have no assigned meaning now.

Dale

---

From: "Michael Procter" <[email-masked]>
Date: Tue, 1 Jul 2008 20:18:22 +0100

> they have no assigned meaning now.

Not quite.  Q.850 cause values are 7 bits long, and (last time I looked)
approximately half of the 128 values have assigned meanings

One thing that doesn't seem to be mentioned in the draft, but seems
useful if you are trying to achieve REQ-1 is the 'Location' field.  This
is a 4-bit field defining where in the network the specific cause was
generated.  Whilst not something that has an obvious mapping to SIP, it
is presumably useful in the ISUP-SIP-ISUP scenario.

My ISUP knowledge is a good few years out of date now, so someone might
be able to provide corrections to the above.  In particular, I'd be
interested in knowing how widely used the location field really is.

Michael

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 2 Jul 2008 09:50:08 +0200

Hi Michael,
The location is used by some operators for O&M issues. Also for the Crank Back feature.
But with regard to the intworking for SIP we identified that the location gives no additional benefit. Perhaps you realised that the Version -02 had the location included.

To complete Q.850: There is also a Diagnostics Field included which gives more information why the call was released or a indication what to do. Like CCBS (Call Completion Busy Subscriber) is possible. 

Best Regards

Roland

> [mailto:[email-masked]] Im Auftrag von Michael Procter
> Gesendet: Dienstag, 1. Juli 2008 21:18
> An: [email-masked]; [email-masked]

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 2 Jul 2008 10:09:20 +0200

Jeroen,
Thank you for the Question. Within the PSTN the Release Cause will be sent back to the Originating Local Exchange where the Announcement is played to the originating user. And the complete path to the terminating user is released. 
So the announcement will not played by the PSTN. That is why ISUP uses Release Causes.

REQ-2: 
It should be possible to provide correct announcements to a 
SIP user based on the reason for call clearing within the 
PSTN network or the PSTN user. The PSTN does normally not provide announcements to originating user when clearing the call.

Best Regards

Roland

> Von: Jeroen van Bemmel [mailto:[email-masked]] 
> Gesendet: Dienstag, 1. Juli 2008 19:18
> An: Jesske, Roland
> Cc: [email-masked]; [email-masked]
> > It should be possible to support PSTN-SIP-PSTN scenarios 
> where the reason of a call release can be transferred though 
> the SIP domain without any loss of information and no change 
> of reason. 
> > REQ-2: 
> > It should be possible to provide correct announcements to a 
> SIP user based on the reason for call clearing within the 
> PSTN network or the PSTN user.
> >
> > Is that better?
> >
> > Best Regards
> >
> > Roland
> >
> >

---

From: "Michael Procter" <[email-masked]>
Date: Wed, 2 Jul 2008 10:02:16 +0100 (BST)

Hi Roland,

I have not reviewed previous versions of the draft, for which I apologise.
 Thank you for clarifying how the Location is used - as I noted, my
knowledge of ISUP/Q.850 is a good few years out of date!

I think that the approach of tunneling the Q.850 cause through SIP using
the reason header is probably the best way to achieve interoperability
with features such as CUG (as you use in your example), but I wonder if
there is scope for some additional SIP response codes to handle specific
cases that have a wider application.

For example, your draft mentions that cause 18 maps to response 408, which
maps back to cause 102.  Clearly this is unhelpful, and could be solved
with a new SIP response code.  Something like '4xx No Answer' would more
accurately match cause 18 (and 19?), and would be (IMO) a useful addition
to SIP.

Alternatively, for the specific case of cause 18, a mapping to 487 might
be reasonable, based on RFC3261 Section 13.3.1 step 1.  That seems to
match conceptually, but then you have an issue with the reverse mapping
(undefined in RFC3398?).

Keith Drage made the following comment further back in the thread:
> However part of this discussion should also look at whether we need more
> SIP response codes as a solution to the other half of the problem.
[...]
> For example, under what circumstances does a initiating SIP terminal
> that happens to be communicating with a PSTN gateway need to distinguish
> the following values (given in the draft):
[mapping table removed]
> If we start understanding that we might be opening up an appropriate
> discussion.

I think that this was a very good point - an understanding of the features
that are inhibited by the current cause mappings would help us to
understand which ones should be natively supported by SIP.

Best regards,

Michael

On Wed, July 2, 2008 8:50 am, Jesske, R wrote:
> But with regard to the intworking for SIP we identified that the location
> gives no additional benefit. Perhaps you realised that the Version -02 had
> the location included.
>
> To complete Q.850: There is also a Diagnostics Field included which gives
> more information why the call was released or a indication what to do.
> Like CCBS (Call Completion Busy Subscriber) is possible.
>
> Best Regards
>
> Roland
>
>
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 4 Jul 2008 14:56:34 +0200

For REQ-1:

I think we need to capture in this requirement (or in association with
this requirement) somehow:

1)	that this is between two "PSTN gateways".

2)	that scenarios exist between PSTN gateways where SIP-I is not a
solution (and you may need to describe one of these in a use cases part
of the document).

For REQ-2: 

Is this the only use for the requirement. There are two ways of building
this requirement:

-	the gateway passes on the cause and some announcement server
translates the cause into the appropriate announcement.
-	the gateway translates the cause into an identifier of a
particular announcement, and passes that information to the announcement
server.

Both fulfil this requirement. Is there some other requirement that
causes these to be distinguished.

I would also note that neither of these requirements justify the
following "display" UA procedure in the document:

   A UA that supports the Reason header field can process the Q.850 
   Cause Value and display it or an equivalent text. The inclusion of a 
   Reason header field by UA is only for 2B2 UA interworking with the 
   PSTN/ISDN or providing services foreseen.

Are we missing a requirement or is the procedure text subject to
revision.

Regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, July 01, 2008 7:08 PM
> To: [email-masked]
> Subject: Re: [Sipping] Progress on 
> I assume that the ISUP reasons are two-digit codes, and there 
> is no intrinsic restriction on what two-digit combinations 
> they can be.
> That is, for REQ-1, codes 00 through 99 must be supported, 
> even if they have no assigned meaning now.
> 
> Dale
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Jesske, R" <[email-masked]>
Date: Tue, 8 Jul 2008 10:38:33 +0200

Hi Keith,
for part one of your mail I propose the following text that describes the Requirement a little more and points to the used case described within the draft. So I extended the Requirements section with some more words.

REQ-1:

REQ-1 shows the scenario between two ISUP Gateways where SIP-I is not a solution to be used. A IMS network defined by 3GPP where SIP-I is not part of the framework is such an example. A used case is shown in Figure 2.

REQ-2: 
It should be possible to provide correct announcements to a SIP user based on the reason for call clearing within the PSTN network or the PSTN user. The PSTN does normally not provide announcements to originating user when clearing the call.

REQ-2 identifies the scenario the gateway passes on the cause and some announcement server translates the cause into the appropriate announcement.

With regard to your last question I have created a requirement but also the text could be discussed further. I've got the comment that in some restricted cases such a possibility of displaying also a Cause value could be valuable. Here is the requirement with some descriptive text:

REQ-3:
A UA may have the ability to display ISUP specific release causes or show a equivalent text. A inclusion of Q.850 causes is out of scope.

REQ-3 excludes that a SIP UA includes Q.850 cause values because that is not needed due to the different context of a SIP UA and of course the existing SIP response codes. Also the possibility of displaying Q.850 causes should be used very restrictive and is not recommended. A used case could be a used case could be a Integrated Access Device where a POTS Phone is connected to. It is recommended to ignore the cause value if received be a UA.

Best Regards

Roland

> [mailto:[email-masked]] Im Auftrag von DRAGE, Keith (Keith)
> Gesendet: Freitag, 4. Juli 2008 14:57
> An: [email-masked]
> where the