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

From: Robert Sparks <[email-masked]>
Date: Sun, 2 Dec 2001 17:09:40 -0500

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

---

From: "Dean Willis" <[email-masked]>
Date: Sun, 2 Dec 2001 16:48:24 -0600

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]

(or maybe not even need seperate listsing)

because my proxy should be smart enough to route Quake invites (remember,
it's in the BODY of the INVITE) to my quakebot and not to my phone.

But hey, if my phone can handle Quake, maybe my proxy will route it there .
. . cool phone.

--
Dean