Subject: [Sipping] Use and requirements of Service ID

From: <[email-masked]>
Date: Wed, 21 Mar 2007 13:56:12 +0200

Dear all,

we discussed yesterday in a parallel session and in social event the use
cases of service ID once again. It was understood that the service ID is
intended to distinguish between services that otherwise would look
similar in SIP and SDP contents like TV and unidirectional video stream
or messaging intended for rendering to the user vs. messaging for some
other use (configuration?).

The reasons for this distinction would be for the network to route the
message via specific AS to perform whatever services are needed for the
session, for QoS management and charging. The endpoints could benefit
from identifying the right application within the terminal.

As the terminal cannot be trusted to provide charging information, the
network can only achieve this via disallowing participating to such
services unless the terminal indicates the correct ID. And this would
happen at the cost of breaking the interoperability towards legacy 3GPP
IMS terminals and non-3GPP SIP terminals that are not aware of the
service ID.

It was also seen that for the above purposes the service ID is to be
considered as something *additional to* the usual SIP / SDP contents,
not instead of it or in contradiction with it.

The 3GPP protocol requirements are defined in 3GPP TS 23.228, subclause
4.13. There was a recent change to mandate the setting of service ID
when one is known to exist for the service and stating that it's not an
error if multiple service identifications are included in a single
request. I don't quote the whole subclause here, but instead point you
to the latest change in this area in document SP-070237, which you can
find here:

http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_35/Docs/

I hope this helps to proceed in the matter urgently. Up to now all 3GPP
Rel-7 specifications are only in "work in progress" status, but the
functional freeze was done already and the next SA plenary in early June
2007 is expected to freeze Rel-7, which means it should be
implementable.

BR,
Hannu Hietalahti
3GPP TSG CT chairman
Nokia
http://www.nokia.com/openness/

_______________________________________________
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: Wed, 21 Mar 2007 16:01:20 +0100

These are the requirements for the implementation for the service
identifier.  Where are the requirements that resulted in this particular
document?  We can infer some requirements.  For example, one might infer
that:

   At terminals, the use of a communication service identifier
   is similar to the use of the port concept in TCP/IP, in that
   it allows applications in a terminal and the network that
   use SIP for communication purposes to be identified.

implies there is a requirement to:
   - Reduce registration load
     (implying not having the terminal register multiple,
      distinct AOR's)
   - Reduce proxy computation
     (implying the proxy cannot compute the correct AOR or
      retargeting Request-URI parameter tags)

Of course, this is purely a guess.  What are the requirements, really?

By the way, note that the sentiment described here:
> As the terminal cannot be trusted to provide charging information, the network
> can only achieve this via disallowing participating to such services unless
> the terminal indicates the correct ID.
Is EXACTLY why the terminal cannot be trusted to provide the service ID.
Are we really saying the requirement is that the terminal needs to be
provisioned with a secret (the service ID) in order to limit
non-approved-handsets or subscribers from accessing a given service?  If so,
I would offer that would last at most one week before being hacked.

Please also note that so far, THERE HAS BEEN NO PAIR OF SERVICES THAT ARE
INDISTINGUISHABLE BASED ON A PROPERLY FORMED SIP INVITE.  By "properly
formed," I do include fixing implementation bugs.  For example, fixing the
POC bug by using Require instantly makes a POC call distinguishable from a
normal telephony call.

I am sure that we can do a BLISS exercise, if necessary, to document all of
the supposed indistinguishable "services."

On 3/21/07 12:56 PM, "[email-masked]"
<[email-masked]> wrote:

> Dear all, 
> 
> we discussed yesterday in a parallel session and in social event the use cases
> of service ID once again. It was understood that the service ID is intended to
> distinguish between services that otherwise would look similar in SIP and SDP
> contents like TV and unidirectional video stream or messaging intended for
> rendering to the user vs. messaging for some other use (configuration?).
> 
> The reasons for this distinction would be for the network to route the message
> via specific AS to perform whatever services are needed for the session, for
> QoS management and charging. The endpoints could benefit from identifying the
> right application within the terminal.
> 
> As the terminal cannot be trusted to provide charging information, the network
> can only achieve this via disallowing participating to such services unless
> the terminal indicates the correct ID. And this would happen at the cost of
> breaking the interoperability towards legacy 3GPP IMS terminals and non-3GPP
> SIP terminals that are not aware of the service ID.
> 
> considered as something *additional to* the usual SIP / SDP contents, not
> instead of it or in contradiction with it.
> 
> The 3GPP protocol requirements are defined in 3GPP TS 23.228, subclause 4.13.
> There was a recent change to mandate the setting of service ID when one is
> known to exist for the service and stating that it's not an error if multiple
> service identifications are included in a single request. I don't quote the
> whole subclause here, but instead point you to the latest change in this area
> in document SP-070237, which you can find here:
> 
> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_35/Docs/>
> 
> I hope this helps to proceed in the matter urgently. Up to now all 3GPP Rel-7
> specifications are only in "work in progress" status, but the functional
> freeze was done already and the next SA plenary in early June 2007 is expected
> to freeze Rel-7, which means it should be implementable.
> 
> BR, 
> Hannu Hietalahti 
> 3GPP TSG CT chairman
> Nokia 
> http://www.nokia.com/openness/ <http://www.nokia.com/openness/>
> 
> 

_______________________________________________________________________
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: <[email-masked]>
Date: Wed, 21 Mar 2007 20:15:53 +0200

Hi Eric,

thanks for your comments.

See my reply inline.

BR,
Hannu Hietalahti
3GPP TSG CT chairman
Nokia

>-----Original Message-----
>From: ext Eric Burger [mailto:[email-masked]] 
>Sent: 21 March, 2007 17:01
>To: Hietalahti Hannu (Nokia-SIR/Oulu); [email-masked]
>Subject: Re: [Sipping] Use and requirements of Service ID
>
>These are the requirements for the implementation for the 
>service identifier.  Where are the requirements that resulted 
>in this particular document?  We can infer some requirements.  
>For example, one might infer
>that:
>

HH: 
The service requirements in 22.228 
http://www.3gpp.org/ftp/Specs/2007-03/Rel-7/22_series/
are admittedly at fairly high level, so that's why I was referencing to
the stage 2 paper 23.228:
http://www.3gpp.org/ftp/Specs/2007-03/Rel-7/23_series/

Registrar or proxy or any other load issue is IMHO already getting to
protocol aspects. They are very true and real requirements, but not so
visible in the service requirements level.

>> services unless the terminal indicates the correct ID.
>Are we really saying the requirement is that the terminal 
>needs to be provisioned with a secret (the service ID) in 
>order to limit non-approved-handsets or subscribers from 
>accessing a given service?  If so, I would offer that would 
>last at most one week before being hacked.

HH:

BTDT and agree.

ANY mechanism where the terminal can affect the charging is inherently
vulnerable, no matter how it's protected. 

I was actually assuming that a well-known identifier would be added by
the terminal that is willing to pay for the service and based on local
policy the network could restrict access to the service if no service ID
is included. The tag, encoded in whichever way, would indicate
willingness to pay and it's got nothing to do with authentication.

I don't like that any more than you do as that breaks the
interoperability. And I hope that people will think again and not use
this option. But at the moment it is one of the 3GPP requirements,
whether I like it or not.

>
>Please also note that so far, THERE HAS BEEN NO PAIR OF 
>SERVICES THAT ARE INDISTINGUISHABLE BASED ON A PROPERLY FORMED 
>SIP INVITE.  By "properly formed," I do include fixing 
>implementation bugs.  For example, fixing the POC bug by using 
>Require instantly makes a POC call distinguishable from a 
>normal telephony call.

HH:
Some examples were considered in the evening session yesterday and at
least for some people they seemed to make sense. But that's not the
point here.

As there are people out there who see service identification beneficial,
then it would be more constructive to consider the best way to achieve
it with minimum damage to the protocol.

>
>I am sure that we can do a BLISS exercise, if necessary, to 
>document all of the supposed indistinguishable "services."
>
>
>
>> we discussed yesterday in a parallel session and in social event the 
>> use cases of service ID once again. It was understood that 
>the service 
>> ID is intended to distinguish between services that otherwise would 
>> look similar in SIP and SDP contents like TV and 
>unidirectional video 
>> stream or messaging intended for rendering to the user vs. 
>messaging for some other use (configuration?).
>> 
>> message via specific AS to perform whatever services are needed for 
>> the session, for QoS management and charging. The endpoints could 
>> benefit from identifying the right application within the terminal.
>> 
>> happen at the cost of breaking the interoperability towards legacy 
>> 3GPP IMS terminals and non-3GPP SIP terminals that are not 
>aware of the service ID.
>> 
>> There was a recent change to mandate the setting of service ID when 
>> one is known to exist for the service and stating that it's not an 
>> to the latest change in this area in document SP-070237, 
>which you can find here:
>> 
>> I hope this helps to proceed in the matter urgently. Up to now all 
>> 3GPP Rel-7 specifications are only in "work in progress" status, but 
>> the functional freeze was done already and the next SA plenary in 
>> early June 2007 is expected to freeze Rel-7, which means it 
>should be implementable.
>> 
>> BR,
>> Hannu Hietalahti
>> 3GPP TSG CT chairman
>> Nokia

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Mar 2007 14:36:33 -0400

> whether I like it or not.

I don't understand this. If the model is Do What I Say, then by 
definition what is done is what the UA is willing to pay for.

It seems that the only problem is when the network decides to do 
something on behalf of the user, that the user didn't ask for, and still 
wants authorization to charge for it.

This could be solved by providing ways to make explicit requests to 
network servers to do things. This already exists in some cases, such as 
when sending an invite to a streaming video service operated by the 
provider. I don't think this is a hard problem on the originating side. 
It may be harder on the terminating side, but I'm sure it can be 
arranged in this case as well.

	Paul

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 22 Mar 2007 05:54:09 +0100

Use and requirements of Service IDHannu,

For reasons stated below by you, I would propose that we start treating *and 
calling* the terminal provided service ID _differently_ from the network 
asserted service ID.
The terminal cannot be allowed to insert an arbitrary service ID on which 
the network bases its charging. The ids before and after authorization by 
the network may be the same strings, but they are different beasts. Much 
like P-Preferred-Identity is not the same as P-Asserted-Identity.

The identifier used by the terminal can be used to route to the appropriate 
application. Let's call this the "Application ID" then

The identifier used by the network for charging (amongst other things) may 
then be based on the application ID, or on other information. The 
application ID would be filtered through an authorization function. Let's 
call the resulting, network asserted ID the "Network Service ID"

Regards,
Jeroen

  ----- Original Message ----- 
  From: [email-masked]
  To: [email-masked]
  Sent: Wednesday, March 21, 2007 12:56 PM
  Subject: [Sipping] Use and requirements of Service ID

  Dear all,

  we discussed yesterday in a parallel session and in social event the use 
cases of service ID once again. It was understood that the service ID is 
intended to distinguish between services that otherwise would look similar 
in SIP and SDP contents like TV and unidirectional video stream or messaging 
intended for rendering to the user vs. messaging for some other use 
(configuration?).

  The reasons for this distinction would be for the network to route the 
message via specific AS to perform whatever services are needed for the 
session, for QoS management and charging. The endpoints could benefit from 
identifying the right application within the terminal.

  As the terminal cannot be trusted to provide charging information, the 
network can only achieve this via disallowing participating to such services 
unless the terminal indicates the correct ID. And this would happen at the 
cost of breaking the interoperability towards legacy 3GPP IMS terminals and 
non-3GPP SIP terminals that are not aware of the service ID.

  The 3GPP protocol requirements are defined in 3GPP TS 23.228, subclause 
4.13. There was a recent change to mandate the setting of service ID when 
one is known to exist for the service and stating that it's not an error if 
multiple service identifications are included in a single request. I don't 
quote the whole subclause here, but instead point you to the latest change 
in this area in document SP-070237, which you can find here:

  I hope this helps to proceed in the matter urgently. Up to now all 3GPP 
Rel-7 specifications are only in "work in progress" status, but the 
functional freeze was done already and the next SA plenary in early June 
2007 is expected to freeze Rel-7, which means it should be implementable.

  BR,
  Hannu Hietalahti
  3GPP TSG CT chairman
  Nokia

------------------------------------------------------------------------------

---

From: <[email-masked]>
Date: Thu, 22 Mar 2007 12:05:22 +0200

Hi Jeroen,
 
such as P-header inserted by the network? If that's what people would
prefer, we should study it further, as it may also meet the need. 
 
Let's assume an AS needs to perform some tweak to a request to perform
some service. Up to now I have been assuming that this would be
triggered based on the feature tag found in contact header. 
 
If that's considered criminal and the network feels better if it does
the same magic as would be needed for this decision to route to AS, but
inserts a P-asserted-something -header instead for any subsequent
elements to consider, then it could to lead to the same outcome, but in
a more orthodox way?

BR, 
Hannu Hietalahti 
3GPP TSG CT chairman 
Nokia 

________________________________

	From: ext Jeroen van Bemmel [mailto:[email-masked]] 
	Sent: 22 March, 2007 06:54
	To: Hietalahti Hannu (Nokia-SIR/Oulu); [email-masked]
	Subject: Re: [Sipping] Use and requirements of Service ID

	Hannu,
	 
	For reasons stated below by you, I would propose that we start
treating *and calling* the terminal provided service ID _differently_
from the network asserted service ID.
	The terminal cannot be allowed to insert an arbitrary service ID
on which the network bases its charging. The ids before and after
authorization by the network may be the same strings, but they are
different beasts. Much like P-Preferred-Identity is not the same as
P-Asserted-Identity.
	 
	The identifier used by the terminal can be used to route to the
appropriate application. Let's call this the "Application ID" then
	 
	The identifier used by the network for charging (amongst other
things) may then be based on the application ID, or on other
information. The application ID would be filtered through an
authorization function. Let's call the resulting, network asserted ID
the "Network Service ID"
	 
	Regards,
	Jeroen

		----- Original Message ----- 
		From: [email-masked] 
		To: [email-masked] 
		Sent: Wednesday, March 21, 2007 12:56 PM
		Subject: [Sipping] Use and requirements of Service ID

		Dear all, 

		we discussed yesterday in a parallel session and in
social event the use cases of service ID once again. It was understood
that the service ID is intended to distinguish between services that
otherwise would look similar in SIP and SDP contents like TV and
unidirectional video stream or messaging intended for rendering to the
user vs. messaging for some other use (configuration?).

		The reasons for this distinction would be for the
network to route the message via specific AS to perform whatever
services are needed for the session, for QoS management and charging.
The endpoints could benefit from identifying the right application
within the terminal.

		As the terminal cannot be trusted to provide charging
information, the network can only achieve this via disallowing
participating to such services unless the terminal indicates the correct
ID. And this would happen at the cost of breaking the interoperability
towards legacy 3GPP IMS terminals and non-3GPP SIP terminals that are
not aware of the service ID.

		It was also seen that for the above purposes the service
ID is to be considered as something *additional to* the usual SIP / SDP
contents, not instead of it or in contradiction with it.

		The 3GPP protocol requirements are defined in 3GPP TS
23.228, subclause 4.13. There was a recent change to mandate the setting
of service ID when one is known to exist for the service and stating
that it's not an error if multiple service identifications are included
in a single request. I don't quote the whole subclause here, but instead
point you to the latest change in this area in document SP-070237, which
you can find here:

		I hope this helps to proceed in the matter urgently. Up
to now all 3GPP Rel-7 specifications are only in "work in progress"
status, but the functional freeze was done already and the next SA
plenary in early June 2007 is expected to freeze Rel-7, which means it
should be implementable.

		BR, 
		Hannu Hietalahti 
		3GPP TSG CT chairman 
		Nokia 
		http://www.nokia.com/openness/
<http://www.nokia.com/openness/>  

________________________________

		_______________________________________________
		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: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 22 Mar 2007 22:29:23 +0100

>From a trust point of view, I think a tag in (Accept-)Contact is equivalent 
to some identifier inserted into a (for example) Application-Id header by 
the UAC. It is asserted by the UAC

You may base routing on such a tag, that is what we already do with 
callerprefs and IFC. However, you cannot base charging on such a tag, not 
without subjecting it to an authorization check. For that you need something 
that is asserted (and thus authorized by and inserted by) the network. The 
network can base this assertion on any information it considers necessary, 
it can do a database check, etc. It may also opt to simply copy the value 
from the Application-Id, if that is the policy.

My basic point is: I think we are trying to solve multiple, fundamentally 
different issues with one solution: the service identifier. It's not about 
criminal versus orthodox, it's about clearly identifying and distinguishing 
the various issues there are, and then for each issue make a 
decision/design/solution on how to address that.

Personally, I think a guiding principle should be that we try and reuse 
existing mechanisms where possible, rather than inventing new ones. So for 
routing related issues I can imagine that we'd reuse callerprefs. For the 
issue of preventing a non-supporting terminal to choke on a request, we 
would typically reuse the Require mechanism. This I believe is an exercise 
that still needs to take place

Regards,
Jeroen

  ----- Original Message ----- 
  From: [email-masked]
  To: [email-masked] ; [email-masked]
  Sent: Thursday, March 22, 2007 11:05 AM
  Subject: RE: [Sipping] Use and requirements of Service ID

  Hi Jeroen,

  Let's assume an AS needs to perform some tweak to a request to perform 
some service. Up to now I have been assuming that this would be triggered 
based on the feature tag found in contact header.

  If that's considered criminal and the network feels better if it does the 
same magic as would be needed for this decision to route to AS, but inserts 
a P-asserted-something -header instead for any subsequent elements to 
consider, then it could to lead to the same outcome, but in a more orthodox 
way?
  BR,
  Hannu Hietalahti
  3GPP TSG CT chairman
  Nokia
  http://www.nokia.com/openness/

----------------------------------------------------------------------------

    Hannu,

    For reasons stated below by you, I would propose that we start treating 
*and calling* the terminal provided service ID _differently_ from the 
network asserted service ID.
    The terminal cannot be allowed to insert an arbitrary service ID on 
which the network bases its charging. The ids before and after authorization 
by the network may be the same strings, but they are different beasts. Much 
like P-Preferred-Identity is not the same as P-Asserted-Identity.

    The identifier used by the network for charging (amongst other things) 
may then be based on the application ID, or on other information. The 
application ID would be filtered through an authorization function. Let's 
call the resulting, network asserted ID the "Network Service ID"

    Regards,
    Jeroen

      ----- Original Message ----- 
      From: [email-masked]
      To: [email-masked]
      Sent: Wednesday, March 21, 2007 12:56 PM
      Subject: [Sipping] Use and requirements of Service ID

      Dear all,

use cases of service ID once again. It was understood that the service ID is 

      The 3GPP protocol requirements are defined in 3GPP TS 23.228, 
subclause 4.13. There was a recent change to mandate the setting of service 
ID when one is known to exist for the service and stating that it's not an 
error if multiple service identifications are included in a single request. 
I don't quote the whole subclause here, but instead point you to the latest 
change in this area in document SP-070237, which you can find here:

      I hope this helps to proceed in the matter urgently. Up to now all 
3GPP Rel-7 specifications are only in "work in progress" status, but the 
functional freeze was done already and the next SA plenary in early June 
2007 is expected to freeze Rel-7, which means it should be implementable.

      BR,
      Hannu Hietalahti
      3GPP TSG CT chairman
      Nokia

--------------------------------------------------------------------------

---

Date: Fri, 23 Mar 2007 11:02:09 +0200

> functionality is superior because it fixes problems in a previous one.
> I
> think the point is being made that ICE provides a superset of
> functionality of ANAT and fixes two issues ANAT has - (1) its
> selection
> of transport addresses are not dynamic and we've have learned that
> dynamic selection is better, and (2) ANAT doesn't allow for RFC 3484
> address selection.
>=20
> -Jonathan R.
>=20
> Hadriel Kaplan wrote:
>=20
> > The thing that bothers me about this ICE vs. ANAT
> discussion/decision is
> > that it makes the assumption that ICE is or will soon become
> ubiquitous.
> > That may well happen, but it is far too premature to assume so.  The
> IETF
> > has shown time and time again that it is good at specifying
> protocols, but
> > bad at mandating market forces by fiat.  The SIP WG is no exception
> to that.
> > The market picks and chooses from the work of the ietf, not the
> other way
> > around.
> >
> > So the concern I have is if we start going down this road of "oh we
> can
> > deprecate this now", without any evidence that the ICE is successful
> in the
> > market, then we are creating yet another head-in-the-sand scenario
> that made
> > the ietf ignore NATs to begin with.
> >
> > So if the proposal is to actually _deprecate_ ANAT because ICE can
> do it a
> > different way, then I think it's too soon.  If the proposal is just
> to
> > ignore ANAT with respect to the ICE draft - i.e., support address
> family
> > selection natively in ICE without any ANAT syntax needed, then I'm
> in favor
> > of that.
> >
> > -hadriel
> >
>=20
> --
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 07054-
> 2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
>=20
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

---

From: <[email-masked]>
Date: Fri, 23 Mar 2007 11:02:09 +0200

Hi again, Jeroen,
 
thanks for clarification on the tags. I agree that a tag inserted by UAC
is not a good basis for charging, so let's leave that for a while.
 
IMHO the main needs for the service ID are to point to the right
services (=AS) in the network and to the right applications in the
receiving terminal.
 
BR, 
Hannu Hietalahti 
3GPP TSG CT chairman 
Nokia 

	From: ext Jeroen van Bemmel [mailto:[email-masked]] 
	Sent: 22 March, 2007 23:29
	To: Hietalahti Hannu (Nokia-SIR/Oulu); [email-masked]
	Subject: Re: [Sipping] Use and requirements of Service ID

	Hannu,
	 
	From a trust point of view, I think a tag in (Accept-)Contact is
equivalent to some identifier inserted into a (for example)
Application-Id header by the UAC. It is asserted by the UAC
	 
	You may base routing on such a tag, that is what we already do
with callerprefs and IFC. However, you cannot base charging on such a
tag, not without subjecting it to an authorization check. For that you
need something that is asserted (and thus authorized by and inserted by)
the network. The network can base this assertion on any information it
considers necessary, it can do a database check, etc. It may also opt to
simply copy the value from the Application-Id, if that is the policy.
	 
	My basic point is: I think we are trying to solve multiple,
fundamentally different issues with one solution: the service
identifier. It's not about criminal versus orthodox, it's about clearly
identifying and distinguishing the various issues there are, and then
for each issue make a decision/design/solution on how to address that. 
	 
	Personally, I think a guiding principle should be that we try
and reuse existing mechanisms where possible, rather than inventing new
ones. So for routing related issues I can imagine that we'd reuse
callerprefs. For the issue of preventing a non-supporting terminal to
choke on a request, we would typically reuse the Require mechanism. This
I believe is an exercise that still needs to take place
	 
	Regards,
	Jeroen

		----- Original Message ----- 
		From: [email-masked] 
		To: [email-masked] ; [email-masked] 
		Sent: Thursday, March 22, 2007 11:05 AM
		Subject: RE: [Sipping] Use and requirements of Service
ID

		Hi Jeroen,
		 
		such as P-header inserted by the network? If that's what
people would prefer, we should study it further, as it may also meet the
need. 
		 
		Let's assume an AS needs to perform some tweak to a
request to perform some service. Up to now I have been assum1a8c0@BEMBUSTER>
	<[email-masked]>
	<003101c76cc9$294c96e0$0601a8c0@BEMBUSTER>
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 

This is a multi-part message in MIME format.
Hi again, Jeroen,
 
thanks for clarification on the tags. I agree that a tag inserted by UAC
is not a good basis for charging, so let's leave that for a while.
 
IMHO the main needs for the service ID are to point to the right
services (=AS) in the network and to the right applications in the
receiving terminal.
 
BR, 
Hannu Hietalahti 
3GPP TSG CT chairman 
Nokia 

	From: ext Jeroen van Bemmel [mailto:[email-masked]] 
	Sent: 22 March, 2007 23:29
	To: Hietalahti Hannu (Nokia-SIR/Oulu); [email-masked]
	Subject: Re: [Sipping] Use and requirements of Service ID

	Hannu,
	 
	From a trust point of view, I think a tag in (Accept-)Contact is
equivalent to some identifier inserted into a (for example)
Application-Id header by the UAC. It is asserted by the UAC
	 
	You may base routing on such a tag, that is what we already do
with callerprefs and IFC. However, you cannot base charging on such a
tag, not without subjecting it to an authorization check. For that you
need something that is asserted (and thus authorized by and inserted by)
the network. The network can base this assertion on any information it
considers necessary, it can do a database check, etc. It may also opt to
simply copy the value from the Application-Id, if that is the policy.
	 
	My basic point is: I think we are trying to solve multiple,
fundamentally different issues with one solution: the service
identifier. It's not about criminal versus orthodox, it's about clearly
identifying and distinguishing the various issues there are, and then
for each issue make a decision/design/solution on how to address that. 
	 
	Personally, I think a guiding principle should be that we try
and reuse existing mechanisms where possible, rather than inventing new
ones. So for routing related issues I can imagine that we'd reuse
callerprefs. For the issue of preventing a non-supporting terminal to
choke on a request, we would typically reuse the Require mechanism. This
I believe is an exercise that still needs to take place
	 
	Regards,
	Jeroen

		----- Original Message ----- 
		From: [email-masked] 
		To: [email-masked] ; [email-masked] 
		Sent: Thursday, March 22, 2007 11:05 AM
		Subject: RE: [Sipping] Use and requirements of Service
ID

		Hi Jeroen,
		 
		such as P-header inserted by the network? If that's what
people would prefer, we should study it further, as it may also meet the
need. 
		 
		Let's assume an AS needs to perform some tweak to a
request to perform some service. Up to now I have been assuming that
this would be triggered based on the feature tag found in contact
header. 
		 
		If that's considered criminal and the network feels
better if it does the same magic as would be needed for this decision to
route to AS, but inserts a P-asserted-something -header instead for any
subsequent elements to consider, then it could to lead to the same
outcome, but in a more orthodox way?

		BR, 
		Hannu Hietalahti 
		3GPP TSG CT chairman 
		Nokia 

			From: ext Jeroen van Bemmel
[mailto:[email-masked]] 
			Sent: 22 March, 2007 06:54
			To: Hietalahti Hannu (Nokia-SIR/Oulu);
[email-masked]
			Subject: Re: [Sipping] Use and requirements of
Service ID

			Hannu,
			 
			For reasons stated below by you, I would propose
that we start treating *and calling* the terminal provided service ID
_differently_ from the network asserted service ID.
			The terminal cannot be allowed to insert an
arbitrary service ID on which the network bases its charging. The ids
before and after authorization by the network may be the same strings,
but they are different beasts. Much like P-Preferred-Identity is not the
same as P-Asserted-Identity.
			 
			The identifier used by the terminal can be used
to route to the appropriate application. Let's call this the
"Application ID" then
			 
			The identifier used by the network for charging
(amongst other things) may then be based on the application ID, or on
other information. The application ID would be filtered through an
authorization function. Let's call the resulting, network asserted ID
the "Network Service ID"
			 
			Regards,
			Jeroen

				----- Original Message ----- 
				From: [email-masked] 
				To: [email-masked] 
				Sent: Wednesday, March 21, 2007 12:56 PM
				Subject: [Sipping] Use and requirements
of Service ID

				Dear all, 

				we discussed yesterday in a parallel
session and in social event the use cases of service ID once again. It
was understood that the service ID is intended to distinguish between
services that otherwise would look similar in SIP and SDP contents like
TV and unidirectional video stream or messaging intended for rendering
to the user vs. messaging for some other use (configuration?).

				The reasons for this distinction would
be for the network to route the message via specific AS to perform
whatever services are needed for the session, for QoS management and
charging. The endpoints could benefit from identifying the right
application within the terminal.

				As the terminal cannot be trusted to
provide charging information, the network can only achieve this via
disallowing participating to such services unless the terminal indicates
the correct ID. And this would happen at the cost of breaking the
interoperability towards legacy 3GPP IMS terminals and non-3GPP SIP
terminals that are not aware of the service ID.

				It was also seen that for the above
purposes the service ID is to be considered as something *additional to*
the usual SIP / SDP contents, not instead of it or in contradiction with
it.

				The 3GPP protocol requirements are
defined in 3GPP TS 23.228, subclause 4.13. There was a recent change to
mandate the setting of service ID when one is known to exist for the
service and stating that it's not an error if multiple service
identifications are included in a single request. I don't quote the
whole subclause here, but instead point you to the latest change in this
area in document SP-070237, which you can find here:

				I hope this helps to proceed in the
matter urgently. Up to now all 3GPP Rel-7 specifications are only in
"work in progress" status, but the functional freeze was done already
and the next SA plenary in early June 2007 is expected to freeze Rel-7,
which means it should be implementable.

				BR, 
				Hannu Hietalahti 
				3GPP TSG CT chairman 
				Nokia 
				http:/ing that
this would be triggered based on the feature tag found in contact
header. 
		 
		If that's considered criminal and the network feels
better if it does the same magic as would be needed for this decision to
route to AS, but inserts a P-asserted-something -header instead for any
subsequent elements to consider, then it could to lead to the same
outcome, but in a more orthodox way?

		BR, 
		Hannu Hietalahti 
		3GPP TSG CT chairman 
		Nokia 

			From: ext Jeroen van Bemmel
[mailto:[email-masked]] 
			Sent: 22 March, 2007 06:54
			To: Hietalahti Hannu (Nokia-SIR/Oulu);
[email-masked]
			Subject: Re: [Sipping] Use and requirements of
Service ID

			Hannu,
			 
			For reasons stated below by you, I would propose
that we start treating *and calling* the terminal provided service ID
_differently_ from the network asserted service ID.
			The terminal cannot be allowed to insert an
arbitrary service ID on which the network bases its charging. The ids
before and after authorization by the network may be the same strings,
but they are different beasts. Much like P-Preferred-Identity is not the
same as P-Asserted-Identity.
			 
			The identifier used by the terminal can be used
to route to the appropriate application. Let's call this the
"Application ID" then
			 
			The identifier used by the network for charging
(amongst other things) may then be based on the application ID, or on
other information. The application ID would be filtered through an
authorization function. Let's call the resulting, network asserted ID
the "Network Service ID"
			 
			Regards,
			Jeroen

				----- Original Message ----- 
				From: [email-masked] 
				To: [email-masked] 
				Sent: Wednesday, March 21, 2007 12:56 PM
				Subject: [Sipping] Use and requirements
of Service ID

				Dear all, 

				we discussed yesterday in a parallel
session and in social event the use cases of service ID once again. It
was understood that the service ID is intended to distinguish between
services that otherwise would look similar in SIP and SDP contents like
TV and unidirectional video stream or messaging intended for rendering
to the user vs. messaging for some other use (configuration?).

				The reasons for this distinction would
be for the network to route the message via specific AS to perform
whatever services are needed for the session, for QoS management and
charging. The endpoints could benefit from identifying the right
application within the terminal.

				As the terminal cannot be trusted to
provide charging information, the network can only achieve this via
disallowing participating to such services unless the terminal indicates
the correct ID. And this would happen at the cost of breaking the
interoperability towards legacy 3GPP IMS terminals and non-3GPP SIP
terminals that are not aware of the service ID.

				It was also seen that for the above
purposes the service ID is to be considered as something *additional to*
the usual SIP / SDP contents, not instead of it or in contradiction with
it.

				The 3GPP protocol requirements are
defined in 3GPP TS 23.228, subclause 4.13. There was a recent change to
mandate the setting of service ID when one is known to exist for the
service and stating that it's not an error if multiple service
identifications are included in a single request. I don't quote the
whole subclause here, but instead point you to the latest change in this
area in document SP-070237, which you can find here:

				I hope this helps to proceed in the
matter urgently. Up to now all 3GPP Rel-7 specifications are only in
"work in progress" status, but the functional freeze was done already
and the next SA plenary in early June 2007 is expected to freeze Rel-7,
which means it should be implementable.

				BR, 
				Hannu Hietalahti 
				3GPP TSG CT chairman 
				Nokia 

				

_______________________________________________
				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: Paul Kyzivat <[email-masked]>
Date: Sun, 25 Mar 2007 15:54:18 -0400

> elements to consider, then it could to lead to the same outcome, but in 

Whether this is criminal or not depends on more details of what is being 
done.

The callerprefs mechanism is designed to give the caller the opportunity 
to express its desires about which kinds of endpoints the call is 
retargeted to. Note that this does not say that the only capabilities 
used in the resulting call will be those for which a preference was 
expressed, or that the preferred capabilities will be used at all.

24.229 does call for the S-CSCF to apply callerprefs when selecting 
among registered contacts, so there is some intent to comply with 
callerprefs, which is good.

*Other* use of the Accept-Contact header, such as to trigger the 
invocation of Application Servers, is certainly not *inherently* in 
conflict with callerprefs, but it could be, depending on what it does.

In particular, anything that depends on the the resulting call using the 
preferred features, or not using other features, would be in violation 
of 3840/3841. I have never seen a definitive statement of how this would 
be done in IMS, so I can't really comment on whether that will be an 
appropriate usage or not. But I am dubious for the simple reason that I 
can't see how the existing filters can reliably anticipate which contact 
will be selected, and so what the *declared* capabilities will be.

	Paul

>     ------------------------------------------------------------------------
>     *From:* ext Jeroen van Bemmel [mailto:[email-masked]]
>     *Sent:* 22 March, 2007 06:54
>     *To:* Hietalahti Hannu (Nokia-SIR/Oulu); [email-masked]
>     *Subject:* Re: [Sipping] Use and requirements of Service ID
> 
>     Hannu,
>      
>     treating *and calling* the terminal provided service ID
>     which the network bases its charging. The ids before and after
>     authorization function. Let's call the resulting, network asserted
>     ID the "Network Service ID"
>      
>     Regards,
>     Jeroen
>      
> 
>         *From:* [email-masked]
>         <mailto:[email-masked]>
>         *To:* [email-masked] <mailto:[email-masked]>
>         *Sent:* Wednesday, March 21, 2007 12:56 PM
>         *Subject:* [Sipping] Use and requirements of Service ID
> 
>         Dear all,
> 
>         we discussed yesterday in a parallel session and in social event
>         the use cases of service ID once again. It was understood that
>         the service ID is intended to distinguish between services that
>         unidirectional video stream or messaging intended for rendering
>         The reasons for this distinction would be for the network to
>         route the message via specific AS to perform whatever services
>         are needed for the session, for QoS management and charging. The
>         endpoints could benefit from identifying the right application
>         within the terminal.
> 
>         participating to such services unless the terminal indicates the
>         correct ID. And this would happen at the cost of breaking the
>         interoperability towards legacy 3GPP IMS terminals and non-3GPP
>         It was also seen that for the above purposes the service ID is
>         to be considered as something *additional to* the usual SIP /
>         SDP contents, not instead of it or in contradiction with it.
> 
>         subclause 4.13. There was a recent change to mandate the setting
>         of service ID when one is known to exist for the service and
>         stating that it's not an error if multiple service
>         identifications are included in a single request. I don't quote
>         the whole subclause here, but instead point you to the latest
>         _http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_35/Docs/_
> 
>         I hope this helps to proceed in the matter urgently. Up to now
>         all 3GPP Rel-7 specifications are only in "work in progress"
>         status, but the functional freeze was done already and the next
>         SA plenary in early June 2007 is expected to freeze Rel-7, which
>         means it should be implementable.
> 
>         BR,
>         Hannu Hietalahti
>         3GPP TSG CT chairman
>         Nokia
>         _http://www.nokia.com/openness/_
> 
>         ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------
>

---

From: <[email-masked]>
Date: Mon, 26 Mar 2007 14:43:17 +0200

[email-masked] wrote:
>IMHO the main needs for the service ID are to point to the right services (=AS) in the >network and to the right applications in the receiving >terminal

On Mar 22, 2007, at 3:39 PM, Salvatore Loreto wrote:
> As I said also in the past, the idea (but this is my personal opinion) is to specify better >the context, and with context I mean the communication environment in term not >only of media, but also QoS, delay, type of access network etc.etc.  

I have difficulties understanding these different approaches from assumingly the same source (3GPP). And this is striking, people have asked for requirements and more understanding. Just maybe, we are all in the dark on the need for service IDs. 

Also, these are utterly different, multiple issues. There is no inherent correlation between the issues, as is indicated by the statement that the interpretation of service IDs is "local policy". So, one *solution* does not work and should not be our goal. 
IMO the first set of issues mentioned above have been dealt with extensively on the list, with clear guidance to use existing mechanism such as callerprefs and Require .

The second set of issues (QoS, charging, etc) should be based on some business requirements if any. Also, QoS and charging are two different beasts. In addition, both will also be subject to service provider policy and implementation (and possible regulatory policy and scrutiny). Hence, not two providers will implement the same thing. And because QoS Control and charging does not depend on a serviceID, this would not require the notion of serviceIDs (aside from the 'religious' debate on the merits of QoS Control and charging), 

Regards,
Colin

________________________________________
Van: [email-masked] [mailto:[email-masked]] 
Verzonden: vrijdag 23 maart 2007 10:02
Aan: [email-masked]; [email-masked]
Onderwerp: RE: [Sipping] Use and requirements of Service ID

Hi again, Jeroen,
 
thanks for clarification on the tags. I agree that a tag inserted by UAC is not a good basis for charging, so let's leave that for a while.
 
IMHO the main needs for the service ID are to point to the right services (=AS) in the network and to the right applications in the receiving terminal.
 
BR, 
Hannu Hietalahti 
3GPP TSG CT chairman 
Nokia 

________________________________________
 
>From a trust point of view, I think a tag in (Accept-)Contact is equivalent to some identifier inserted into a (for example) Application-Id header by the UAC. It is asserted by the UAC
 
You may base routing on such a tag, that is what we already do with callerprefs and IFC. However, you cannot base charging on such a tag, not without subjecting it to an authorization check. For that you need something that is asserted (and thus authorized by and inserted by) the network. The network can base this assertion on any information it considers necessary, it can do a database check, etc. It may also opt to simply copy the value from the Application-Id, if that is the policy.
 
My basic point is: I think we are trying to solve multiple, fundamentally different issues with one solution: the service identifier. It's not about criminal versus orthodox, it's about clearly identifying and distinguishing the various issues there are, and then for each issue make a decision/design/solution on how to address that. 
 
Personally, I think a guiding principle should be that we try and reuse existing mechanisms where possible, rather than inventing new ones. So for routing related issues I can imagine that we'd reuse callerprefs. For the issue of preventing a non-supporting terminal to choke on a request, we would typically reuse the Require mechanism. This I believe is an exercise that still needs to take place
 
Regards,
Jeroen
 
----- Original Message ----- 
From: [email-masked] 
To: [email-masked] ; [email-masked] 
Sent: Thursday, March 22, 2007 11:05 AM
Subject: RE: [Sipping] Use and requirements of Service ID

Hi Jeroen,
 
such as P-header inserted by the network? If that's what people would prefer, we should study it further, as it may also meet the need. 
 
Let's assume an AS needs to perform some tweak to a request to perform some service. Up to now I have been assuming that this would be triggered based on the feature tag found in contact header. 
 
If that's considered criminal and the network feels better if it does the same magic as would be needed for this decision to route to AS, but inserts a P-asserted-something -header instead for any subsequent elements to consider, then it could to lead to the same outcome, but in a more orthodox way?
BR, 
Hannu Hietalahti 
3GPP TSG CT chairman 
Nokia 
http://www.nokia.com/openness/ 

________________________________________
 
For reasons stated below by you, I would propose that we start treating *and calling* the terminal provided service ID _differently_ from the network asserted service ID.
The terminal cannot be allowed to insert an arbitrary service ID on which the network bases its charging. The ids before and after authorization by the network may be the same strings, but they are different beasts. Much like P-Preferred-Identity is not the same as P-Asserted-Identity.
 
The identifier used by the terminal can be used to route to the appropriate application. Let's call this the "Application ID" then
 
The identifier used by the network for charging (amongst other things) may then be based on the application ID, or on other information. The application ID would be filtered through an authorization function. Let's call the resulting, network asserted ID the "Network Service ID"
 
Regards,
Jeroen
 
----- Original Message ----- 
From: [email-masked] 
To: [email-masked] 
Sent: Wednesday, March 21, 2007 12:56 PM
Subject: [Sipping] Use and requirements of Service ID

Dear all, 
we discussed yesterday in a parallel session and in social event the use cases of service ID once again. It was understood that the service ID is intended to distinguish between services that otherwise would look similar in SIP and SDP contents like TV and unidirectional video stream or messaging intended for rendering to the user vs. messaging for some other use (configuration?).
The reasons for this distinction would be for the network to route the message via specific AS to perform whatever services are needed for the session, for QoS management and charging. The endpoints could benefit from identifying the right application within the terminal.
As the terminal cannot be trusted to provide charging information, the network can only achieve this via disallowing participating to such services unless the terminal indicates the correct ID. And this would happen at the cost of breaking the interoperability towards legacy 3GPP IMS terminals and non-3GPP SIP terminals that are not aware of the service ID.
It was also seen that for the above purposes the service ID is to be considered as something *additional to* the usual SIP / SDP contents, not instead of it or in contradiction with it.
The 3GPP protocol requirements are defined in 3GPP TS 23.228, subclause 4.13. There was a recent change to mandate the setting of service ID when one is known to exist for the service and stating that it's not an error if multiple service identifications are included in a single request. I don't quote the whole subclause here, but instead point you to the latest change in this area in document SP-070237, which you can find here:
http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_35/Docs/ 
I hope this helps to proceed in the matter urgently. Up to now all 3GPP Rel-7 specifications are only in "work in progress" status, but the functional freeze was done already and the next SA plenary in early June 2007 is expected to freeze Rel-7, which means it should be implementable.
BR, 
Hannu Hietalahti 
3GPP TSG CT chairman 
Nokia 
http://www.nokia.com/openness/ 
________________________________________
_______________________________________________
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