Subject: [Sip] re: refer-to header

From: Rohan Mahy <[email-masked]>
Date: Sun, 02 Dec 2001 09:51:15 -0800

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