Subject: AW: [Sip] Reason version 01 - Q.850 Location and diagnostics

From: "Jesske, R" <[email-masked]>
Date: Mon, 24 Jun 2002 11:30:00 +0200

Dear all,
I'm sorry about opening a new issue regarding the Reason draft. 

At the moment the Reason Draft doesn't contain the location and diagnostic field of the Q.763/Q.730 Cause indicators parameters (described within Q.850 1998). The location and diagnostic field is in some cases important for services and procedures within the network.

E.g. Cause Value 34 could be a normal release indicating a congestion in a transit or international network but Cause Value 34 with a diagnostic field including the CCBS possible indication coming from a private network indicates a busy network where the CCBS service is possible.

CCBS is within ISDN networks a frequently used service. For the future interworking of SIP with ISDN networks the indication of location and diagnostics is a extension that enables the CCBS over networks.

The reason draft is OK for only indicating the reason of a release but for service interworking with the PSTN it would be better to have also the location and reason available.

Best regards 

Roland Jesske

Deutsche Telekom AG
T Com Zentrale
Section T38; Signalling, Gateways and Switching Systems 
Roland Jesske, T38a12
Am Kavalleriesand 3, 64295 Darmstadt, Germany
Phone:  +49 6151 83-5940 
Fax:    +49 6151 83-4577 
mailto: [email-masked] <mailto:[email-masked]> 

> -----Ursprüngliche Nachricht-----
> Von: Gonzalo Camarillo [mailto:[email-masked]]
> Gesendet am: Dienstag, 14. Mai 2002 12:19
> An: sip
> Betreff: [Sip] Reason version 01
> 
> Folks,
> 
> I have just released version 01 of the Reason draft. Until it 
> appears in
> the archives, you can fetch it from:
> http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-re
> ason-01.txt
> 
> Only minor modifications has been done since version 00.
> 
> Best 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
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 26 Jun 2002 12:46:12 +0200

Thank you for your answer and possible solutions.

comments below.

Roland

> Von: Adam Roach [mailto:[email-masked]]
> Gesendet am: Montag, 24. Juni 2002 17:44
> An: Jesske, Roland; [email-masked]; [email-masked]
> Cc: Pinker, Gerold; Benz, Robert; Alexeitsev, Denis; Tolksdorf,
> Christian; Pötzl, Joachim; Schütte, Wolfgang; Köhler, Dieter; 
> Hülsemann,
> Martin; Martinez Rebordosa, Anna
> Betreff: RE: [Sip] Reason version 01 - Q.850 Location and diagnostics
> 
> > -----Original Message-----
> > From: Jesske, R [mailto:[email-masked]]
> > 
> > E.g. Cause Value 34 could be a normal release indicating a 
> > congestion in a transit or international network but Cause 
> > Value 34 with a diagnostic field including the CCBS possible 
> > indication coming from a private network indicates a busy 
> > network where the CCBS service is possible.
> > 
> > CCBS is within ISDN networks a frequently used service. For 
> > the future interworking of SIP with ISDN networks the 
> > indication of location and diagnostics is a extension that 
> > enables the CCBS over networks.
> > 
> > The reason draft is OK for only indicating the reason of a 
> > release but for service interworking with the PSTN it would 
> > be better to have also the location and reason available.
> 
> The idea behind including Q.850 in the reason draft is certainly
> not to push ISUP semantics like this into the SIP network. For
> your suggestion to be useful, it would require every device
> on the network to implement detailed ISUP semantics in addition
> to normal SIP semantics.

It is not my Idea to force SIP network elements to understand the whole ISUP. From my understanding the Reason Draft was created to give SIP elements additional information to react on these. What I  didn't realised (because of my Ideas in my head) is that the reason Draft is only for *REQUESTS* (and in 155 responses.
And I saw that the draft is already approved, therefore my comments are not longer valid.

> 
> Further, the level of service interworking you are hinting at
> requires a much better defined mechanism than simply conveying
> the every last bit of the Q.850 cause code. For example, if
> we accepted your suggestion, how would the SIP node go about
> ordering CCBS? Would we expect normal SIP nodes to have the
> ability to generate and tunnel TCAP through M3UA back to the MGC?
> That seems a bit extreme -- and, even if we accepted this as a
> solution, it requires much more rigorous specification than merely
> adding location values to the Q.850 cause codes sent to the SIP
> network (e.g. how do you route the tunneled TCAP?).

You are right that the inclusion of location and the diagnostic field is not the solution of this problem. It was for me only the start. And I thought not of tunnelling the SCCP thought the SIP network. What I thought was to find appropriate SIP Messages and procedures that allows the interworking of TCAP/SCCP Messages to SIP. 

> 
> Am I saying such service interworking is impossible? Of course not.
> I'm just saying that such interworking necessarily *must* allow
> the PSTN network to do things in a PSTN way, and *must* allow the
> SIP network to do things in a SIP way.

agreed ! 
For such kind of scenario there should be a SIP - TCAP/SCCP interworking. I think that will be driven by operators, service provider and vendors that will offer such kind of services.
The problem is that the TC Messages will be send after the call is finished. I don't know (at the moment) how SIP can support such kind of scenario.

> 
> Here's a mile-high sketch of how CCBS interworking would be specified:
> upon receipt of a REL with cause 34 and a diagnostic indicating that
> CCBS is available, the MGC would send a normal 486, with an 
> "Allow-Events"
> header of "dialog" (see draft-rosenberg-sip-call-package-01.txt). The

Ok! This is the proposed mapping of cause 17 and 34 with CCBS possible within the ITU mapping spec (Q.1912.sip).

> UAC, if it supports CCBS, would subscribe to the state of the dialog
> at the gateway. The gateway would take appropriate actions (e.g.
> generation of TCAP messages) based on this subscription. The remainder

Yes! The generation of the TCAP/SCCP CCBS Messages should be done by the interworking function (Gateway). 
If I understand you correct, than it would be possible with this subscription that the SIP user can indicate that he will use the CCBS Service and he get also the indication back if the called user is free. So that the UA can initiate a new call or the GW can initiate a new call to the both parties.  
 
> of the interactions are left as an excercise for the reader, 
> but can be
> deduced from the call-package draft and normal PSTN CCBS procedures.
> (Note that the information returned in the "dialog" event 
> notifications
> might be a very limited subset of what is specified in the 
> call-package
> draft; this will not cause any problems that I am aware of).

Thank you for your answer and for your considerations regarding CCBS

> 
> /a
> 
> P.S. As an aside, the application you describe would be predicated
>      on including Q.850 codes in a *RESPONSE*. The Reason draft is
>      currently specified such that reason headers can appear only
>      in *REQUESTS* (and in 155 responses).
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 24 Jun 2002 17:49:24 -0400

Sorry; I didn't realize the draft was about to be approved. I withdraw
my concerns.

/a

> From: Adam Roach 
> Sent: Monday, June 24, 2002 16:47
> To: 'Cullen Jennings'; Adam Roach; 'Jesske, R';
> [email-masked]; [email-masked]
> Cc: Pinker, Gerold; [email-masked]; Alexeitsev, D; Tolksdorf,
> Christian; Poetzl, Joachim; Schuette, Wolfgang; [email-masked];
> Huelsemann, Martin; Martinez-Rebordosa, Anna
> Subject: RE: [Sip] Reason version 01 - Q.850 Location and diagnostics
> 
> 
> > From: Cullen Jennings [mailto:[email-masked]]
> >
> > > From: [email-masked] [mailto:[email-masked]]On 
> > Behalf Of Adam
> > > Roach
> > >
> > I agree with Adam but just out of curiosity, why is the Q.850 
> > stuff in the
> > SIP network?
> 
> Cullen has a good point -- one that has occured to me before. The
> draft needs some motivating text around this. If there isn't a
> really compelling motivation, it probably needs to be removed.
> 
> /a
>