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

Sean Olson <seancolson@yahoo.com> Thu, 25 July 2002 16:50 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12148 for <sipping-archive@odin.ietf.org>; Thu, 25 Jul 2002 12:50:39 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11731 for sipping-archive@odin.ietf.org; Thu, 25 Jul 2002 12:51:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09761; Thu, 25 Jul 2002 12:23:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09721 for <sipping@optimus.ietf.org>; Thu, 25 Jul 2002 12:23:33 -0400 (EDT)
Received: from web11601.mail.yahoo.com (web11601.mail.yahoo.com [216.136.172.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10926 for <sipping@ietf.org>; Thu, 25 Jul 2002 12:22:28 -0400 (EDT)
Message-ID: <20020725162333.68639.qmail@web11601.mail.yahoo.com>
Received: from [207.46.137.8] by web11601.mail.yahoo.com via HTTP; Thu, 25 Jul 2002 09:23:33 PDT
Date: Thu, 25 Jul 2002 09:23:33 -0700
From: Sean Olson <seancolson@yahoo.com>
Subject: Re: [Sipping] new event package for CCBS, CCNR, MWI
To: "Poetzl, Joachim" <Joachim.Poetzl@telekom.de>, sipping@ietf.org
In-Reply-To: <A456C746A5E2D2118FC70090270F673B02FC1875@U8P19.blf01.telekom.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
X-BeenThere: sipping@ietf.org

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:bob@acme.com>;tag=a
To: <sip:+1-800-354-5466@gw.acme.com;user=phone>;tag=1
Call-ID: 1231@10.0.0.2
Allow-Events: dialog
Contact:
<sip:monitor-1231-10.0.0.2@gw.acme.com;methods=SUBSCRIBE>
Retry-After: 180
Content-Length: 0

There may be subtleties that I am missing here

Regards,
Sean

--- "Poetzl, Joachim" <Joachim.Poetzl@telekom.de>
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.
> 
> 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:	joachim.poetzl@telekom.de
>
........................................................................................
> 
> 
> 
> _______________________________________________
> Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application
> of SIP
> Use sip-implementors@cs.columbia.edu for questions
> on current sip
> Use sip@ietf.org for new developments of core SIP


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

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP