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

From: Alan Johnston <[email-masked]>
Date: Mon, 04 Dec 2000 12:53:22 -0600

I'm still trying to understand the implementation issues here.  See my
comments below.

Alan Johnston

Billy Biggs wrote:

> 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.
> >
> > Hence To: and From: headers in the URL.
>
>   How can the referrer know what tag the far-end UA used?  As well,
> using the supplied to/from is another security no-no.

I don't understand this.  If I send you a REFER to a URL which you complete,
then I send a REFER with the same URL but with method=BYE, then I am
requesting that you disconnect whatever session(s) you established as a
result of my original REFER.  If your referred INVITE was somehow forked
(stereo Music On Hold?) and resulted in two sessions, then the BYE would
refer to both sessions. Tags don't come into the picture.  Kind of like tags
and CANCEL requests - when I send a CANCEL, it means cancel all pending
requests - I don't need to know the tags.

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

You seem to be treating REFER like an automatic redirection response, which
it is not.  Your phone should never automatically process a REFER request
without confirmation from the user. Even your web browser alerts you if you
get a HTTP redirect.  The user will know if a REFER is imminent when the
other party on the call says something like "I'm going to try to transfer
you" or "I'm putting you on hold, you can have music if you want".  If a
REFER arrives out of the blue, the one party says to the other "What's up -
are you trying to transfer me?" before they confirm their acceptance.

>
> >>   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 your UA has a policy to always 503 sip: BYE URLs.
>
>   Right now we treat everything as an INVITE, but the plan would be to
> send a 403.
>
> >>   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.
> >
> > You could require that your REFERs be SIP authenticated.
>
>   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.

It's not reasonable, since REFER is a request, not a command.  The user can
reject the REFER and just get silence instead.  Or, the user can accept the
request and get the music.  If the music is not to the user's taste, they
can disconnect.  This call flow gives the user the choice of music or not.

>
>
> --
> 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: Billy Biggs <[email-masked]>
Date: Mon, 4 Dec 2000 14:16:22 -0600

I'm really glad you've made these comments.  They help to raise
awareness of these issues.

Alan Johnston ([email-masked]):

> I don't understand this.  If I send you a REFER to a URL which you
> complete, then I send a REFER with the same URL but with method=BYE,
> then I am requesting that you disconnect whatever session(s) you
> established as a result of my original REFER.

  You're saying that the device has to match the BYE with the old call.
This is definitely special (and difficult) logic for handling of a
method=BYE REFER.

> If your referred INVITE was somehow forked (stereo Music On Hold?) and
> resulted in two sessions, then the BYE would refer to both sessions.
> Tags don't come into the picture.  Kind of like tags and CANCEL
> requests - when I send a CANCEL, it means cancel all pending requests
> - I don't need to know the tags.

  REFER Refer-To: [email-masked]

     spawns -> INVITE [email-masked]
               To: [email-masked]
               From: me@localhost;tag=54321
               Call-ID: [email-masked]

  Then later I get:

  REFER Refer-To: [email-masked];method=BYE

     spawns -> BYE [email-masked]
               To: [email-masked]
               From: [email-masked];tag=73625
               Call-ID: [email-masked]

  This BYE has a new from tag and a new call-id, so it gets ignored by
the far end.

  In order to ensure we match, the REFERs MUST include both the Call-ID
and From (with a tag).  Ouch.  My implementation does not want to trust
either of those to a remote UA, especially not the From.

> You seem to be treating REFER like an automatic redirection response,
> which it is not.

  Is for me.  How else can you coordinate a smooth (instant) handoff of
a 3-way call (hangup and the two remote parties are connected), or build
a SIP-POTS line converter, or otherwise build a phone without the luxury
of a 19" monitor?

  I suspect that other implementations will be similar.

> Your phone should never automatically process a REFER request without
> confirmation from the user. Even your web browser alerts you if you
> get a HTTP redirect.

  What crazy web browser do you use?

---

From: Billy Biggs <[email-masked]>
Date: Mon, 4 Dec 2000 15:03:57 -0600

To add to my own email:

Billy Biggs wrote:

>   In order to ensure we match, the REFERs MUST include both the
> Call-ID and From (with a tag).  Ouch.  My implementation does not
> want to trust either of those to a remote UA, especially not the
> From.

  Even with specifying a Call-ID and From header for each REFER, I'm
also assuming:

  1. The remote UA will match the BYE to the ongoing call, even though
     it does not have a To-tag (this is mentioned in the spec, but I
     wouldn't count on all UAs supporting it).

  2. That you don't care about the Record-Route'ing proxies in the
     middle of the call which care very much about receiving that BYE.

  I'm sure that 2 is unacceptable to some people on this list.

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 05 Dec 2000 08:04:21 -0800

Hi,

For REFERs that deal with existing calls, there must be some way to match
against the existing calls/transactions.  Billy is assuming that you need
to explicitly state the From (with tag), Call-ID, and possibly the To.  I
always assumed that you would use the To, From, and/or Call-ID in the
Refer-To URL to match against existing calls/transactions in the most
common cases, and that you would be more specific for the corner cases.  We
need to nail down these semantics more tightly.

thanks,
-rohan