Subject: [Sipping] new event package for CCBS, CCNR, MWI

From: "Poetzl, Joachim" <[email-masked]>
Date: Thu, 25 Jul 2002 16:55:01 +0200

Hi,

we have checked draft-ietf-sipping dialog-package.txt and other relevant drafts for applicabilty to serve for interworking scenarios (PSTN/SIP) for services which uses call unrelated signalling (e.g. Call Completion to busy Subscriber (CCBS, ITU-T Q.733.3),Call Completion on No Reply (CCNR, ITU-T Q.733.5),Message Waiting Indication (MWI, ITU-T))

The described functionalities are not sufficient for a proper interworking, because the knowledge of dialog states is only applicable in the SIP domain. A real interworking between both worlds needs more functionality than just a mapping of parameters and defining dilog states in the SIP domain.

The interworking of information elements and messages has to take place in a unit (e.g. Media Gateway Controller) which is capable to set up SCCP messages containing the appropriate SCCP-messages. Furthermor it needs an instance of the TCAP CCBS ASE and has to obbey the rules for SCCP routing. In the backwards direction it is desireable to map all the ISUP parameters contained in the CCBS-recall into the SIP-domain (e.g. CCBS recall indication).

We propose to put the necessary functionalities, events, mapping of elments in a new event package for the SIP events architecture (draft-sipping-call-unrelated-PSTN2SIP-package-00.txt) accompanied by another draft which describes the requirements for the mapping function. We will distribute a first draft in a few days.

Please find below the example for a basic call flow for the described interworking. 

User A (SIP) calls User B (SIP), B is busy (Call to User C),  CCBS possible
	IP				PSTN
          A                               Gateway                              B                   C
     |     Invite        |                  |   (1)     |
     | ----------------->|                  |
     |                   |    IAM           |
     |                   |----------------->|
     |                   |  Rel CCBS=yes (2)|
     |                   |<-----------------|
     |  486 Busy Here    |                  |
     |  CCBS Possible (3)|                  |
     |<----------------- |                  |
     |                   |    TC Begin      |
     |   subscribe (4)   |    CCBS Request  |
     |-----------------> |----------------->|
     |                   | TC Continue      |
     |      200 OK       | CCBS Request resp|
     |<----------------- |<-----------------|
     |   Notify (5)      |                  |
     | ----------------->|                  |
     |   200 OK          |                  |
     |<----------------- |                  |
     |                   |                  |  (6)     |
     |                   | TC Continue      |
     |     Notify  (7)   | Remote User free |
     |<------------------|<-----------------|
     |    200 OK         |                  |
     | ----------------->|                  |
     |                   |                  |
     |    Invite         |    IAM  (8)      |
     | ----------------->|----------------->|
     |      200 OK       |       ANM        |
     | <-----------------|<-----------------|
     |                   |                  |

Note 1:	B is busy with C
Note 2:	ISUP Release Message with cause #17 or #34 with diagnostic field indicating CCBS possible
Note 3:	The indication CCBS Possible here can be transported in the Message body of the response, needs definition in XML
for SIP based services the usage of the Retry after header is also possible 
	the Busy Response should transport the B-URI in the contact header 
check usage of other Busy codes  e.g. 600, 603???
Note 4: 	URI in Subscribe from busy contact header
	Epires Header defines duration of subscription, value from CCBS-T7
	subscribe for events defined in  draft-sipping-call-unrelated-PSTN2SIP-package-00.txt
	Event Header defines typical CCBS Events from draft-sipping-call-unrelated-PSTN2SIP-package-00.txt
note 5: 	It is necessary to send an immediate NOTIFY. It solves the Heterogeneous Error Response Forking Problem (HERFP).
Note 6:	B becomes free
Note 7: 	Notification to A that user B is free
Note 8:   ISUP indication that it is a CCBS-Call

Regards

> Joachim Pötzl
........................................................................................
Deutsche Telekom AG
T-Com Zentrale T38-13
Signalling, Gateways and Switching Systems
64307 DARMSTADT, GERMANY 
Phone:  +49 6151 83-2134
Fax:      +49 6151 83-4577
email:	[email-masked]
........................................................................................

_______________________________________________
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: Sean Olson <[email-masked]>
Date: Thu, 25 Jul 2002 09:23:33 -0700 (PDT)

I think the CCBS indication that you are looking
for could be summed up in an "Allow-Events: dialog"
header in the 486 response. This is based on
an assumption that the CCBS indication is a boolean
and that the Contact: URI that you are supplying in
the 486 is what you intend to use for the 
Request-URI in the subsequent SUBSCRIBE. In other
words, I don't think you need to invent anything
new here. It would still be useful to publish
how you see this working and perhaps it would
fit into the service examples draft.

What I have in mind would look like

SIP/2.0 486 Busy Here 
From: <sip:[email-masked]>;tag=a
To: <sip:[email-masked];user=phone>;tag=1
Call-ID: [email-masked]
Allow-Events: dialog
Contact:
<sip:[email-masked];methods=SUBSCRIBE>
Retry-After: 180
Content-Length: 0

There may be subtleties that I am missing here

Regards,
Sean

--- "Poetzl, Joachim" <[email-masked]>
wrote:
> Hi,
> 
> we have checked draft-ietf-sipping
> dialog-package.txt and other relevant drafts for
> applicabilty to serve for interworking scenarios
> (PSTN/SIP) for services which uses call unrelated
> signalling (e.g. Call Completion to busy Subscriber
> (CCBS, ITU-T Q.733.3),Call Completion on No Reply
> (CCNR, ITU-T Q.733.5),Message Waiting Indication
> (MWI, ITU-T))
> 
> The described functionalities are not sufficient for
> a proper interworking, because the knowledge of
> dialog states is only applicable in the SIP domain.
> A real interworking between both worlds needs more
> functionality than just a mapping of parameters and
> defining dilog states in the SIP domain.
> 
> The interworking of information elements and
> messages has to take place in a unit (e.g. Media
> Gateway Controller) which is capable to set up SCCP
> messages containing the appropriate SCCP-messages.
> Furthermor it needs an instance of the TCAP CCBS ASE
> and has to obbey the rules for SCCP routing. In the
> backwards direction it is desireable to map all the
> ISUP parameters contained in the CCBS-recall into
> the SIP-domain (e.g. CCBS recall indication).
> 
> We propose to put the necessary functionalities,
> events, mapping of elments in a new event package
> for the SIP events architecture
>
(draft-sipping-call-unrelated-PSTN2SIP-package-00.txt)
> accompanied by another draft which describes the
> requirements for the mapping function. We will
> distribute a first draft in a few days.
> 
>           A                               Gateway   
>                           B                   C
>      |     Invite        |                  |   (1) 
>    |
>      |                   |                  |  (6)  
>   |
> Note 2:	ISUP Release Message with cause #17 or #34
> with diagnostic field indicating CCBS possible
> Note 3:	The indication CCBS Possible here can be
> transported in the Message body of the response,
> needs definition in XML
> 	subscribe for events defined in 
> draft-sipping-call-unrelated-PSTN2SIP-package-00.txt
> 	Event Header defines typical CCBS Events from
> draft-sipping-call-unrelated-PSTN2SIP-package-00.txt
> note 5: 	It is necessary to send an immediate
> NOTIFY. It solves the Heterogeneous Error Response
> Forking Problem (HERFP).
> Note 6:	B becomes free
> Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com