[asterisk-dev] New group CCSS branch

Mon Aug 17 10:25:37 CDT 2009

Roman Sidler wrote:
> Hi Mark
> Cool, someone sets the ball rolling!
> Many days of hard work in your paper...
> 
> 1)
> We've implemented our own implementation and it's working since many years. It 
> has been ported recently to 1.6.1.0.
> http://lists.digium.com/pipermail/asterisk-dev/2005-February/009856.html
> Since this mail, I've simplified many things (e.g no asn1c) and  brought it  
> to a rather mature stage.
> 
> The outlines
> - Transfered over QSIG(BRI/PRI), IAX2. Local, Goto()
>   (it works locally, and over many asterisk[transit])
> - Invoked by SIP-Instantmessage or Dialplan (postdial, e.g. *02 as EXAMPLE1)
> - The monitoring of userB is protocol (technology)-independent
> - No new configuration, the dial plan is consulted (especially the hints)
> - the whole state machine of agent(PTNXA) and monitor(PTNXB) is implemented in 
> 1 module (res_ccomp.c) 
> ****Stop commercial***
> 
> About your document:
> 2)
> Do you really intend to support the monitoring of several terminals:
> exten => 50,1,Dial(SIP/2000&Local/100 at example)
> 
> In the ISDN world the start of CCBS is defined by hangupcause=busy. 
> The 1Caller-to-1Callee-CallCompletion produces as well never-ending 
> combinations ;)

Yes, it is intended to fully support forked dialing. And yes, support for this 
is probably the thing that has caused more headaches than anything else ;)

> 
> 3)
> The terms are slightly different than in the ISDN standard. The goals are the 
> same. Is here a reason.

To be honest, I'm not an ISDN guy, so I just used terminology which made sense 
to me. I'm certainly up for changing terms and configuration options if they'll 
make things more clear to people who are familiar with ISDN CCBS/CCNR.

Do you have any specific examples that you think should be changed?

> 
> 4)
> Why should the system initiate a cc_offer?
> The caller (userA) could start this game. The service is rejected if one stage 
> fails. It makes things more complex, if the previous call state needs to be 
> remembered. 

I apologize, but I don't really understand what you're asking here (but I can 
try to guess). I think this may be a case where the terminology used in the pdf 
is different from that used traditionally in the ISDN world. When I use the word 
"offer" in the CCSS document, I mean advertising the availability of the 
service. As an example, with ISDN, a DISCONNECT will indicate if the network 
supports CCBS. This, in my terminology, constitutes a CCBS "offer."

Another thing to keep in mind is that not CCBS/CCNR requests will specify the 
called parties. For instance, with SIP, the final response to an INVITE will 
contain a URI to send a SUBSCRIBE request to in order to request CCBS/CCNR. 
Then, whoever receives that subscription request will have to associate that 
request to a previous call. So in a situation like that, we have to remember the 
previous call state. Also, for cases where we use a generic CCSS agent as 
specified in the document, the phones that request CCBS/CCNR will have no 
concept of what it is they're doing, and for those we also need to remember the 
previous call. And, of course, the back-to-back nature of Asterisk means that 
even if the inbound leg of the call is ISDN, the outbound forks of a dialed call 
may all use different protocols. Of course for a situation like this, Asterisk 
needs to be able to remember all the necessary information in order to be able 
to make the necessary outbound requests.

> 
> 5)
> Have you already figured out a usable  mechanism in SIP to support such a 
> complicate service?
> 

The BLISS working group has been working on this for quite some time. Their 
latest draft can be found here:

http://tools.ietf.org/html/draft-ietf-bliss-call-completion-04

This is what we will be implementing in Asterisk. Of course, if a new draft 
should be issued or if this should become an RFC, then we will update the 
implementation to support any differences. It is doubtful, though, that the 
basic flow of messages is going to be changing any at this point.

> We're really interested to see this service in the asterisk trunk.
> Thanks for your effort!

Thanks for your comments and questions, too!

Mark Michelson

> 
> Roman
> 
> 
> On Friday 14 August 2009 19:02:13 Mark Michelson wrote:
>> Hi devs,
>>
>> I have recently created a new subversion branch at
>> http://svn.digium.com/svn/asterisk/team/group/CCSS
>>
>> This branch is meant for adding CCBS and CCNR to Asterisk. In it, I have
>> added a document in /doc called CCSS_architecture.pdf. It contains a
>> relatively high-level look into how the features will be implemented within
>> Asterisk. I encourage any developers interested in this feature to give the
>> document a read and reply here if they see any inherent flaws, any
>> inconsistencies, or any unclear sections. I must warn that I am not a
>> technical writer, and so the document does not adhere to as strict a format
>> or writing style as seen in most standards. However, I think the document
>> gets the point across and provides some insight into the methods which will
>> be used for this feature.
>>
>> I plan to start coding as soon as possible according to the architecture
>> document that I have included. Don't let that stop you from raising
>> concerns, though.
>>
>> Thanks in advance for any constructive feedback.
>> Mark Michelson
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> AstriCon 2009 - October 13 - 15 Phoenix, Arizona
>> Register Now: http://www.astricon.net
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
> 
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> AstriCon 2009 - October 13 - 15 Phoenix, Arizona
> Register Now: http://www.astricon.net
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev