Subject: Re: [Sip] re: refer-to header

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 05 Jan 2002 01:53:51 -0500

Robert Sparks wrote:

> inline
> 
> 
>>-----Original Message-----
>>From: Dean Willis [mailto:[email-masked]]
>>Sent: Sunday, December 02, 2001 4:48 PM
>>To: Robert Sparks; 'Rohan Mahy'; [email-masked]
>>Subject: Re: [Sip] re: refer-to header
>>
>>
>>How does one distinguish an HTTP URL that enters a sex site 
>>from one that
>>retrieves info on a Disney character? I recall that there was some
>>excitement a few years ago when http://www.bambi.com/ 
>>retrieved information
>>on "wild life" not usually considered suitable for children . . .
>>
>>In  short, the URL is just an entry point. How that entry 
>>point responds is
>>up to the application behind it. This is not a standardizable 
>>thing. The
>>application MAY base its response on the parametrs of the 
>>request as well as
>>on the body of the request.
>>
>>In the case posed by Robert, my business card might say:
>>
>>Voice: sip:[email-masked]
>>Quake: sip:[email-masked]
>>
>>Or, it might say:
>>
>>Voice: sip:[email-masked]
>>Quake: sip:[email-masked]
>>
> 
> If you do this and you put these on a web page, not
> a business card, how does your web browser know which
> application to launch to generate the associated INVITE?

We are back to one of the big sipping questions, I believe. How do we 
construct URIs to explicitly invoke services, without standardizing the 
services?

The answers remain the same. If the URI is handed out (i.e., its on a 
business card), thats when things are best. I can pick whatever URL I 
like to be the URL to invoke Quake with. Presumably, a user would type 
this URL into their quake app, and things work. Should they type it into 
their voip-only SIP phone, they get back a 488 that tells them this is 
for quake only.

The REFER issue is harder. If A is in a call with B, and wants to REFER 
C to B in order to have them play quake, now were are in a situation 
where A needs to know the URL to use at A to invoke a particular 
service. This is a hard, hard problem. I had, in the past, proposed 
including these URLS in INVITE/200, for the particular case of conferencing:

INVITE sip:B SIP/2.0
To-Join: sip:[email-masked]

Dave Oran asked what URL to use for "blow up my phone", and now we are 
asked for the URL for "play quake". The variations are infinite. When a 
URL is not handed out, and must be constructed, we are talking about the 
old service invocation problem.... I have some ideas on it, but they are 
not gelled enough for a post.

-Jonathan R.

>>----- Original Message -----
>>From: "Robert Sparks" <[email-masked]>
>>To: "'Rohan Mahy'" <[email-masked]>; <[email-masked]>
>>Sent: Sunday, December 02, 2001 4:09 PM
>>Subject: RE: [Sip] re: refer-to header
>>
>>
>>
>>>Casting it back to what I put on a business card/web page,
>>>how would I distinguish the URL used to enter a quake game
>>>with me from the one used to enter a chess game?
>>>
>>>RjS
>>>
>>>
>>>>-----Original Message-----
>>>>From: Rohan Mahy [mailto:[email-masked]]
>>>>Sent: Sunday, December 02, 2001 11:51 AM
>>>>To: [email-masked]
>>>>Subject: [Sip] re: refer-to header
>>>>
>>>>
>>>>Hi,
>>>>
>>>>I think the "right way" to distingish a "voice" INVITE from a
>>>>"game" INVITE
>>>>is with the caller preferences extensions.
>>>>
>>>>for example:
>>>>
>>>>Refer-To:
>>>><sip:[email-masked]?Accept-Contact=*;media="application/game">
>>>>
>>>>
>>>> >To: "'Hisham Khartabil'" <[email-masked]>, 
>>>>
>>[email-masked]
>>
>>>> >Subject: RE: [Sip] Refer-To header and method-param
>>>> >From: Robert Sparks <[email-masked]>
>>>> >Date: Thu, 29 Nov 2001 12:25:57 -0500
>>>> >List-Id: Session Initiation Protocol <sip.ietf.org>
>>>> >Sender: [email-masked] > -----Original Message-----
>>>> >> From: Hisham Khartabil [mailto:[email-masked]]
>>>> >> Sent: Thursday, November 29, 2001 3:38 AM
>>>> >> To: [email-masked]
>>>> >> Subject: [Sip] Refer-To header and method-param
>>>> >>
>>>> >>
>>>> >> Hi,
>>>> >>
>>>> >> Section 3.5.1 of draft-ietf-sip-refer-02 states:
>>>> >>
>>>> >>    "The resource identified by the Refer-To: URL is contacted
>>>> >> using the
>>>> >>    normal mechanisms for that URL type.  For example, if
>>>>the URL is a
>>>> >>    SIP INVITE URL, the UA would issue a new INVITE using
>>>>all of the
>>>> >>    normal rules for sending an INVITE defined in [1]."
>>>> >>
>>>> >> My question is: How can I determine is the URL is indeed an
>>>> >> INVITE URL? What
>>>> >> does an "INVITE URL" mean?
>>>> >>
>>>> >> The only thing I can relate to this is the method-param
>>>>in a SIP URL.
>>>> >Which is exactly the thing. INVITE is the default value of
>>>>that method
>>>> >parameter. so sip:[email-masked] and
>>>>sip:[email-masked];method=INVITE are INVITE
>>>> >URIs. sip:[email-masked];method=SUBSCRIBE is a SUBSCRIBE URI >
>>>> >> The other question is: If a UAC has the capabilities to REFER
>>>> >> someone to a
>>>> >> voice session as well as some other session like a Game
>>>> >> session. How does it
>>>> >> tell the referee what type of INVITE it is.
>>>> >>
>>>> >> E.g.
>>>> >>
>>>> >> - A is in a voice session with B
>>>> >> - A is in a game session with C
>>>> >> - A wants to refer D to join the voice with B and game with
>>>> >> C. How would the
>>>> >> Refer-To header differ in that scenario? This is a good
>>>>question, but its
>>>> >not REFER specific. To put it another way, suppose you want
>>>>to put a URI that
>>>> >someone can use to join your game on a business card or
>>>> >on a web page. What does it look like? I've heard a number
>>>>of possible
>>>> >answers for this
>>>> >(and I don't claim this is an exhaustive list) 1) The game
>>>>URI looks exactly
>>>> >like the voice URI, but you
>>>> >   use different clients to play games and have voice
>>>> >   conversations, so the intent is inferred from which
>>>> >   client you handed the URI too.      This has tons of
>>>>problems, starting
>>>> >with the assumption
>>>> >     of different clients. 2) The URIs look exactly the
>>>>same, and agents
>>>> >always include
>>>> >   every kind of session they support in every offer.
>>>>Think of video vs
>>>> >audio for a minute. How do you know from
>>>> >     a SIP URI on a business card that someone supports both?
>>>> >     The discussion I've heard to date indicates that 
>>>>
>>you don't -
>>
>>>> >     you just include a video m= line if you want to use it and
>>>> >     if the other side supports it, great! You could take the
>>>> >     same approach with game streams. The downside of 
>>>>
>>this is that
>>
>>>> >     D above may end up in both a voice and game session (think
>>>> >     voice and video if you think that's bad) with C. 
>>>>
>>Now if D is
>>
>>>> >     joining an existing dialog at C (which is managing only a
>>>> >     game session), C can just decline the voice part of
>>>>the offer.      The
>>>> >downside with this approach is having to include an offer
>>>> >     for everything you support - resource acquisition 
>>>>
>>at the client
>>
>>>> >     may be prohibitive, and the messaging can get huge. What if
>>>> >     you support 30 different games? Are those games only
>>>>distinguished
>>>> >     by SDP? Do you have 30 sets of m= lines in your 
>>>>
>>offer matching
>>
>>>> >     them? 3) The URIs differ by some parameter, header, or
>>>>body content.
>>>> >  This path has the most promise, but there needs to be
>>>> >     much discussion about what the difference is. The examples
>>>> >     of games sessions we've seen before use INVITEs that differ
>>>> >     only in their SDP - do we include SDP or some subset of it
>>>> >     in the URI? That way is filled with security and interop
>>>> >     peril.
>>>> >
>>>> >4) You just have a different URI for games, video and
>>>>voice.      This is a
>>>> >workaround - not a solution.
>>>>
>>>>
>>>>_______________________________________________
>>>>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>>>>This list is for NEW development of the core SIP Protocol
>>>>Use [email-masked] for questions on current sip
>>>>Use [email-masked] for new developments on the 
>>>>
>>application of sip
>>
>>>_______________________________________________
>>>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>>>This list is for NEW development of the core SIP Protocol
>>>Use [email-masked] for questions on current sip
>>>Use [email-masked] for new developments on the application of sip
>>>
>>>
>>>
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip