dispatch R. Jesske Internet-Draft B. Dreyer Intended status: Informational M. Kreipl Expires: 17 August 2024 R. Schott Deutsche Telekom 14 February 2024 SIP Product Identifier draft-jesske-dispatch-sip-product-identifier-00.txt Abstract Complex telephony networks using SIP as signalling like the IP Multimedia Subsystem (IMS) of the Third Generation Partnership (3GPP) serving different groups of customers like business and retail customers with different products like mobile, fixed and PBX 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 17 August 2024. Jesske, et al. Expires 17 August 2024 [Page 1] Internet-Draft SIP Product Identifier February 2024 Copyright Notice Copyright (c) 2024 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 . . . . . . . . . . . . . . . . . . . . . 4 2.3. Product Identifier . . . . . . . . . . . . . . . . . . . 4 2.3.1. Applicability Statement for Product Identifier . . . 4 2.3.2. Usage of the Product Identifie . . . . . . . . . . . 5 2.3.3. Product identifier Syntax . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Telephony networks using SIP become more and more complex due to the different user accessing these networks. Operators providing services to their customers are reducing their separate networks to provide several 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 may start in different registration models via different access components and different application servers also procedures and routing may differ. Jesske, et al. Expires 17 August 2024 [Page 2] Internet-Draft SIP Product Identifier February 2024 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 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. Question is how B2BUA providing services are spread over complex networks. It can sum up to 10 or 20 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 numerous amount of SIP parameters is used to identify the correct routing. So 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 17 August 2024 [Page 3] Internet-Draft SIP Product Identifier February 2024 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 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 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 Jesske, et al. Expires 17 August 2024 [Page 4] Internet-Draft SIP Product Identifier February 2024 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 an product identifier that is not allowed for the current usage ie customer connected. ZThua the network have to take care on such requests with wrong identifiers, to save the network and customer when provding wron services or seervices which does not apply for that profile. 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 Jesske, et al. Expires 17 August 2024 [Page 5] Internet-Draft SIP Product Identifier February 2024 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 17 August 2024 [Page 6]