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

From: Rohan Mahy <[email-masked]>
Date: Wed, 06 Dec 2000 13:45:25 -0800

At 10:11 AM 12/5/00 , Jonathan Rosenberg wrote:
>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.

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

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

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.

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

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.  

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

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

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

thanks,
-rohan

>-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
> 
>
>_______________________________________________
>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: Henry Sinnreich <[email-masked]>
Date: Thu, 07 Dec 2000 22:01:59 -0600

>full blown control and monitoring
>protocol like megaco.

Agree here completely with Rohan Mahy
>*don't* need to be notified when someone presses "hook flash"; and we
<start soapbox>
and propose we face the facts why device control protocols are a poor
engineering option:
Device control protocols can be found in proprietary IP PBX designs and also
in various proposed standards, such as MEGACO and H.248. Device control
protocols are master-slave protocols where every detail of the device
operation is controlled from a central server. In this model, every event,
such as a hook flash has to be reported to the central controller and every
action of the device has to be controlled, such as how to display a number,
or a message.
How does the controller know if the device has a display at all? The answer
is, it does not know, unless it has been pre-configured with a so-called
"package" that is written for that particular device, such as for example
for specific phone model that may or may not have a display with certain
capabilities. In the case of Media Gateways, "packages" have to be written
and provisioned depending on the particular circuit switch network signaling
of the Media gateway, such as channel associated signaling (CAS), Q.931, SS7
in its various flavors, etc. This is in stark contrast to the Internet
model, where the same protocol is used, without caring if at the other end
is a palmtop computer or a powerful server farm in a data center. For
example when using FTP, e-mail or browsers, no consideration has to be given
how the remote IP device is configured. Where different capabilities, such
as codecs for voice and video have to be coordinated for real time
communications, a capability negotiation takes place. Device control
protocols have no notion of capability negotiation.
</soapbox>

likewise ;-)

Henry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Rohan Mahy
Sent: Wednesday, December 06, 2000 3:45 PM
To: Jonathan Rosenberg; Billy Biggs; Alan Johnston
Cc: Robert Sparks; Jonathan Rosenberg; SIP List
Subject: RE: [SIP] Music on Hold in ietf-sip-service-examples-00

<soapbox>

likewise ;-)

thanks,
-rohan