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.txt Abstract 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 Notice Copyright (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. Jesske, et al. Expires 27 September 2025 [Page 2] Internet-Draft SIP Product Identifier March 2025 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. 2. Service Use Cases 2.1. General Operators 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 token Using 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 Jesske, et al. Expires 27 September 2025 [Page 3] Internet-Draft SIP Product Identifier March 2025 200 OK (REGISTER). 2.2.2. SIP header approach In 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 Jesske, et al. Expires 27 September 2025 [Page 4] Internet-Draft SIP Product Identifier March 2025 Product-ID: "PID#1" 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 Identifier This 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. Acknowledgments The 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, . 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 Jesske, et al. Expires 27 September 2025 [Page 6] Internet-Draft SIP Product Identifier March 2025 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 7]