Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00

From: Rohan Mahy <[email-masked]>
Date: Mon, 04 Dec 2000 12:28:52 -0800

At 10:14 PM 11/29/00 , Billy Biggs wrote:
>Jonathan Rosenberg ([email-masked]):
>
>>>   The REFER transaction itself does not affect the old session.
>>> However, to keep our phone UI simple, we disconnect the old call.
>>> Users can't understand it otherwise.
>> 
>> You are most definitely confusing a primitive operation (REFER), with
>> a specific service, which is transfer.
>
>  Understandably we need some primitive.  I think we agree this
>primitive is "initiate a session with the Refer-To address".
>
>  Due to the design constraints of our device, we cannot keep around
>both calls.  I suspect that a PSTN gateway would be in a similar
>situation, since there is no way for the POTS phone to be able to
>indicate this.  When the new session is active, we disconnect the old.

You really can't keep state for a held call and an active call at the same
time?  I find that a little hard to believe.  I know of at least one PSTN
gateway that can do that  ;-).

>  Yes, we are unable to use services which require the old call to stay
>active.  It's a constraint.  But our implementation is completely
>reasonable and we do follow the spec.
>
>
>  So far, the only service I've halted seems to be Music-On-Hold, which
>requires that the far end have some crazy logic to send a BYE based on a
>REFER anyways.  I'm sure there will be other services that this device
>won't be able to handle, but I'm not worried yet.

Crazy logic?  When you want to take the user off-hold you tell them to stop
listening to music.  That seems pretty logical to me.

Attended transfers and Call Waiting need you to manage two sessions too.
This is a pretty basic feature for an IP phone.

>  I suspect that other SIP devices which try to act like phones will
>behave similarily, which is why I suggested to change the music call
>flow to be more interoperability-friendly.

what other IP phone implementations are you thinking of?

>> [...] Putting a Require header in to specify each service for which
>> REFER might be used is a bad thing. Its the same as writing a formal
>> protocol spec for each specific service. Our aim here was to build
>> primitive operation which could be used to build many services,
>> without every party knowing the service. Just the invoker needs to
>> know how to map the services into protocol primitives.
>
>  Yes, but there are two actors here.  The sender of the REFER (who
>knows the service it wants to provide) and the receiver of the REFER
>(who doesn't).  At least in this example, if we knew that the sender
>really needed the call to stay up after the REFER completes, then we
>could at least reject the REFER.

i think that is a very slippery slope.  i won't go there.

thanks,
-rohan

>-- 
>Billy Biggs, 3Com               Email: [email-masked]
>http://www.div8.net/billy/      Phone: [email-masked]
>
>_______________________________________________
>SIP mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 5 Dec 2000 13:11:49 -0500

Billy raises some very important issues. These are some of the things that
motivated a thread on the list many months back (on the road now and can't
dig up the reference), where we discussed adding control functionality to
SIP, and how this was insufficient for a full blown control and monitoring
protocol like megaco.

As Billy rightly observes, sending a refer for a sip URL with a BYE method
makes a lot of assumptions about how its processed in the recipient. It is
assuming that the UA matches the BYE with an existing call leg, it assumes
tags are handled, it assumes the UA is willing to accept REFERs with BYE,
and so on, as he has pointed out. 

The simple fact is, SIP is a poor control protocol. If people want a real
protocol that can adequately remote control a phone, thats a totally
separate thing, with different primitives and communication requirements and
security implications. I believe SIP is entirely inadequate for such a job.

REFER was a sort-of-compromise; it introduced a little bit of control into
SIP. It was enough to do a bunch of simple things (call transfer
specifically), and as such its a nice primitive for building services. But,
I believe it is inadequate for a complete control protocol. Thus, I share
Billy's concerns about using it to hang up existing calls, among other
things.

We should probably add text to REFER that is explicit about the requirements
(and non-requirements) for processing REFER at the recipient. 

Flame away.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Thu, 7 Dec 2000 04:13:28 -0800

-----Original Message-----
From: Rohan Mahy
To: Jonathan Rosenberg; Billy Biggs; Alan Johnston
Cc: Robert Sparks; Jonathan Rosenberg; SIP List
Sent: 12/6/00 1:45 PM
Subject: RE: [SIP] Music on Hold in ietf-sip-service-examples-00

>SIP, and how this was insufficient for a full blown control and
monitoring

We need to keep the distinction between MEGACO-style control, and what
we
need.  
1) SIP uses requests, which the UAS can decline.
2) SIP abstracts away the user interface of the UA away from the
verbs/methods used to do useful things.

We need to request that call legs move around to include certain users.
we
*don't* need to be notified when someone presses "hookflash"; and we
*don't* need to tell the UA exactly how to write something on a display
(that may not even exist).

This following thought occurred to me reading the comment made above
("display may not even exist").....
Does this  mean to say that one cannot support simple features like call
transfer, or even providing music on hold just because I happen to have a
phone that does not support a display? As I understand, a REFER has to be
approved of by the end user, and in the absence of a display, I can't think
of other mechanisms to use to obtain such approval(unless some auto-approval
mechanisms are already present which I must admit I am not aware of)... Just
a thought... any clarifications to provide some inputs here would be greatly
helpful.

>tags are handled, 

yes, the examples make a lot of assumpions.  i don't think it is really
such a big deal to codify this kind of behavior in some IETF document.
then we can stop making assumptions about the semantics, and then we can
make a lot of cool things work.

the problem that i think is more significant is the retransmission
problem
that motivated Billy's REFERDONE method.

>it assumes the UA is willing to accept REFERs with BYE,

actually the UAC just _requests_ a REFER w/ BYE; the UAS is free to
decline
that request.

>security implications. I believe SIP is entirely inadequate for such a
job.

I disagree.  whatever this set of "control request" primitives is, it
needs
to follow the same path as the SIP signalling, and it needs to interact
with the SIP security and policy rules, etc. etc.  It seems logical that
these primitives are indeed SIP messages.

PHONECTL (while a reasonable stab at its problem set) currently assumes
shared secrets between the controller and the phone (won't work for a
Guest
phone in my lobby), will need separate firewall treatment, and can't
easily
particpate in the mobile roaming aspects of SIP which are so nice.

I believe that REFER with some additional semantic definition, is
adequate
for this job.  

>Billy's concerns about using it to hang up existing calls, among other

<soapbox>
We've been pussy-footing around the nut of the call control problem for
over a year now. If we ever want to get better-than-PSTN call-control
services in a SIP environment, we need to define powerful, generic
primitives now.  
</soapbox>

>(and non-requirements) for processing REFER at the recipient. 
likewise ;-)

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 07 Dec 2000 09:00:48 -0800

>a thought... any clarifications to provide some inputs here would be greatly

A SIP UA could use an auto-approval or pre-approval technique, or could
play a wav file requesting authorization, or, or...  SIP allows for this
type of abstraction.  MEGACO does not.  that's all.

thanks,
-rohan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 10 Dec 2000 18:39:48 -0500

> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Wednesday, December 06, 2000 4:45 PM
> We need to keep the distinction between MEGACO-style control, 
> and what we
> need.  

Indeed. This is precisely my point. The problem is that since REFER is just
a primitive, there is no easy way for the user to determine the ultimate
service being invoked. So, while the user can be queried about whether to
accept a REFER request, what would a typical user respond to when asked "you
are being requested to send a re-INVITE within call A to add a media line
with a new address"? They'll reject it since they have no idea what it
means. Any sensible UA would likely reject any REFER thats not for an IVNITE
request received as part of an existing call. 

> We need to request that call legs move around to include 
> certain users.  we

You are oversimplifying the way in which this equates to megaco.

Seems like what some people want is a signaling level control protocol. Such
a protocol would not report hookflash or allow for control of displays;
thats a device level control ala megaco. Signaling level control would allow
me to instruct another device to send signaling messages of any type at any
time. The feedback would tell me what responses were received to those
requests, and what the resulting call level states where. Rohans two drafts
(3pcc with REFER and feedback with 189) seem to be attempting to do exactly
that.

Now, my point is, that even though this control is at a higher level, its
still a control protocol nonetheless. It has the same issues with
transactional integrity (several REFERS may need to succeed all together)
and security as megaco has. I would argue that for things like this, forking
is anathema. Do you really want these REFERs to go all over the place? No.
You want a direct channel, from one entity to the controlled entity.

All of this is what SIP is not very good at. This is my point.

-Jonathan R.
---