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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 30 Nov 2000 00:34:44 -0500

> -----Original Message-----
> From: Billy Biggs [mailto:[email-masked]]
> Sent: Wednesday, November 29, 2000 4:50 PM
> To: Alan Johnston
> Cc: Robert Sparks; SIP List
> Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00
> 
> 
> Alan Johnston ([email-masked]):
> 
> > So your interpretation of the REFER request is that a successful
> > completion of the request always automatically generates a BYE
> > request?
> 
>   Implementation not interpretation.
> 
> > [...] to REFER, which can be used to implement a transfer 
> service, but
> > just has the semantic to request establishment of a new session
> > without affecting the existing session.
> 
>   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.

As Alan correctly pointed out, REFER has other applications beyyond
transfer. Assuming that everytime the device sends a REFER, its a transfer,
is both an incorrect interpretation and an incorrect implementation. Now, it
may be that when a user presses "transfer" on your phone, it sends a REFER
then a BYE. Thats fine; in this flow here, the user would not press
"transfer", since this is not a transfer service. 

> 
>   Yes, we are using REFER to implement transfer.  If there 
> are seperate
> requirements, such as requesting to add a user in a 3-way call, or
> asking the remote phone to dial another user seperately and be able to
> remotely control the call, then these should be seperate 
> methods or with
> a Requires or something.  PHONECTL was designed (and 
> implemented) to do
> much of this, with an appropriate authentication structure.

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

-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

---

From: Billy Biggs <[email-masked]>
Date: Thu, 30 Nov 2000 00:14:36 -0600

Jonathan Rosenberg ([email-masked]):

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

  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.

  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.

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

-- 
Billy Biggs, 3Com               Email: [email-masked]
http://www.div8.net/billy/      Phone: [email-masked]

---

From: "Robert Sparks" <[email-masked]>
Date: Thu, 30 Nov 2000 09:29:59 -0600

> primitive is "initiate a session with the Refer-To address".

Actually, it's do whatever makes sense in your UA for the URL.
Keep in mind that non-SIP URLs are valid here. 

> won't be able to handle, but I'm not worried yet.

What crazy logic? Building the request based on the method parameter and
possibly header parameter in the URL?

---

From: Billy Biggs <[email-masked]>
Date: Thu, 30 Nov 2000 10:03:43 -0600

Robert Sparks ([email-masked]):

>>   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.
> 
> What crazy logic? Building the request based on the method parameter
> and possibly header parameter in the URL? 

  I assume you want the BYE to be associated with the music call.
Otherwise, that BYE would be sent with a new From tag and no To tag (a
new call leg), and would not end the old call.

  Aside from that matching, there are also security implications of
being able to tell a UA to send any SIP request, especially a BYE.  I
don't want a remote UA to tell me to hang up a call.  So if some service
requires this, then we have to do some logic to see if the user
previously asked us to make a call such that we would allow them to send
a BYE for it.  Ugh.

  So, our security is simple:

  - Remote UA must have a call active to us (no out-of-call REFERs).
  - We will only allow REFERs which ask us to INVITE.
  - We will only allow being REFERed once (REFER is at the cost of the
    old session).

  More priviledges are available through something stronger (PHONECTL),
which requires authentication.

---

From: "Robert Sparks" <[email-masked]>
Date: Thu, 30 Nov 2000 10:13:15 -0600

> Sent: Thursday, November 30, 2000 10:04 AM
> To: Robert Sparks
> Cc: Jonathan Rosenberg; Alan Johnston; SIP List

Hence To: and From: headers in the URL.

> previously asked us to make a call such that we would allow them to send

So your UA has a policy to always 503 sip: BYE URLs. 

> which requires authentication.

You could require that your REFERs be SIP authenticated.

---

From: Billy Biggs <[email-masked]>
Date: Thu, 30 Nov 2000 10:47:11 -0600

Robert Sparks ([email-masked]):

>> Otherwise, that BYE would be sent with a new From tag and no To tag
>> (a new call leg), and would not end the old call.
> 

  How can the referrer know what tag the far-end UA used?  As well,
using the supplied to/from is another security no-no.

  REFER should not be a control protocol.  It does not supply enough
information to properly orchestrate these operations.  If you need this
sort of functionality, let's keep it seperate, like PHONECTL.

>> don't want a remote UA to tell me to hang up a call.  So if some
>> service requires this, then we have to do some logic to see if the
>> user previously asked us to make a call such that we would allow them
>> to send a BYE for it.  Ugh.
> 

  Right now we treat everything as an INVITE, but the plan would be to
send a 403.

>>   - We will only allow being REFERed once (REFER is at the cost of
>>     the old session).
>> 
>>   More priviledges are available through something stronger
>> (PHONECTL), which requires authentication.
> 

  Which would be the same as PHONECTL.  The remote UA needs to know the
phone's password to to do remote phone control operations.

  It doesn't seem reasonable for me to tell my phone's password to
everyone who wants to play me music-on-hold.