Subject: [Sip] Refer-To header and method-param

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 29 Nov 2001 11:37:47 +0200

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.

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?

Regards,
Hisham
www.hotsip.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

---

From: Robert Sparks <[email-masked]>
Date: Thu, 29 Nov 2001 12:25:57 -0500

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

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

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

---

From: "Sriram Parameswar" <[email-masked]>
Date: Thu, 29 Nov 2001 13:22:15 -0600

Some time ago Aaron Lo had suggested on this list that possibly the REFER
should contain SDP which is suggestion of the session that could be created
between Transferee and Transfer Target. That thread went no-where - a quick
re-visit?

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-685-3563
Nortel Networks, Richardson USA  Email: [email-masked]

-----Original Message-----
From: Hisham Khartabil [mailto:[email-masked]]
Sent: Thursday, November 29, 2001 3:38 AM
To: sip
Subject: [Sip] Refer-To header and method-param

Hi,

E.g.

Regards,
Hisham
www.hotsip.com