Internet DRAFT - draft-jesske-dispatch-sip-product-identifier
draft-jesske-dispatch-sip-product-identifier
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]
