Subject: [Sip] Application identification with callee caps/caller preferences

From: [email-masked]
Date: Tue, 27 Apr 2004 10:38:49 +0300

Hi, I have a question on following scenario. 

The user Y has two games installed Chess (named x-chess) and Othello (named x-othello). The caller X has the equivalent chess-game (x-chess) and would like to use SIP to invite Y for a game. 
Is the following approach correct according to the callee caps/caller preferences specs? Namely is it correct to use the 'type' media feature tag in this way. In practice here the 'type' tag identifies the application and on the other hand defines also the media capability of the UA (since the x-chess in this case might use whatever "gaming-protocol" as media stream).

The callee Y would generate a registration which looks like, in part:

For the Chess game:

REGISTER sip:example.com SIP/2.0
   To: sip:[email-masked]
   Contact: sip:[email-masked]
     ;type="application/x-chess"

For the Othello game:

REGISTER sip:example.com SIP/2.0
   To: sip:[email-masked]
   Contact: sip:[email-masked]
     ;type="application/x-othello"

Now when the caller X wants to play x-chess it would express its' preference by generating an INVITE which looks like, in part:

INVITE sip:[email-masked] SIP/2.0
   From: sip:[email-masked]
   To: sip:[email-masked]
   Accept-Contact: *;type="application/x-chess";require;explicit

Best Regards,
Jari

_______________________________________________
Sip mailing list  https://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: David Oran <[email-masked]>
Date: Tue, 27 Apr 2004 09:48:22 -0400

This seems a bit of a stretch for callee caps. What bothers me is the 
notion i that you want to play a game with somebody, and which game is 
determined by a preference matching scheme. I suppose there's nothing 
horrible in that - it just strikes me as weird.

I would think that you would be more likely to choose the combination of 
participant+game through addressing, such as by having multiple 
registrations of the form

sip:[email-masked] and sip:[email-masked]

This has the additional benefit of not requiring a registry for game names.

Dave.

--On Tuesday, April 27, 2004 10:38 AM +0300 [email-masked] wrote:

> The user Y has two games installed Chess (named x-chess) and Othello
> (named x-othello). The caller X has the equivalent chess-game (x-chess)
> and would like to use SIP to invite Y for a game.  Is the following
> approach correct according to the callee caps/caller preferences specs?
> Namely is it correct to use the 'type' media feature tag in this way. In
> practice here the 'type' tag identifies the application and on the other
> hand defines also the media capability of the UA (since the x-chess in
> this case might use whatever "gaming-protocol" as media stream).
>
> Now when the caller X wants to play x-chess it would express its'
> preference by generating an INVITE which looks like, in part:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Apr 2004 11:51:06 -0400

I think what is proposed is quite reasonable. Given that the game is 
defined by the type of media stream used to interact, the simplest 
approach is simply to send an INVITE to the AoR, offering the desired 
kind of media stream and not bothering with callerprefs at all. In that 
case the invite would be forked to all the callee's devices. Presumably 
those that couldn't handle the media type would refuse the call, and any 
that so support it and are available might respond with a 180.

Using callerprefs here is possibly a slight optimization, especially in 
case the proxy were to try serial forking. And it is also insurance 
against devices that might accept the call while refusing the media.

This would be more important if you want two streams - one for the game 
and another for voice. If you simply offer both then you run a real risk 
that an audio phone might accept the call and refuse the game stream.

Of course it is also possible to use separate addresses for the games. 
But that might be inconvenient, and limiting if the game console also 
does voice and/or video.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Apr 2004 11:02:35 -0500

> This has the additional benefit of not requiring a registry for game names.

This alternative has the additional disadvantage of either not resolving 
through any proxy/registrar that I know of, or of requiring a seperate 
REGISTER message and authentication transacation for each client-game 
combination (not to mention account creation). Suppose I had three 
hundred games on my PDA . . .

Use of a preference/capability tag for a "chess" call gets routed to a 
machine with that game is just as reasonable as using pref/cap matching 
to make sure a "video" call request gets routed to a display device with 
a camera and sound.

Of course, I'm still deeply confused between:
1) preference/capability negotiation enabled by offer/answer
2) preference/capability negotiation enabled by callee-caps/caller-pref.

The issue of having a huge registry of names seems to be valid, however.

Options that come to mind:

1) Non-registered "user capability" sub-tags
2) More SDP extensions . . . we're really describing the session we 
want, not the capabilities of the target.
3) URI parameters, anybody?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Apr 2004 13:21:11 -0400

> 2) preference/capability negotiation enabled by callee-caps/caller-pref.

See my earlier reply.

Forking and offer/answer provide a partial solution. But offer/answer 
doesn't give you a way to say you don't want the call unless your 
offered media are accepted. At least not an easy way. Conceivably some 
new extension to preconditions could be made to handle this kind of 
thing. Lacking that you run the risk of having an unsuitable device 
answer, even if there is a suitable device present.

Callerprefs gives you an increased likelihood that you will end up with 
a suitable device.

> The issue of having a huge registry of names seems to be valid, however.

I don't see how you can avoid that, one way or another. If you are going 
to set up the session with sip, then there needs to be some media 
stream. If the media stream protocol is game dependent then it needs to 
be registered somehow to be referenced in an m-line.

I suppose the alternative is some generic game protocol. But I doubt 
that would fly, and even if it did, you would still have to discover 
somehow what games you had in common, and pick one.

> 3) URI parameters, anybody?

These really are capabilities. But you don't necessarily always enable 
all your capabilities, and so perhaps don't offer them all by default. 
This is a relatively new concept in practice, since practically speaking 
most sip devices today only do voice. (I'll bet that video phones aren't 
always going to want to offer video - there will probably be a button 
that turns that on/off.)

If there are a *lot* of supported game protocols, and you just want to 
dynamically choose one that both ends support, then I think you will 
need a separate way of negotiating that. Maybe you simply establish an 
MSRP IM session, discuss what game to play, and then reinvite with an 
offer that adds a stream for the chosen game. Of course, if you started 
out with IM, the other party might not be IMing from a game console. But 
that should simply be a matter of him first transferring his end of the 
call to the game console before gaming begins. E.g.

- Alice, from game console, opens IM session with Bob
- IM session is established on Bob's PC.
- Alice sends message to Bob espressing an interest in playing game.
- They discuss what game to play. Decide on Doom.
- Bob transfers the IM session to his X-Box so he has the good
   audio, TV screen, and game controllers. (This could also be
   done by conferencing in the X-Box.)
- Alice sends reinvite, adding a Doom media session. This goes
   to Bob's X-Box. Now have both Doom and IM.
- They play ...

Other possibilities:

- simply send invite with a separate m-line for each supported game, 
using ALT to say they are mutually exclusive.

- publish presence, listing all the types (including games) supported. 
Then watcher can choose which of those to offer when calling.

	Paul