Subject: Re: [Sipping] Review of draft-ietf-sipping-service-identification-00

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 24 Feb 2008 23:30:20 -0500

Tolga,

An update of this draft is very tardy, as is a response to your review 
comments. My apologies. Comments below:

Asveren, Tolga wrote:
> Draft: draft-ietf-sipping-service-identification-00
> Reviewer: Tolga Asveren [[email-masked]]
> Review Date: 14 October 2007
> Review Deadline: 15 October 2007
> Status: Initial review
> 
> Summary: This draft is on the right track but has open issues described
> in the review
> 
> * 5.1 Application Invocation in the User Agent
> I think this is the real problem together with 5.7 Dispatch to Devices.

well, these are two of the problems. But they are all problems.

> 
> * 5.2 Application Invocation in the Network
> A specific model is assumed for the examples in this section. For
> example why can't the outbound call blocker be implemented in a way
> where it can recognize all allowed targets rather than just phone
> numbers? 

Feature interaction explosion.

> 
> * 5.3 Network Quality of Service Authorization
> I think the right way to do QoS reservation by a non-UA element is that
> UA signals this need somehow. 

This section is not talking about reservation or QoS techniques. Its 
talking about AUTHORIZATION of whatever the mechanism is.

> If the UA does not have RSVP capability or
> prefers reservation by a network entity for some other reason, this can
> be done by other means (maybe a new SIP header, or some other form of
> signaling). I also do not think that RSVP authorization should be
> service dependent. It should be based on the profile/account/balance of
> the user (user meaning the subscriber to Internet connectivity not
> subscriber to an application service) but not on a particular service.

Well, I would love for that to be so. But there are lots of examples 
where folks want to couple QoS with applications. Indeed, this is one of 
the central architectural concepts in IMS.

> 
> * 5.4 Service Authorization
> I believe this is responsibility of an AS, not of a proxy.

The document is not trying to call out the nuances of a proxy vs. an 
application server. Proxy is meant in the general sense here - a network 
box. I'll use the more general term 'server'.

> 
> * 5.5 Accounting and Billing
> Again, I don't think this is something to be done by a proxy.

See above. Proxy, b2bua, server, whatever. I mean box in the network. 
Clearly those do accounting and billing.

> 
> 5.6 Negotiation of Service
> It seems to me this is a subset of the issues described in 5.1/5.7
> rather than a separate problem.

No - it is different. This is about selecting amongst possible services, 
not sending to a client based on a specific service.

>  
> * 6.1 Gaming vs. Voice Chat
> I think the explanations provided in this section are covering a subset
> of the problem space. For example, what about the case where the moves
> for the game are sent to a centralized gaming server whereas voice is
> end-to-end between players?

The signaling would still be clear on what is happening so I don't see 
the issue.

> We would have two sessions but how could we
> make sure that voice session is fed to the gaming application? 

By the signaling.

> It could
> be useful to include some information about the approach in
> draft-rosenberg-sip-app-media-tag-01.txt.

That document is really about the dispatch problem. I'll include a 
bullet in the recommendations section, which points out how its done and 
points to that draft. It says:

<t>
Device dispatch should be done following the principles of
<xref target="RFC3841"/>, using implicit preferences based on the
signaling. For example,
<xref target="I-D.rosenberg-sip-app-media-tag"/> defines a new UA
capability that can be used to dispatch requests based on different
types of application media streams.
</t>

> I believe it is also
> worthwhile to discuss "multiple AoR" strategy.  

I'll add yet another bullet; that is really only doable when you have 
presence which allows you to go from the AOR (since users only want one) 
to per-service URI.

I added:

<t>
Presence can help a great deal with service indentification. When a
user wishes to contact another user, and knows only the AOR for the
target (which is usually the case), the user can fetch the presence
document for the target. That document, in turn, can contain numerous
service URI for contacting the target with different services. The
usage of different URI for contacting different services makes it very
easy to identify the service - it's the actual target of the request
itself. When possible, this is the best solution to the problem.
</t>

> 
> * 6.2.1 Fraud
> If billing/accounting etc... is performed by the application server,
> fraud shouldn't be possible with or without Application-Id (like stated
> in the draft, the messages can reach the intended application server
> based on target URI and there is no need for an Application-Id for that
> purpose but an Application-Id based solution can use target URI for
> routing to the AS purposes as well)

This is the point - don't use the explicit service ID since it can be faked.

> 
> * 6.2.2 Systematic Interoperability Failures
> I think QoS is something, which needs to be signaled explicitly and
> should be independent of a particular service. It could be nice to
> provide an additional example in this section.
> 

I've reworked one of the paragraphs in here to talk specifically about qos.

Thanks for your comments,
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  http://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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 27 Feb 2008 17:26:03 -0500

Jonathan,

One follow-up question:

[..snip..]

> > make sure that voice session is fed to the gaming application?
There is something I miss on this one. What would be difference in
signaling between a standalone voice call session and a voice session in
the context of the gaming application for the case described above?

Thanks,
Tolga
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Feb 2008 08:11:38 -0500

In this case, there are two m-lines in the SDP - one for the game moves 
and one for media. Just because the game moves go through a separate 
intermediary, doesn't mean its invisible in the signaling.

-Jonathan R.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 28 Feb 2008 09:17:55 -0500

Jonathan,

I think I failed to explain the scenario properly: There are two
sessions, not just one. Session for game moves is established between
each player and the game server but the session for voice is between the
players themselves.

I guess, one could say:

a) In this case the voice communication should be considered as a
separate application invocation, i.e as a regular voice call. I am not
sure whether this would provide the best user experience though. It
would be like playing an online game and calling your teammates with
phone.

b) This type of use is out of scope and any game with that type of
capability should use a single session.

c) Signaling for a voice session set up for online gaming will be
different than signaling for a regular voice session (how?)

d) There is some other way of making this work

Thanks,
Tolga

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, February 28, 2008 8:12 AM
> To: Asveren, Tolga
> Cc: [email-masked]
> Subject: Re: Review of draft-ietf-sipping-service-identification-00
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Feb 2008 09:27:33 -0500

OK, so to make sure I understand, you are saying that the SIP part of 
this is purely voice - just a SIP invite with a voice m-line? It just so 
happens that there is a game in progress, that game maybe not even using 
SIP. Is that right?

-Jonathan R.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 28 Feb 2008 09:43:01 -0500

Yes, but that pure voice call is in the context of the gaming
application, i.e. from user's perspective it is part of her gaming
experience.

Thanks,
Tolga

> Sent: Thursday, February 28, 2008 9:28 AM
> To: Asveren, Tolga
> Cc: [email-masked]
> >>>>> for the game are sent to a centralized gaming server whereas
voice
> >>> is
> >>>> The signaling would still be clear on what is happening so I
don't
> > see

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Feb 2008 11:12:21 -0500

Ah I see. OK, so here is my thoughts on this use case.

Presumably you wouldn't want 'features' like call screening, voicemail, 
etc., to engage for this voice call. There is also probably a charging 
difference.

You also need to have the voice call directed to the device handling the 
games, and presumably not do things like alerting - i.e., voice just 
engages when we play the game.

At the same time, you need to make sure users can't make these 'voice' 
calls unless they are playing the game; otherwise there is fraud 
opportunities and other problems.

So I would have the game connection get set up, and over that, exchange 
a URI for targeting the game application on the receiving phone, i.e.:

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

this is a gruu that the terminating domain would construct, and since it 
was built for the game the terminating domain understands its treatment. 
The gr param is cryptorandom so you can't guess one and thus need to 
start the game to get it.

And in this way, the signaling is different. It isn't targeting the 
user, its targeting a service on the UA, the address having been learned 
by connecting to the game service (SIP or otherwise).

If you tried to include an explicit service-ID from the UA, i.e., send 
the INVITE to [email-masked] but include a sip header that says, 
"game-voice", this is a massive fraud opportunity since UA will send 
those INVITE without having games. And btw since it doesn't ring the 
terminating phone its a massive security hole.

I think its fair to say that this piece of the puzzle - the idea of 
using different identifiers for entities in the agent - is not well 
treated in the document. There is a brief mention of doing this via 
presence. I think Eric has promoted strongly this mechanism and I do 
believe its viable but you NEED to have some other way to learn those 
URI. Here you do, and you also do in presence.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Feb 2008 13:21:25 -0500

> application, i.e. from user's perspective it is part of her gaming

So the sequence of events is:

- some sort of signaling to establish a gaming session
   (maybe sip, maybe something else???)

- separate signaling to establish a voice call that
   should be tied to the equipment/application that is
   involved with the gaming session.

IMO this is quite a bit like an INVITE/Join, and that could be used for 
this - at least if the original session was established using sip.

Because of the possibility of multiple UAs per AOR, and the possibility 
that a UA could have multiple sessions active at once, AOR+serviceid 
isn't a unique identifier for an existing session in any case. If you 
want to connect to an existing session then you need to identify that 
session.

	Paul