Subject: [BLISS] comments on draft-poetzl-bliss-call-completion

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Dec 2007 11:00:39 -0500

Section 6.1:

I think this completely understates the problem; if the caller is using 
dialog and the callee is using http polling it completely fails. 
Similarly in section 6.3. Just because a UA supports the dialog event 
package, doesn't mean it would know to subscribe for call completion 
using it.

> Conclusion 
>      
>     As seen on the analysis above, when dialog event package is used, 
>     it's only the server that needs to support call-completion, and 
>     with the wide implementations of the dialog event package, high 
>     level of interoperability can be anticipated if this approach is 
>     used. 

I don't understand this. The caller needs to clearly support call 
completion since there needs to be a UI for the user to invoke it, and 
the UA has to know to utilize dialog event package. Call completion is 
clearly a double-ended service in that both sides need to support some 
functionality beyond existing specs for it to work.

General comments:

The document says there is no role for state agents. But what about a 
user that has multiple devices. Is the assumption that there is a 
stateful b2bua type of element that is aware of the state of all of 
them, and the subscribe terminates there? That would be a state agent. 
Or does the SUBSCRIBE fork to all devices? This is important since we'll 
need to make recommendations on which elements implement the event agent 
side of this - phones or 'servers' in the network. I'll note this 
question is addressed in draft-worley-call-completion. That draft raises 
several issues which need to be addressed, in particular:

1. handling multiple UAs at caller side
2. handling multiple UAs at callee side
3. correlating the call completion call with the queue request
4. figuring out how to determine the availability states of user/UA

So I believe we will need to combine these two drafts for a complete 
solution.

Nits:

> this, until either the callee receives a HTTP response that 
> 
>  Poetzl                    Expires May, 2008                    Page 4 
>   
>  Internet-Draft             Call Completion              November 2007 
>   
> 
>     contains information about caller's readiness for receiving a call 
>     or it gives up. 

s/caller's/callee's

>  it MUST include "application/call-completion". This 
>     "application/call-completion" data format is described in chapter 
>     8. 

you mean Section 10

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Fri, 7 Dec 2007 15:51:27 +0100

Hi Jonathan,

some answers inline.

BR, Martin

> -----Ursprüngliche Nachricht-----
> Von: Jonathan Rosenberg [mailto:[email-masked]] 
> Gesendet: Donnerstag, 6. Dezember 2007 17:01
> An: [email-masked]
> Betreff: [BLISS] comments on draft-poetzl-bliss-call-completion
> 
> 
> Section 6.1:
> 
Yes, that's one of the issues of using the dialog event package. It's not dedicated to call completion.

> functionality beyond existing specs for it to work.
There is definitely a missing semantics in the dialog event package, that would indicate to the UA that it's going to be queued and notified only when it's at the top of the queue. We have added this because we heard from others that this kind of implementation based on dialog-event package really exists in the wild.
>From our understandings, the server with this kind of dialog-event implementation,  selectively sends NOTIFY with "dialog terminated" to the subscriber that was on the top of the queue. When this solution is used, a UA never knows that it is in queue, it thinks it's simply subscribing to a dialog-event package. The overall result of this is that the UAs are getting the notification with callee's availability in order, similar to when call-completion package is used, except for the UA being 
aware of the fact that it's actually being queued. But anyway also when the caller does not support call completion, with the fallback to the dialog event package the callee has the possibility to receive the (redial) calls in order.

> So I believe we will need to combine these two drafts for a complete 
Yes, that is the plan once the work on Dale's document is finished. For the time we work on call completion it's easier to be able to update the two different documents.

> > >  Internet-Draft             Call Completion              
> November 2007 
> >   
> > 
Oh, of course, thank you.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Dec 2007 13:13:28 -0500

Martin,

I have no problem with using the dialog event package as a fallback for 
this feature. But only if it is a *vanilla* implementation of the dialog 
event package. If queuing is added to the dialog event package then it 
is no longer the same package. Adding the queuing semantics breaks its 
value for other purposes, and is entirely unacceptable.

	Paul

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Wed, 12 Dec 2007 18:05:36 +0100

Hi Paul,

in my understanding this would be a fallback to an unchanged dialog event package, basing on the procedures in the services examples draft for an automatic redial, only with the notifications send in order.

BR, Martin

> Von: Paul Kyzivat [mailto:[email-masked]] 
> Gesendet: Freitag, 7. Dezember 2007 19:13
> An: Hülsemann, Martin
> Cc: [email-masked]; [email-masked]; [email-masked]
> Betreff: Re: AW: [BLISS] comments on 
> draft-poetzl-bliss-call-completion
> 
> 
> Martin,
> 
> > Yes, that's one of the issues of using the dialog event 
> package. It's not dedicated to call completion.
> > 
> >  
> >>> Conclusion 
> >>>      
> > There is definitely a missing semantics in the dialog event 
> package, that would indicate to the UA that it's going to be 
> queued and notified only when it's at the top of the queue. 
> We have added this because we heard from others that this 
> kind of implementation based on dialog-event package really 
> exists in the wild.
> >>From our understandings, the server with this kind of 
> dialog-event implementation,  selectively sends NOTIFY with 
> "dialog terminated" to the subscriber that was on the top of 
> the queue. When this solution is used, a UA never knows that 
> it is in queue, it thinks it's simply subscribing to a 
> dialog-event package. The overall result of this is that the 
> UAs are getting the notification with callee's availability 
> in order, similar to when call-completion package is used, 
> except for the UA being 
> > aware of the fact that it's actually being queued. But 
> anyway also when the caller does not support call completion, 
> with the fallback to the dialog event package the callee has 
> the possibility to receive the (redial) calls in order.
> > 
> > 
> > 
> >> General comments:
> >>
> > Yes, that is the plan once the work on Dale's document is 
> finished. For the time we work on call completion it's easier 
> to be able to update the two different documents.
> > 
> > 
> >>
> >>
> >>
> >> Nits:
> >>
> >>> > >  Internet-Draft             Call Completion              
> >> November 2007 
> >>>   
> >>>