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

From: Billy Biggs <[email-masked]>
Date: Wed, 29 Nov 2000 11:09:44 -0600

In sip-service-examples-00, you discuss performing music on hold using
REFER.  A shortened call flow is below:

  On hold:

         User A        User B       Music Server
          |              |              |
          |   REFER Refer-To: sip:[email-masked]
          |<-------------|              |
          | INVITE/200 OK/ACK           |
          |<--------------------------->|
          |  200 OK      |              |
          |------------->|              |
          |              |              |

  Off hold:

          |              |              |
          |   REFER Refer-To: [email-masked];method=BYE
          |<-------------|              |
          |  BYE/200 OK  |              |
          |<--------------------------->|
          |  200 OK      |              |
          |------------->|              |
          |              |              |

  I have two problems with this method:

  1. In our implementation, User A will hang up the call to User B after
     the REFER completes successfully.  This is to protect ourselves
     (User B will also send a BYE), however, I can imagine most
     implementations will be similar.

  2. As mentioned in my previous email on remote device control using
     REFER, the URI [email-masked];method=BYE is insufficient to
     indicate to the UA which call should be disconnected.  It's also
     overloading REFER and obfuscating its meaning.

  There are more appropriate ways to implement music on hold.  One is to
have User B call up the music server itself and swap the SDP (3pcc).
Another is to have User A call up the music on hold server when it
receives on-hold SDP.

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

---

From: Alan Johnston <[email-masked]>
Date: Wed, 29 Nov 2000 14:04:40 -0600

Billy,

So your interpretation of the REFER request is that a successful completion
of the request always automatically generates a BYE request?  I'd be
interested to hear if other implementors have made this assumption as well.

This seems to me like mixing a service with the primitive used to implement
the service.

I thought this was why the original name of the method was changed from
TRANSFER (which is the name of a service and does imply a disconnect after
successful completion) 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.

Is your proposal for Music On Hold  for User B to proxy media from the Music
On Hold Server, or is it to send a re-INVITE to User A using SDP from the
Music On Hold Server?  Your other approach is for User A to choose its own
Music On Hold server without assistance from User B?

I'm always interested in seeing new call flows, but I'm not sure that these
are better approaches.

Thanks,
Alan.

---

From: Billy Biggs <[email-masked]>
Date: Wed, 29 Nov 2000 15:49:45 -0600

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

  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.

  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.

> Is your proposal for Music On Hold  for User B to proxy media from the
> Music On Hold Server, or is it to send a re-INVITE to User A using SDP
> from the Music On Hold Server?  Your other approach is for User A to
> choose its own Music On Hold server without assistance from User B?

  As with most telephony features and SIP, there are many options.  It
is up to the implementor to pick one.  My problem with your Music on
Hold proposal is that it isn't interoperability-friendly.