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

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 12 Oct 2007 10:37:25 -0400

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.

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

_______________________________________________
Sipping mailing list  https://www1.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: Eric Burger <[email-masked]>
Date: Mon, 15 Oct 2007 07:31:38 -0500

Comments inline.

> where it can recognize all allowed targets rather than just phone

The two use cases proposed by 3GPP were application invocation / message
dispatch at the User Agent and forcing the routing of messages to in-network
application servers.  Thus I would offer it is appropriate to have these two
use cases come up first, if for no other reason to show that we are
listening.

> subscriber to an application service) but not on a particular service.

This is the point of the section: having a Service Identifier *implicitly*
indicate QoS will blow up.  Such a request for QoS must either be explicit
or asserted by the network.  In any event, even if the QoS request is
explicit, most networks will validate and assert the QoS allocation, anyway.

Believe it or not, there really is a use for SBC's!

> Again, I don't think this is something to be done by a proxy.

I would offer we use the "network element" language, as in:

  Consequently, when an INVITE arrives at a network element, the
  element will need to determine what the requested service is, so that
  it can make an authorization decision.

The reason I would offer this is I do not see why a Proxy *cannot* provide
this function.  It is not necessarily a network termination function, which
would require it to be an AS function.

> rather than a separate problem.

Perhaps if we move 5.6 to be after 5.2?  It is a distinct scenario, in that
5.1 and 5.7 refer to the case where the message gets dispatched to a single
instance based on the signaling, whereas 5.6 is more interactive and either
asks the user or uses heuristics to pick the correct target for the message.

> worthwhile to discuss "multiple AoR" strategy.

This sounds to me like another use case.  Do note these use cases are ALL
subsets of the problem space.

> routing to the AS purposes as well)

This is the point!

> provide an additional example in this section.

We are using QoS as an example.  Got another favorite failure you would like
captured?

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 15 Oct 2007 14:13:33 -0400

Eric,

Please see below for comments/questions.

  Thanks,
  Tolga

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: Monday, October 15, 2007 8:32 AM
> To: Asveren, Tolga; Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: [Sipping] Review of draft-ietf-sipping-service-
> identification-00
> 
> Comments inline.
> 
> 
> application servers.  Thus I would offer it is appropriate to have
these
> two
[TOLGA]Are we sure that what they mean with "forcing the routing of
messages to in-network application servers" is what is described in this
draft, i.e. routing based on target URI, rather than knowing by other
means that a certain service needs to be invoked for a particular
session where target URI does not provide any hint whatsoever about that
service?
> explicit, most networks will validate and assert the QoS allocation,
[TOLGA]My comment is a little bit more than that. What I am saying is
"For QoS reservation, we don't need to know the specific application
layer service". It doesn't matter whether the service is identified by a
"Service Identifier" or implicitly by other signaling elements as
suggested by the draft. IMHO, this is not a valid example.
> would require it to be an AS function.
[TOLGA]Fine with me.
> subsets of the problem space.
[TOLGA]Yes, but the difference is the solution stated in the draft does
cover the use case mentioned in the draft but not necessarily the one I
mentioned, which IMO is a problem significantly harder to solve. 
> > routing to the AS purposes as well)
[TOLGA]O.K.
> We are using QoS as an example.  Got another favorite failure you
would
> like
[TOLGA]For the reasons I mentioned above, IMHO QoS is not a valid
example. And I don't know what would make a good example for the case
where an application requires involvement of application servers in
different domains.
> 
> 
> Notice:  This email message, together with any attachments, may
contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and
affiliated
> entities,  that may be confidential,  proprietary,  copyrighted
and/or
> legally privileged, and is intended solely for the use of the
individual
> or entity named in this message. If you are not the intended
recipient,
> and have received this message in error, please immediately return
this by
> email and then delete it.