SIP Product Identifier
draft-jesske-dispatch-sip-product-identifier-00

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,
              <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

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]