Draft: draft-ietf-sipping-service-identification-00
Reviewer: Tolga Asveren [tasveren@sonusnet.com] 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.

* 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? 

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

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

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

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.
 
* 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? We would have two sessions but how could we make sure that voice session is fed to the gaming application? It could be useful to include some information about the approach in draft-rosenberg-sip-app-media-tag-01.txt. I believe it is also worthwhile to discuss "multiple AoR" strategy.  

* 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)

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