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

["Mark Watson" <[e-mail]>]

The dialog events package does not allow you to properly implement CCBS.
Neither is direct re-creation of the CCBS service in SIP a good idea.

If you generalise CCBS you get the following service:
1) A sends B a SIP request
2) B fails this request (for some (any) reason)
3) A asks B *whether* and *when* they will accept the same (or similar)
request in future
...time passes...
4) (optionally) B tells A that they are now ready to accept the request
5) A sends B a SIP request

Knowing the state of some dialogs at B does not give A the information about
whether B will accept a 'repeat' request. Firstly, A does not know what the
various dialogs are *for* (IM, gaming, voice conversation etc.) and so does
not know which of them is occupying the attention of the user and so causing
their UA to reply Busy (or whatever). Secondly, why would B *want* to give A
information about their ongoing dialogs ? All that B needs to reveal is at
what point they are willing to accept a particular request. Since A could
ask B for this information at any time (by sending the request), then there
is no new information being revealed.

Two final points:
o You can implement a reasonable approximation to CCBS by simply retrying
every minute or so. Ok, so this wastes messaging and is not as nicely
engineered, but it provides a service of sorts
o CCBS was a very popular service until everyone got voicemail. Here in the
UK one v.large provider gives voicemail free to residential customers. With
vm they get revenue for the message being left *and* (probably) a return
call. With CCBS they just get the one call completion. How much effort is
justified for a service which is in some sense obselescent ?

...Mark

> -----Original Message-----
> From: Sean Olson [mailto:[e-mail]]
> Sent: 25 July 2002 17:24
> To: Poetzl, Joachim; [e-mail]
> Subject: Re: [Sipping] new event package for CCBS, CCNR, MWI
> 
> 
> 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:[e-mail]>;tag=a
> To: <sip:[e-mail];user=phone>;tag=1
> Call-ID: 1231@10.0.0.2
> Allow-Events: dialog
> Contact:
> <sip:[e-mail];methods=SUBSCRIBE>
> Retry-After: 180
> Content-Length: 0
> 
> There may be subtleties that I am missing here
> 
> Regards,
> Sean
> 
> --- "Poetzl, Joachim" <[e-mail]>
> 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:  [phone]
> > Fax:      [phone]
> > email:	[e-mail]
> >
> ..............................................................
> ..........................
> > 
> > 
> > 
> > _______________________________________________
> > Sipping mailing list 
> > https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application
> > of SIP
> > Use [e-mail] for questions
> > on current sip
> > Use [e-mail] 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 [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
>