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

From: Adam Roach <[email-masked]>
Date: Mon, 24 Jun 2002 11:43:46 -0400

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

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

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.

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

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

_______________________________________________
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: "Cullen Jennings" <[email-masked]>
Date: Mon, 24 Jun 2002 14:13:25 -0700

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