Subject: Re: [Sipping] Use and requirements of Service ID

From: "Andrew Allen" <[email-masked]>
Date: Thu, 22 Mar 2007 06:08:15 -0400

Hannu

Just so we don't confuse further I think you meant Accept-Contact header not Contact header.

Andrew
--------------------------
Andrew Allen
Manager Standards
Research In Motion Ltd
BlackBerry Mobile  +1 847 809 8636
http://www.rim.com/

Sent from my BlackBerry Wireless Handheld

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Thu Mar 22 06:05:22 2007
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/ 

________________________________

	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:

		http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_35/Docs/ <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/>  

		________________________________

				_______________________________________________
		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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

_______________________________________________
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