Subject: Re: [Sipping] I-DAction:draft-ietf-sipping-service-identification-01.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jul 2008 11:07:39 -0400

I thought I had responded to this a while back but apparently had not. 
Comments below:

Christer Holmberg wrote:
>  
> Hi,
> 
> To progress the work in a constructive way I have some comments on
> things which I still think are missing from the draft.
> 
> 
> Q1:
> ---
> 
> About dispatching to the approriate application, it is assumed that the
> MSRP content etc is going to indicate e.g. what game you want to use
> etc.
> 
> But, one use-case I've mentioned earlier, is how to distinguish between
> a plain VoIP call and a VoIP call with specific application logic.

This is not a "use case" Christer. What do you mean by "specific 
application logic"? Give a real-world example of something specific a 
user wants to do, and the specific functions provided by this 
application server.

Tolga had provided an example use case, perhaps this is what you mean. 
In his use case, users A and B are playing a game. The game utilizes 
audio. However, the game moves and game signaling are handled by a game 
server and this might not even be SIP based; or if it is, its a 
completely separate SIP session. Thus, the companion audio has a single 
m-line for audio, and it otherwise looks just like a voice call. 
However, we don't want to invoke call features like screening or 
forwarding to voicemail for this voice call.

My response to this, was that in such a case the 'voice call' is really 
targeted to a service on the device, and not to the user. Thus, what 
should happen is that the game server allows the calling party to 
determine a URI for companion voice, which looks something like:

sip:[email-masked];gr=asd88g7xapqpw9e77==asd

this URI, being constructed by example.com, would get appropriate 
treatment when called.

I plan on working this into the next revision of the document.

> 
> Another use-case is when you have multiple games which are controlled
> using simple DTMF, ie there is no MSRP etc.

I think this is a lot like the example above; in this case you are not 
initiating a session to bob, you are initiating a session to a service 
on his device and you need to determine a URI for it. You need to do 
that anyway - how would a calling party even know that this game is 
something he can do with the called party?

> 
> 
> Q2:
> ---
> 
> Related to the previous comment, the draft says "look at the SDP and
> you'll find the correct application". But, the draft does not cover the
> case where the SDP you are looking at does not contain all the
> information I may want to use during the session. For example, I may
> start with voice, but I want to reach an application which allows me to
> later add e.g. video, messaging - and certain application logic
> associated to those.

You can add video later by signaling without an application server. You 
need to be specific here - what kind of 'application logic' do you want 
to see applied and in what cases is it wrong?

> 
> Q3:
> ---
> 
> The draft focuses very much on how the receiving terminal is able to
> dispatch an incoming message to the approriate application, but one
> thing which the service id is used for is for finding an appropriate
> terminal in the first place, ie forking.

This is covered in section 4.7.

> In this case it is not about
> finding the correct application inside the terminal, or to figure out
> what the calling party wants to do, but to find a terminal which
> supports a number of capabilities in the first place. Some of these
> capabilites can be registered using feature tags, e.g. whether the
> terminal supports audio, video. But, a service "profile" can contain
> much more than that: supported codecs, supported transport mechanisms,
> supported security mechanisms, supported application logic (games,
> supplementary services etc etc etc) etc etc etc. So, instead of
> registering all those things separately, a profile service
> identification is used instead. That does NOT prevent requests from
> users that do not upport it to reach those terminals - it's all about
> how the Accept-Contact header in such requests look like.

There is nothing wrong with defining new accept-contact tags that are 
combinations of existing or new ones, as a syntactic optimization of 
sorts. The thing thats important is to make sure that the matching 
algorithm is done by expanding these to their component parts and THEN 
doing the matching operation; this allows for things to work in 
environments where the same profile is not known to the originating party.

That said, I don't see a lot of benefit in such combined tags. Why is it 
such a problem to include five tags in a register instead of one?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

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