dispatch R. Jesske
Internet-Draft B. Dreyer
Intended status: Informational M. Kreipl
Expires: 27 September 2025 R. Schott
Deutsche Telekom
26 March 2025
SIP Product Identifier draft-jesske-dispatch-sip-product-identifier-01.txtAbstract
Complex telephony networks using SIP signalling such as the IP Multimedia Subsystem (IMS) of the Third Generation Partnership (3GPP) serve diverse customer groups, including business and retail clients, with various products like mobile, fixed, and PBX services. Such services have the problem of different handling of the services. This may end up in a complex analysis of the signalling syntax before starting the required procedures for calls based on their service provided to the customer. With the introduction of microservice based technologies the complexity increases.
This draft describes a generic identification mechanism for SIP dialogs in using an identifier indicating the service/product which the customer is using to allow an efficient processing of the SIP dialog and session.
Status of This Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 September 2025.
Jesske, et al. Expires 27 September 2025 [Page 1]
Internet-Draft SIP Product Identifier March 2025
Copyright NoticeCopyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Service Use Cases . . . . . . . . . . . . . . . . . . . . . . 3
2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Evaluation and identification of possibl emecanisms . . . 3
2.2.1. Registration token . . . . . . . . . . . . . . . . . 3
2.2.2. SIP header approach . . . . . . . . . . . . . . . . . 4
2.2.3. Conclusion . . . . . . . . . . . . . . . . . . . . . 5
2.3. Product Identifier . . . . . . . . . . . . . . . . . . . 5
2.3.1. Applicability Statement for Product Identifier . . . 5
2.3.2. Usage of the Product Identifie . . . . . . . . . . . 5
2.3.3. Product identifier Syntax . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Telephony networks using SIP become more and more complex due to the different users accessing these networks. Operators providing services to their customers are reducing their separate networks to provide diffrent services by one and the same network. So mobile, fixed and business telephony are provided via the same network. Nevertheless there are different requirements and preconditions to be fulfilled by their network to serve the customers. This can result in varying in diffrent registration models through service specific access components and application servers, with procedures and routing potentially differing as well. To reduce the number of separate components (SIP Proxy and B2BUA) software should provide the capability to differentiate such service approaches instead of providing different networks or at least different components. This document discusses the different approaches in separating services by using protocol solutions.
Jesske, et al. Expires 27 September 2025 [Page 2]
Internet-Draft SIP Product Identifier March 2025 2. Service Use Cases 2.1. GeneralOperators deploy a network providing services to customers which have a mobile subscription, a fixed line and/or a business subscription. So for mobile services there are customers having prepaid and postpaid services. Business customers may use a cloud PBX from a service provider, have access via a value added service like an office work place including an communication/conference platform. Retail customers with a plain communication service. Also the combination of several numbers and different access types is possible like mobile and fixed. For such cases the network itself will have numerous entities providing services and functionalities. An example could be an IMS network specified by 3GPP. Such networks have a variety of access network possibilities, different application servers and also different network inter connectivities. With deploying different products on the same network the complexity will increase. Functionalities as mentioned before within the architecture will be based on the products.
The question arises how B2BUA providing services are spread over complex networks. Based on the amount of user groups this can end up in many different B2BUAs which are serving different customer groups with different services as line hunting for business customers or announcement services . For such a routing today a multiple SIP parameters is used to identify the correct routing. It would be the To/From header fields. With using a unique identifier for a specific group the routing is now easier and more efficient.
2.2. Evaluation and identification of possibl emecanisms 2.2.1. Registration tokenUsing a registration token within the contact header field may be a solution for identifying the product category for the user and can be enriched by the registrar. Stateful entities need to save the token and need to act when the token is received in the SIP INVITE. For that the SIP entity has to evaluate the contact header field and react on the embedded token. This may have some disadvantages. Also all UAs have to store such token. From current experience there are UAs which react with failures when receiving such unknown tokens in a 200 OK (REGISTER).
Jesske, et al. Expires 27 September 2025 [Page 3]
Internet-Draft SIP Product Identifier March 2025 2.2.2. SIP header approachIn using a SIP header field the identifier can be sent through the network and can be used by each entity which needs to process this information due to different service procedures. We therefore propose the use of the Product-ID SIP header field. The use of the Product ID during registration is a normal registration procedure. It may change within a Re-Register when the customer changes their used products.
SIP Register 200 OK:
200 OK SIP Server -> UA
SIP/2.0 200 OK
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92 ;received=192.0.2.201
From: Bob sip:bob@biloxi.example.com;tag=ja743ks76zlflH
To: Bob sip:bob@biloxi.example.com;tag=37GkEhwl6
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 2 REGISTER
Contact: sip:bob@client.biloxi.example.com;expires=3600
Content-Length: 0
Product-ID: "PID#1"
SIP INVITE Example: INVITE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:joe@example.com
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:bob@client.biloxi.example.com;expires=3600 Product-ID: "PID#1"
Jesske, et al. Expires 27 September 2025 [Page 4]
Internet-Draft SIP Product Identifier March 2025
The advantage in using the SIP header field is that it will be ignored by entities and UAs not knowing the header field.
2.2.3. Conclusion
Considering that the mechanism should be as generic as possible and shall not violate existing implementations the SIP header approach is the preferred one. The danger of end device incompatibility by using registration token is more dangerous than using new SIP headers which are ignored by entities if not implemented.2.3. Product Identifier 2.3.1. Applicability Statement for Product IdentifierThis mechanism is appropriate in environments where SIP services are dependent on SIP elements knowing details about the product used by the customer calling
active mode in enriching SIP with the product identifier
reactive mode by network functions having stored the product identifier on behalf of the customer
2.3.2. Usage of the Product Identifie
UA behaviour B2B UA behavior Stateless/statefull SIP server behaviour Clien server
2.3.3. Product identifier Syntax
The syntax of the Product-ID SIP header field is described as follows:Product-ID = "Product-ID" HCOLON product-id-spec
product-id-spec = (token / quoted-string) *(SEMI product-id-param) product-id-param = generic-param
3. Security Considerations
An UA may setup a product identifier that is not allowed for the current usage ie customer connected. The network has to take care of such requests with wrong identifiers, to save the network and customer when provding wrong services or services which do not apply for that profile.
Jesske, et al. Expires 27 September 2025 [Page 5]
Internet-Draft SIP Product Identifier March 2025 4. AcknowledgmentsThe author would like to acknowledge the constructive feedback provided by ....
5. References 5.1. Normative References[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
Authors' Addresses
Roland Jesske Deutsche Telekom Ida-Rhodes-Str. 2 64295 Darmstadt Germany Email: r.jesske@telekom.de URI: www.telekom.de
Bastian Dreyer Deutsche Telekom Budapester StraÃe 18 20359 Hamburg Germany Email: Bastian.dreyer@telekom.de URI: www.telekom.de
Michael Kreipl Deutsche Telekom Dieselstr. 43 90441 Nürnberg Germany Email: michael.kreipl@telekom.de URI: www.telekom.de Roland Schott Deutsche Telekom Ida-Rhodes-Str. 2 64295 Darmstadt Germany Email: roland.schott@telekom.de URI: www.telekom.de
Jesske, et al. Expires 27 September 2025 [Page 6]
Internet-Draft SIP Product Identifier March 2025
Jesske, et al. Expires 27 September 2025 [Page 7]
