AW: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00

["Huelsemann, Martin" <[e-mail]>]

Hi Jonathan, all,

I don't think that there really is a relationship between presence and call completion. Presence is about the general availibility of a certain user, call completion provides the possibility to complete a call to a certain destination you've got a busy error response from. Because of this busy indication it is clear that someone in principle can be reached at that destination, and with call completion this will be acheived as soon as the destination user hangs up the receiver, of course depending on your position in the queue. Perhaps there will be another person at the phone then you wanted to talk to, but at least you will get an answer.
 
I don't understand the problem with the notification and the race condition. I thought there would be a seperate BFCP session for each outstanding call completion request. And so the BFCP server at the callee could grant the floor for the user at the top of the queue independently from the other requests. Did I misunderstand this?


Regards, Martin










> -----Ursprüngliche Nachricht-----
> Von: Jonathan Rosenberg [mailto:[e-mail]] 
> Gesendet: Donnerstag, 2. November 2006 01:00
> An: IETF Sipping List
> Betreff: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00
> 
> 
> This is a very interesting draft. Neat idea to use BFCP to manage the 
> queue.
> 
> Its not clear to me that this mechanism works well in the face of 
> forking. Seems like you could end up with disparate queues 
> for each of 
> my phones. What you are really after is the state of the user (i.e., 
> AOR) and not their devices. This seems to make it problematic to 
> implement this in the UA at all. I understand your intention is that 
> this be in a server in the network; but if it only works in 
> that case it 
> needs to be called out.
> 
> Similar issues arise when the originating user has multiple 
> devices. So 
> if I call you from phone 1, and later you are available, does the 
> ringback happen only at phone 1 or all of my phones? Seems like the 
> latter is much more desirable. That too implies that a 
> UA-based solution 
> on the originating side has some problems.
> 
> There is clearly a relationship between all of this and presence; I 
> think you need to call that out.
> 
> On whether BFCP is the right thing or not for this problem, I'm not 
> sure. In one sense, you could characterize this as really a 
> problem with 
> RFC3265 in general; that for certain event packages, 
> notification of an 
> event to all watchers can cause them to take actions that result in a 
> further change to that same state. This is a race condition.
> 
> An alternative way to model the queueing discipline to fix 
> the race is 
> through a generic capability in RFC 3265, which sends out 
> notifications 
> gradually. You need to be careful to not end up embedding 
> queue control 
> commands in SUBSCRIBE as you have pointed out previously. However, 
> nothing stops a notifier from sending out notifications one 
> at a time. 
> That would not permit you to do things like pause your 
> position in queue 
> or similar features, but 3265 sometimes feels to be more 
> on-target for 
> this service.
> 
> I share John's concerns as to whether this really 
> interoperates with the 
> PSTN. Perhaps if you had some call flows demonstrating it, 
> this would help.
> 
> Thanks,
> Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [e-mail]                              FAX:   [phone]
> http://www.jdrosen.net                         PHONE: [phone]
> http://www.cisco.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
> 

_______________________________________________
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