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

[Paul Kyzivat <[e-mail]>]

Shida Schubert wrote:
> Paul;
> 
> My comments inline..
> 
> Paul Kyzivat wrote:
>> 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.
>> 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.

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.

>> - 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)

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

>> Paul
>>
>> [e-mail] 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
>>> [e-mail] 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:
>>> [e-mail].
>>> 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
>>> [e-mail]
>>> 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 [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