Subject: [Sipping] Re: I-D ACTION:draft-roach-sipping-callcomp-bfcp-00.txt

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Oct 2006 10:22:20 -0400

Adam,

I like this approach.

But I think you have been overly restrictive in how you are using this 
mechanism. The following are a couple of suggestions:

- When a caller is granted active status, instead of making a *new* 
call, why not just reINVITE and add the media to be used for the call? 
At the same time the BFCP stream could be dropped, or it could be retained.

- why wouldn't it be ok for a caller to make a call offering BFCP *and* 
other media? The callee could then answer the call and accept one or the 
other media. (Or both if it wanted, but that probably wouldn't make a 
lot of sense here.) I'm not sure what kind of UI could make use of this, 
but it certainly doesn't seem to hurt anything.

	Paul

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: A Call Completion Service for the Session Initiation Protocol (SIP) Using the Binary Floor Control Protocol (BFCP)
> 	Author(s)	: A. Roach
> 	Filename	: draft-roach-sipping-callcomp-bfcp-00.txt
> 	Pages		: 26
> 	Date		: 2006-10-16
> 	
>    This document proposes extensions to the Session Initiation Protocol
>    (SIP) and the Binary Floor Control Protocol (BFCP) for service
>    request and queue manipulation related to the Completion of Calls to
>    Busy Subscribers (CCBS) and Completion of Calls on No Reply (CCNR)
>    services.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-roach-sipping-callcomp-bfcp-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of 
> the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-roach-sipping-callcomp-bfcp-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-roach-sipping-callcomp-bfcp-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Shida Schubert <[email-masked]>
Date: Wed, 18 Oct 2006 09:41:45 -0700

Paul;

My comments inline..

Paul Kyzivat wrote:
> I think it depends on who is providing the BFCP server function.
Adam's draft leaves room for BFCP server(CCBS/CCNR server)
and UAS to be decoupled in which case what you are suggesting might not
work.
>
> - why wouldn't it be ok for a caller to make a call offering BFCP
> *and* other media? The callee could then answer the call and accept
> one or the other media. (Or both if it wanted, but that probably
> wouldn't make a lot of sense here.) I'm not sure what kind of UI could
> make use of this, but it certainly doesn't seem to hurt anything.
> Assuming call is parallel forked and CCBS/CCNR server and UAS are
decoupled, having both BFCP *and* other media might trigger the
CCBS/CCNR service
before other UAs.(Assuming CCBS/CCNR server would return a 200 OK with
the BFCP session acceptance before any other UAs returning 200 OK)
>> Title : A Call Completion Service for the Session Initiation Protocol
>> (SIP) Using the Binary Floor Control Protocol (BFCP)
>> Author(s) : A. Roach
>> [email-masked] with the word unsubscribe in the body
>> of the message. You can also visit
>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your
>> subscription settings.
>>
>> logging in, type "cd internet-drafts" and then "get
>> draft-roach-sipping-callcomp-bfcp-00.txt".
>>
>> http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Oct 2006 13:19:32 -0400

> and UAS to be decoupled in which case what you are suggesting might not

How does it allow them to be decoupled? From 5.1.3:

   When the calling party indicates that they are ready
   for the call to proceed, the calling party user agent initiates the
   call.  It does so by sending an INVITE request to the URI that it
   received in the Contact header field of the 200-class response to the
   INVITE that set up the BFCP session.

That contact is the same place that the BYE will go for the call that
established the BFCP session.

They *can* be decoupled even working this way. The BFCP server can act
as a B2BUA when it gets the expected INVITE.

Another possibility is for it to return a 3xx when it gets the reINVITE,
though the behavior of the caller in that case isn't so clear.

> the BFCP session acceptance before any other UAs returning 200 OK)

I agree that using the mechanism this way would lead to a somewhat
different service behavior. Might be better, or worse, or just suit
different needs.

Including both can result in a variety of different scenarios:

- it could be offered to phones. If one accepts, it may accept
  only the media, and refuse the BFCP stream. That's fine - the
  call works.

- it could be offered to phones, but none answers. After awhile
  it is offered to separate BFCP server, which accepts the BFCP
  and rejects the other media. Subsequent reinvite offering
  media again might be passed on to the phones by the BFCP server
  acting as a B2BUA.

- there might only be one phone that acts as its own BFCP server.
  If it is free it accepts the media and rejects the BFCP. If it
  is busy it accepts the BFCP and rejects the media.

	Paul

---

From: Adam Roach <[email-masked]>
Date: Wed, 18 Oct 2006 14:31:42 -0500

> established the BFCP session.

You are correct, and this is an oversight on my part. I believe that
this indicates that we need to convey this URL in some other fashion.
The intention in the draft certainly is that the CCBS server could be
somewhere else. Hopefully, this will become somewhat clearer when I
expand section 7.

> as a B2BUA when it gets the expected INVITE.

Ugh. I understand what you're trying to achieve here, but it seems like
a very bad idea to have a B2BUA destroying service transparency just for
the sake of dialog re-use -- especially since the benefits of such
re-use haven't really been made clear yet.

> though the behavior of the caller in that case isn't so clear.

Yes; 3xx responses mid-dialog are ambiguous at best. I don't think we
want to go down that path.

>>> make use of this, but it certainly doesn't seem to hurt anything.

This assumes that the caller knows, a priori, that its user wishes to
make use of a call completion service. This isn't usually the way things
work.

>   is busy it accepts the BFCP and rejects the media.

I appreciate the mental exercise, but still haven't seen any identified
benefits. To be clear: I'm sure that there are myriad ways that the
mechanism I've proposed can be improved -- but your proposals so far
seem to be arbitrary changes with no clear benefits.

I'll also point out that including multiple ways to do something in a
protocol tends to *decrease* interoperability rather than increase it. I
would counsel against including flexibility that isn't warranted by
specific requirements.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Oct 2006 16:47:53 -0400

If the *intent* is that this service be disjoint from the target
devices, then as you mention, the target for the call must be conveyed
some other way. And then all the other stuff I was talking about is moot.

Seems like it might make sense to convey the URI to call in the BFCP
message when notifying that access has been granted.

	Paul