Subject: [Sip] Re: draft-mahy-sip-remote-cc-01.txt

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Feb 2004 16:06:56 -0500

I find the newest version of this draft troubling. It feels to me like 
it has selected a slippery slope and is already accelerating rapidly 
downward.

My major concern is with the approach described in section 4:

    Alternatively, the Refer-To URI could be a Universal Resource Name
    (URN) [21] which could describe a particular operation such as Hold
    or Retrieve.  Combined with the dialog-identifiers of an existing
    session conveyed as parameters of the Refer-To header, this would
    permit explicit operations which do not need additional parameters or
    handle more than a single session.  For example, the following could
    represent a Hold operation of a session with the Call-ID "123":

    	Refer-To: <urn:ietf:params:sip:remotecc:hold>
    	 ;call-id=123;remote-tag=aaa;local-tag=bbb

Further examples are given abstractly, for example:

     --------------------------------
     | Remote Call Control Body     |
     | transfer                     |
     |   FirstCall=                 |
     |     sip:[email-masked]    |
     |     call-id:456              |
     |     remote-tag=uvw           |
     |     local-tag=xyz            |
     |   SecondCall=                |
     |     sip:[email-masked]    |
     |   other parameters           |
     --------------------------------

My concern is that this appears to be defining an explicit feature 
invocation model, with specific features that have names and parameters. 
While it could conceivably be in scope for IETF to define things to this 
level, in the past the sip wg has avoided doing so. If that philosophy 
is to change, then I think we must consider all the implications of 
doing so.

I think every feature of this sort will require a considerable effort to 
specify in sufficient detail so that interoperation is assured. It may 
be that we are already in that situation with REFER and just haven't 
realized it yet, but I am inclined to think this makes that situation worse.

I don't think the features as described go far enough to define their 
semantics. In particular, I think it is difficult to define the meaning 
of these features without addressing media handling and the management 
of explicit UI components of the endpoint. For instance, what does 
MakeCall imply about the UI and media handling on the device that is to 
make a call? Is the user alerted first, with the device awaiting an 
off-hook before completing the call? Or are the microphone and speaker 
in the handset activated for media even though the phone is on-hook? If 
the device is capable of using multiple media, which are enabled in the 
call? The questions abound.

More generally, must all endpoints that support extended-refer support 
every feature that might be named in a Remote Call Control Body? If so, 
how do we evolve the set of features? If not, how does a UA determine 
what features it can invoke, and how?

The approach of simply enhancing Refer-To with header parameters that 
simplify the construction of complex referred operations is more 
bounded, and less likely to present issues in the future. Of course it 
may or may not be sufficient for the kinds of call control people may 
want to do remotely.

	Paul

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