Subject: [SIP] REFER issues

From: Rick Dean <[email-masked]>
Date: Wed, 24 Jan 2001 10:49:17 -0600

Dear SIP list,

I apologize for only publishing my side of
this debate, but I feel right publishing
other people private correspondence.  I need
to publish my comments, so I don't
to endlessly repeat myself in many conversations.

--
Rick

> Rohan,
> 
> Thank you for your thoughts.  I wrote this off line last night.
>
> I agree HANDOFF is very late in comming.  Hopefully, not too
> late.  It would mean some abandoned REFER work for me as well.
> 
> I would be powerful if a remote host forwards all of its sniffed
> packets to me, and the remote sends any packet I forward to
> it.  Admittedly extreme, but not only would it ignore security and
> privacy, it has implemented nothing.  The work has simply
> been moved around.
> 
> Without a layered architecture, I don't know how to assign
> the functionality of HANDOFF and PhoneControl to different
> programmers using REFER.  If we can cleanly separate these
> two, should we?
> 
> The syntax of REFER is more complicated.  Do you know when to escape?
> How about REFER with a method=refer?  The readability of
> SIP is lost.
> 
> What kinds of security precautions should I put in my
> REFER implementation?   If there is a level less than root,
> what should it do with headers it doesn't recognize?
> How many pages is your sandbox design?  ...and megabytes of
> code?  .... or bug reports?
> 
> If I already implement PhoneControl to talk to a PDA or
> PC helper app, should I also support a REFER duplicate?
> ...or should the PDA and PC have a full SIP parser
> and their developers be SIP experts?
> 
> If we remove HANDOFF, PhoneControl, and JOIN functionality
> from REFER,  what is left?   (Hopefully nobody ever drafts JOIN.)
> 
> --
> Rick
> 
> BTW, the join wording of PHONECTL was changed to handoff.  Some
> typos were fixed.   http://phonectl.sfour.com/

> Rohan,
> 
> Agreed that TAKE is another primitive supported
> by REFER, but not covered in the other drafts.
> I reject REFER in part because I don't want TAKE.
> 
> Without PHONECTL access, how do I know about the
> call leg I am going to take?  Do you expect a
> subscription to allow me to see all of someone
> else's SIP traffic?   Heck, with that why not forge
> BYE and HANDOFF messages in the call-leg?
> 
> Will your UA handoff a call to another with
> the expectation of being able to take it back?
> What if the remote entity doesn't cooperate?
> You won't learn until too late.  The error
> message would be comical.  With my envisioned
> TAKE scenarios, the participants are too
> altruistic.
> 
> Taking back a call from a music-on-hold server
> would be slower than ending a B2BUA.  Please don't
> assume every network device is within a 20ms ping time.
> I like to count by 100ms, and this doesn't assume loss.
> 
> We are working on a draft for pickup.  The current
> designs require a centralized privledged server.
> I don't totally like them.  Maybe a TAKE
> method would be good for this for rining calls only.
> Nonetheless, the action of reviewing ringing
> calls and instructing one to transfer is better
> suited by a remote control layer, e.g. phonectl.
> 
> To support phone provisioned pickup privledges, wouldn't
> you need to modify some user interface.  At this
> time wouldn't the SIP be modified to support it?
> I don't buy your arguement against needing to code
> additional methods being a problem.
> 
> Thank you for hearing me out.
> 
> --
> Rick
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 24 Jan 2001 21:26:07 -0800

Hi folks,

Following in Rick's footsteps...  Billy's private comments are likewise
removed.  I'm happy to move the rest of this thread to the list.

>to endlessly repeat myself in many conversations.

agreed.  IMO the hardest part of the work is defining the trust
relationships for the parties involved in features.
 
>> programmers using REFER.  If we can cleanly separate these

on the UAC side the work is independent in that each programmer just
creates the appropriate Refer-To URL and adds any special case error handling.

on the UAS side, you do the work to support the primitive and parse the URL
once, then the work is in adding something like an access-list definition,
or sandbox definition for the additional functionality.

>> How about REFER with a method=refer?  The readability of

yes, this is an admitted drawback.  You have to be able to read URLs and
then imagine what will happen to the bubbles based on the headers in the
Refer-To URL (not the easiest).  escaping should be done once for an
implementation of REFER, so it is complex for writing only once.

>> code?  .... or bug reports?

a sandbox design should be 2-5 pages.  In some cases it can be just a few
paragraphs.  It is like the section in HANDOFF where you guys explicitly
defined some illegal things (methods, call-id, etc...).  Each primitive
will need this code as apropos for its application.  We're not talking
about a lot of code if you do it well.  
 
>> and their developers be SIP experts?

for that application, phonectl is still a reasonable model.  we need full
coverage, but some overlap of functionality isn't the end of the world.
 
>> from REFER,  what is left?   (Hopefully nobody ever drafts JOIN.)

see our further discussion on TAKE....

------------
A previous reply to Rick's other post....
>>call leg I am going to take?  
>
>Choice 1: you were originally a party to the call so you know it's call-id.  
>presumably your original role in the call gives you some rights in certain 
>circumstances automatically.  I almost certainly don't want to give phonectl 
>style control to you just because we were in a call together once.
>
>Choice 2: you are already a trusted role/entity in the network.  I probably 
>don't want you to be able to do phonectl things to me.  call center take, 
>and operator barge-in needs one role (supervisors, attendants, operators) to 
>be able to ask special things of another role (the agents/ordinary users).
>
>Note that I may use PHONECTL to control my desk phone, which I use as as a 
>call center agent, and for regular business calls. Based on my role, I am 
>willing to grant permission to my phone to let an authenticated category of 
>folks (supervisors) tell the phone to do rude things to my call-legs 
>occasionally, but only for my call center persona.  Likewise these same 
>folks should be able to SUBSCRIBE to certain things (this may be the same 
>group of Events that PHONECTLs companion subscriptions use). 
>
>>Do you expect a
>>else's SIP traffic?   
>Absolutely not.  
>>Heck, with that why not forge
>I can already do that anyway if I can see your packets, and that is pretty 
>easy.  We need SIP message integrity and authentication anyway.  
>
>sometimes.  a music on hold server is an automaton. like conferencing 
>servers, it would be reasonable to explicitly design automatons such that 
>you can undo anything you ask them to do.  you can make this behavior 
>explicit in a spec.  this is a very different thing from asking you to cease 
>talking to billy and talk to me now, just because sometime in the past I 
>transfered you to him.
>
>it's allowed to refuse, just like it can refuse an INVITE or a BYE.  all 
>call control features in a peer to peer environment must be based on mutual 
>cooperation for mutual benefit.
>
>>would be slower than ending a B2BUA.  
>
>cooperation takes time, just like in real life ;-)
>
>I do think we can make these flows reasonable for the common cases; even 
>with 100ms rtts.
>
>>Please don't
>It's not a problem, but it effectively neautralizes the gain you champion of 
>small code size for your more numerous individual primitives.
>
>hey, this is fun.  i've been trying to get people to talk about features for 
>A LONG TIME, and there finally appears to be some interest.  :-)
>
>take care,
>-r
>
>>--
>>Rick
>>
>>
[snip]

>>> >> Seriously, I think we can put a security sandbox around your REFER
>>> >> security concerns, and nail down explicit Replaces, Joins, Fork-with
>>> >> or other headers that indicate the relationship of the triggered
>>> >> INVITE to existing call[ leg]s.

[like what?]

>>> having to authorize other methods, arbitrary call-ids, arbitrary headers,
>>> etc...
>>> 
>>> >> If HANDOFF was the first attempt to solve the transfer problem, I
>>> >> would have endorsed it wholeheartedly.  Now that I see what it can do,
>>> >> I don't want to give up the power of REFER. In either case I will
>>> >> yield to consensus.
>>> >
>>> >> FYI: I'm attaching some notes on call primitives based on "the bubble
>>> >> model" of a call.  Each primitive does not need to map onto a SIP
>>> >> method.  Each "primitive" corresponds to a distinct way to move
>>> >> parties in and out of call bubbles...

>>> draw ovals (bubbles) representing all the folks you want to be a "call".
>>> the basic operations on the bubbles are adding, removing, and replacing
>>> parties; and joining and spliting bubbles.  The primitives that I described
>>> (I picked an arbitrary breakdown of them, but close to a complete
>>> breakdown) are grouped based on what I consider to be the "interesting"
>>> part of the problem, which is authorization.
>>> 
>>> who should be allowed to take a call?  you shouldn't need authorization to
>>> do phonectl for every application of take.  You should be able to
>>> "takeback" a call that was yours in some circumstances.  Some trusted peers
>>> should be able to take some calls, but not all (your supervisor can take
>>> calls from you call center agent persona, but not from your personal
>>> persona.)  Hopefully you get the idea here.

>INVITE	BYE
>a originates	a or b originates
>a => a-b	a-b => a
>
>18x (progress) 	200 (accept)
>
>HANDOFF	TAKE
>	a-b => b-c
>a originates	c originates
>		could be used to retrieve parked call, call held with music, call center
take...
>		voice browser/voicemail yanking-back call
>
>		REFER or Interrupt
>
>		can take calls you used to be a party to (generate a takeback token)
>		also trusted 3rd parties...
>
>ADD		DROP
>a-b => a-b-c	a-b-c => a-b
>	originated by a or b
>with local mixing, just local implementation
>
>in full mesh, add is an INVITE with members header
>no way to "banish" a party for full mesh
>
>in conf bridge environment, how do I find out who is currently in the
>conference (SUB/NTFY).  how do I remotely add, drop, and mute them?
>
>	sip:conference-server;method=REFER?refer-to=<C;method=BYE> (drop)
>
>who should get to do this?  conference owner(s)
>
>FORK			INSERT
>a-b => a-b & a-c	a-b => a-b-c
>	originated by c
>mixed locally
>- originated by a:  just do it
>- originated by c:  Interruption.......
>conf bridge
>- originated by a: ask conf to do it
>- originated by c:  either Interrupt a (who asks conf), or ask conf
>directly (REFER)
>
>same rules as for take....
>
>conf - a, b, c  

etc.
>>> The problem with most primitives that purports to do conferencing, is that
>>> they rarely work for all four conferencing topologies:  conf bridge, local
>>> n-way mixing, full mesh, multicast conf.  If it doesn't, you end up
>>> frequently with REFER/HANDOFF to something else.

more rants...
>Little "c" conferencing isn't a feature, it is a basic services that you use 
>to build other features.  If you want to build features that involve more 
>than 3 simultaneous parties, then chances are you need conference control.  
>I don't give a rat's ass about floor control, voting, side channels, etc  as 
>defined in a traditional Conferencing System.  I just want to build the 
>features.  For that matter, we also need forking (multi-unicast) as a basic 
>service.
>
>Here are some examples of features that need conference or forking 
>primiitives (join isn't sufficient):
>
>	screening your voice mail
>	residential line emulation (classic use of full-mesh or multicast)
>	call center monitoring (supervisor or recording)
>	call center coaching
>	any of the examples I gave for TAKE.
>
>hope this helps...
>
>thanks,
>-rohan