ETSI TR 183 056 V2.1.1 (2009-02)

Technical Report
Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN);
Feasibility study on new methods for Overlap Sending

2 ETSI TR 183 056 V2.1.1 (2009-02)

Reference
DTR/TISPAN-03111-NGN-R2
Keywords
IMS, signalling
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2009.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TR 183 056 V2.1.1 (2009-02)
Contents
Intellectual Property Rights.5
Foreword.5
Introduction .5
1 Scope.6
2 References.6
2.1 Normative references.6
2.2 Informative references.6
3 Definitions and abbreviations.7
3.1 Definitions.7
3.2 Abbreviations.7
4 Requirements and Issues .8
4.1 Requirements.8
4.2 Issues.8
4.2.1 Routing related issues: .9
4.2.2 Interrelation with number portability.9
4.2.3 Interrelation with the support of wildcard PUID .9
4.2.4 No IMS defined solutions .10
4.2.5 Overlap Scenarios supported.10
4.2.5.1 Overlap transit.10
4.2.5.2 Terminating overlap.10
4.2.5.3 Originating overlap (IMS PES).11
4.2.6 Different error responses for incomplete and unknown number.11
5 Overview of technical solutions.11
5.1 General.11
5.2 Mechanisms for the Reduction of Signalling Load .12
5.2.1 Provisioning of Number Length Information within Extension of the Error-Info Field.12
5.2.1.1 Procedures.12
5.2.1.2 Encoding.14
5.2.2 Provisioning of Number Length Information within min/max Digit MIME body .15
5.2.2.1 Procedures.15
5.2.2.2 Encoding .15
5.2.3 Digit Collection at AGCF or VGW .16
5.2.4 Provisioning of Number Length Information within the SIP Reason header .16
5.2.4.1 Procedures.16
5.2.4.2 Encoding.16
5.3 Routeing Methods for Transmitting SIP networks.16
5.3.1 Overlap signalling using SIP in-dialog messages .16
5.3.2 Multiple INVITE method .17
5.3.2.1 Call ID Extended Routeing logic .17
5.3.2.2 Use of deterministic routeing configuration.18
5.4 Interworking.19
5.4.1 Interworking between in-dialog and multiple-INVITE methods.19
5.4.1.1 General.19
5.4.1.2 Call from network supporting the in-dialog method .19
5.4.1.3 Call from network supporting the multiple-INVITE method.22
5.4.2 Interworking towards networks not supporting overlap signalling.25
5.4.2.1 Forwarding overlap signalling and handling error responses from the network not supporting
overlap in appropriate manner in originating network as specified in TS 129 163.25
6.4.2.2 Digit Collection in originating network and forwarding en-bloc signalling. .26
5.5 Impacts on other interfaces/nodes in the IMS network .26
5.5.1 I-CSCF Impacts.26
5.5.2 SLF.27
5.5.3 S-CSCF.27
ETSI
4 ETSI TR 183 056 V2.1.1 (2009-02)
5.5.3.1 Originating.27
6 Comparison of solutions.28
6.1 Comparison of Signalling load reductions mechanisms.28
6.1.1 URL method (see clause 5.2).28
6.1.1.1 Pros.28
6.1.1.2 Cons.28
6.1.2 MIME method (see clause 5.3).28
6.1.2.1 Pros.28
6.1.2.2 Cons.28
6.1.3 Digit Collection at AGCF or VGW (see clause 5.2.3).29
6.1.3.1 Pros.29
6.1.3.2 Cons.29
6.1.4 Reason method (see clause 5.2.4).29
6.1.4.1 Pros.29
6.1.4.2 Cons.29
6.1.5 Conclusions.29
6.2 Comparison of Routeing mechanisms for Transmitting SIP networks .29
6.2.0 Comparison Criteria.29
6.2.1 In Dialog method (see clause 5.5).30
6.2.2 Multiple INVITEs method (see clause 5.5 and related to clauses 5.2 and 5.3).31
6.3 Comparison of mechanisms for interworking towards networks not supporting overlap signalling.32
6.3.1 Forwarding overlap signalling and handling error responses from the network not supporting overlap
in appropriate manner in originating network.32
6.3.1.1 Pros.32
6.3.1.2 Cons.32
6.3.2 Digit Collection in originating network and forwarding en-bloc signalling. .32
6.3.2.1 Pros.32
6.3.2.2 Cons.32
6.4 Impacts of inter-working between In-Dialog and Multi-INVITE overlap methods .32
7 Final Conclusion.33
Annex A: (network option): Call ID extended Overlap Dialling Procedures.34
A.1 Actions at the originating VGW/AGCF.34
A.1.1 Terminating overlap signalling at originating VGW/AGCF .34
A.1.2 Sending of INVITE without determining the end of address signalling .35
A.1.3 Special handling of 404 Not Found and 484 Address Incomplete responses after sending of INVITE
without determining the end of address signalling .36
A.2 Actions at the terminating VGW/AGCF .37
A.3 Timers.37
Annex B: Example calculation for signalling load reduction as achieved by different
proposals.38
History .41

ETSI
5 ETSI TR 183 056 V2.1.1 (2009-02)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
Introduction
The SIP protocol has been designed for terminal types that send the address information en-bloc rather than a digit at a
time. Whilst this is not an issue for terminals such as PCs and mobile phones, this is an issue for stimulus mode
terminals such as telephones.
If the gateway controller that is controlling the access gateway for telephones, cannot determine the number length from
the initial dialled digits, the procedures for an O-IWU described in ITU-T Recommendation Q.1912.5 [i.4] and its ETSI
endorsement are either to apply a timer to collect digits or to send an INVITE message with the digits collected so far to
avoid call setup delays due to this timer. If the INVITE contains incomplete digits, a SIP proxy in the session
establishment path can return a SIP 404 "not found" or SIP 484, 'Number Incomplete Message' error response. For
instance, the I-CSCF [i.4] acting as entry point to the terminating IMS will return a 404 response. An I-IWU as
described in ITU-T Recommendation Q.1912.5 [i.4] will return a SIP 484 error response.
On receipt of the next digit the Gateway Controller may send a new INVITE with all the digits collected. If this is not
enough then it will be rejected again along with sending the 484 or 404 message. This can be repeated digit by digit,
with the session attempts progressing deeper and deeper into the network with the associated waste of signalling
bandwidth and processing.
The present document proposes a number of mechanisms that will help minimize these wasteful overheads without
impacting on the original mechanism and SIP. It also describes alternative mechanisms, one using SIP in-dialog
messages, to transport the additional digits, once an early dialog has been established with the remote SIP entity.
In addition, impacts to overlap routeing in SIP networks are also investigated.
ETSI
6 ETSI TR 183 056 V2.1.1 (2009-02)
1 Scope
The present document purpose is to investigate new methods for providing overlap sending originating from PSTN
Networks and devices. The expectation is that such methods would save on processing that the present method for
overlap sending deploys. It is also the aim of this investigation to be fully backward compatible, have no impact upon
the SIP signalling protocols, and have a minimal impact upon the existing SIP nodes.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
Not applicable.
2.2 Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
[i.1] ETSI ES 283 003: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); IP Multimedia Call Control Protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 [3GPP TS 24.229
(Release 7), modified]".
[i.2] IETF RFC 3261: "SIP: Session Initiation Protocol".
[i.3] IETF RFC 3578: "Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP)
Overlap Signalling to the Session Initiation Protocol (SIP)".
[i.4] ITU-T Recommendation Q.1912.5: "Interworking between Session Initiation Protocol (SIP) and
Bearer Independent Call Control protocol or ISDN User Part".
[i.5] ETSI TR 184 005: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Types of numbers used in an NGN environment".
ETSI
7 ETSI TR 183 056 V2.1.1 (2009-02)
[i.6] ETSI TS 129 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); LTE; IP Multimedia (IM) Subsystem Cx and Dx
Interfaces; Signalling flows and message contents (3GPP TS 29.228)".
[i.7] ETSI TS 129 229: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); LTE; Cx and Dx interfaces based on Diameter protocol;
Protocol details (3GPP TS 29.229)".
[i.8] ETSI TS 129 163: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); LTE; Interworking between the IP Multimedia (IM) Core
Network (CN) subsystem and Circuit Switched (CS) networks (3GPP TS 29.163)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
deterministic routing: routeing method ensuring that subsequent INVITE requests for the same call are forwarded to
the same next hop
Incoming Interworking Unit (I-IWU): As defined in ITU-T Recommendation Q.1912.5 [i.4].
Outgoing Interworking Unit (O-IWU): As defined in ITU-T Recommendation Q.1912.5 [i.4].
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACK ACKnowledge
AGCF Access Gateway Control Function
AGW Access GateWay
AS Application Server
B2BUA Back-to-Back User Agent
BGCF Border Gateway Control Function
BICC Bearer Independent Call Control
CSCF Call Server Control Function
DDI Direct Dialling In
DNS Directory Name Server
DTMF Dual Tone Multi Frequency
ENUM Electronic Number
IAM Initial Address Message
IBCF Interconnect Border Control Function
I-CSCF Interrogating - CSCF
ID IDentity
IETF Internet Engineering Task Force
I-IWU Incoming Interworking Unit
IMS IP Multimedia Subsystem
INFO Information message
ISUP ISDN User Part
ITU-T International Telecommunications Union - Telephony
MGC Media Gateway Controller
MGCF Media Gateway Control Function
MIME Multipurpose Internet Mail Extensions
NICC Network Interoperability Consultative Committee
O-IWU Outgoing Interworking Unit
OS-IWF Overlap Signalling Interworking Function
PBX Private
PC Personal Computer
ETSI
8 ETSI TR 183 056 V2.1.1 (2009-02)
P-CSCF Proxy CSCF
PES PSTN Emulation Subsystem
PSTN Public Service Telephony Network
PUID Public User Identity
S-CSCF Serving CSCF
SDP Service Description Protocol
SIP Session Initiation Protocol
SLF Server Local Function
S-CSCF Service Call Server Control Function
ST Signal Termination
TrGW Trunking GateWay
UAC User Agent Client
UE User Equipment
URI Uniform Resource Identifier
VGW Voice Gateway
XML eXtensible Markup Language
4 Requirements and Issues
4.1 Requirements
1) The use of the new overlap signalling mechanism(s) minimize the additional signalling and processing load.
2) Any new overlap signalling mechanism is to be fully backward compatible with the overlap Release 1 SIP
mechanism as described in RFC 3578 [i.3].
3) The entities collecting digits within the IMS network should be able to distinguish between unknown and
incomplete numbers.
4) Routeing Database requirements:
- There needs to be a mechanism in the database to handle an incomplete string, and the means of
signalling a unique response for a valid incomplete string.
- Support of a minimal length for the N(S)N part of Tel-URIs and "Types of Numbers" as drafted in
TR 184 005 [i.5], should only apply to numbers starting with country codes for countries that support
overlap dialling.
5) For the mechanism(s) based on RFC 3578 [i.3] and Q.1912.5 [i.4] every node in a network supporting overlap
signalling ensures that subsequent INVITE requests for the same call are forwarded to the same next hop as
the previous INVITE.
6) Networks supporting overlap and interfacing to networks that do not support overlap signalling will have to
interoperate with theses networks. Networks that do not support SIP overlap signalling will then be unaffected
when interworking with networks using SIP overlap dialling.
7) Networks supporting only specific overlap scenarios only need to implement the overlap extensions needed for
these scenarios.
8) The solution for overlap sending will not cause any unnecessary impacts on systems not directly concerned
with the use of overlap or en-bloc sending.
9) In the PES network the service level provided to the user should not be dependent on using overlap or en-bloc
sending.
4.2 Issues
The point when overlap sending required is assumed by the present document however this decision is made is outside
the scope of the present document and needs to be documented elsewhere.
ETSI
9 ETSI TR 183 056 V2.1.1 (2009-02)
4.2.1 Routing related issues:
1) When the S-CSCF or routing functions query ENUM, it needs to identify a valid incomplete string:
- Issue 1a: Separate entries are required in the database for each valid incomplete string.
Conclusion:
• An incomplete digit string may still be a valid entry for the routeing database, assuming that a routeing
decision based on this entry can be made:
- Issue 1b: The means of signalling a unique response for a valid incomplete string is required.
Conclusion:
• If an incomplete string is provisioned as a valid database entry, then the routing decision can be made. In this
case the session setup is progressed to the next hop and no SIP response is generated by the routing hop.
2) Deterministic routing is recommended based on text in ITU-T Recommendation Q.1912.5 [i.4] and
RFC 3578 [i.3]. RFC 3578 [i.3], paragraph 3.1 "One vs. Several Transactions":
- Issue 2a: All intermediate routing entities such as Application Servers, I-MGCF, Terminating UE and
terminating S-CSCF all need to route deterministically and therefore route the INVITE requests to the
same next hop.
NOTE: This is primarily an issue when routing to an MGCF, because multiple MGCFs may support routing to
the same final destination in the SIP to ISUP direction, there may be a need to associate caller id etc with
the IP addresses, etc. and different MGCF may be reached for reach new .SIP invite setup.
Conclusion:
• Only the entities that further propagate received overlap address information need to support the call-id
correlation. Terminating entities apply the normal terminating procedures:
- Issue 2b: Application Servers, I-MGCF, Terminating UE and terminating S-CSCF need to identify that
subsequent INVITE requests with the same call ID are related.
The BGCF needs to be able to identify a valid incomplete string for numbers not in ENUM (after ENUM query failure
before the BGCF is reached).
4.2.2 Interrelation with number portability
• Issue 3: At the point at which number porting information is retrieved, to enable portability in the DDI
enterprise cases, in the normal case is that you cannot port until the full number is received.
NOTE: It is not decided yet whether Number Portability is supported in TISPAN R2.
Conclusion:
• It could be necessary first to collect all digits transmitted in the overlap mode before a valid portability
response can be received.
On the other side the database of a number portability server could also include incomplete numbers like it is in
Germany where blockbuilding is done. Also PBX users cannot be forced to store their PBX dialling schema in an
official database. So for routing purposes the answer given for issue 1a is valid.
4.2.3 Interrelation with the support of wildcard PUID
• Issue 4: The network needs to deliver a valid incomplete strings owned by IP PBX networks, that enable a
IP PBX UE to setup to another part of the PBX network UE across the public NGN. E.g. S-CSCF and
Application Servers will need to deliver valid incomplete strings to PBXs.
NOTE: It is not decided yet whether wildcard PUID is supported in TISPAN R2. However, deferring to TISPAN
R3 is not a feasible option, as the support of wildcard PUID is needed to support PBX in TISPAN R2.
ETSI
10 ETSI TR 183 056 V2.1.1 (2009-02)
Conclusion:
• The routing based on wildcard PUIDs is the same as on an incomplete numberstring.
4.2.4 No IMS defined solutions
Historically the defined procedures for the overlap sending and receiving are focusing on the interworking elements
only. The IMS core was not taken in to account. This leads to the following problem (see figure 4.2.4-1) if no additional
procedures are defined for the support of the overlap by IMS. The subsequent INVITE may get routed to the different
MGC due to the load sharing policies, or any other routing decisions made by the core IMS.
x-CS CF /
VG W
MGC1 MGC2
AS
DTMF 1
INVITE 1
484/404 (1)
ACK
DTMF 2
INVITE 12
DTMF 3
INVITE 123
INVITE 123
IAM 123
484/404 (12)
ACK
DTMF 4
INVITE 1234
INVITE 1234
IAM 1234
Figure 4.2.4-1
4.2.5 Overlap Scenarios supported
The impacts on IMS and IMS-PES network entities and functions depend on the supported overlap scenarios. This
clause defines three cases of overlap support. For example, an IMS network may only support overlap for transit calls.
In all the scenarios reflected in the following clauses, the same basic principle should apply: the first network able to
resolve the overlap signalling conversion, either totally or partially, is responsible for such conversion.
4.2.5.1 Overlap transit
In this scenario, the terminating subscriber is not known to the IMS network, and the call is not routed via the S-CSCF.
The transit function(s) within the network route the call towards the next network.
The transit network can choose to perform full en-bloc conversion, or perform partial conversion and forward the call
towards the next network once enough digits have been received in order to find the next network.
NOTE: If the next network does not support overlap, full en-bloc conversion is performed by the (transit) IMS
network.
4.2.5.2 Terminating overlap
In this scenario, the terminating subscriber is registered to the terminating IMS/IMS PES network. The call enters the
terminating network from a PSTN network (via a MGCF), or from another IMS/IMS PES network (via IBCF). The
terminating subscriber uses the DDI service, but the additional digits for DDI are not relevant to identify the subscriber
for the purpose of the service logic in the IMS network or to route the call towards the subscriber through the IMS
based network.
ETSI
11 ETSI TR 183 056 V2.1.1 (2009-02)
The terminating IMS/IMS-PES network will perform full en-bloc conversion when the network knows the numbering
length of the terminating subscriber.
For IMS PES, in the particular case of subscribers with a DDI service, there may be scenarios where the IMS PES
network does not know the full length of the number. In such a case, the IMS PES will perform partial en-bloc
conversion required to perform the service logic in accordance to the subscription, and forward the call once enough
digits have been received in order to identify the terminating subscriber (AGCF).
NOTE 1: Currently there are no requirements to support overlap for IP-PBXs, so the current assumption is that DDI
services are provided by IMS PES via an AGCF. If there is a requirement to support overlap for IP-PBXs,
it is handled separate from cases handled via an AGCF.
NOTE 2: The AGCF/VGW is an IMS PES entity.
4.2.5.3 Originating overlap (IMS PES)
The originating IMS-PES network (the overlap comes via an AGCF) can choose to perform full en-bloc conversion, or
perform partial conversion and forward the call towards the next network (which could be the same physical IMS
network although in the context of overlap should be seen as a different logical network, and the transit or terminating
overlap case applies) once enough digits have been received in order to identify the next network.
NOTE: If the next network does not support overlap the originating IMS-PES network performs full en-bloc
conversion.
4.2.6 Different error responses for incomplete and unknown number
SIP proxies, which require a minimum number of digits to forward the call, such as a node performing a routeing
decision or the I-CSCF at the B-side that looks up the S-CSCF assigned to the request URI in the SLF, return an error
response when receiving an INVITE with insufficient digits. According to current procedures in TS 129 229 [i.7], the
SLF does not keep apart unknown and uncomplete numbers and the I-CSCF will therefore reply with the generic
404 response. The procedures could be modified by identifying uncomplete numbers. The Cx interface would need to
allow the SLF to return different results for uncomplete and unknown numbers so the I-CSCF can generate a
484 response as appropriate, in order for the MGCF to continue overlap timing or to reject the call immediately.
According to ITU-T Recommendation Q.1912.5 [i.4] the receipt of a 404 response would trigger an ISUP REL message
to the PSTN/ISDN side of the gateway.
According to TS 129 163 [i.8] the receipt of a 404 response could, when overlap is used, be treated in the manner as the
receipt of a 484 response i.e. a timer Ti/w3 is started and the gateway will await receipt of further digits.
Separate 404/484 processing would apply to all nodes collecting digits for overlap sending.
The advantage of different processing is that sessions can be rejected quicker e.g. a 404 response would trigger an
immediate release.
5 Overview of technical solutions
5.1 General
The following clauses describe different mechanism alternatives, and IMS entity impacts, related to SIP overlap
signalling:
• Mechanisms to indicate minimum number of digits needed by the network to forward the call, in order to
reduce signalling load by not sending digits until the minimum number of digits are available.
• Mechanisms to transport additional digits in the IMS network.
• Mechanism to interwork between different overlap transport mechanisms and networks that do not support
overlap.
ETSI
12 ETSI TR 183 056 V2.1.1 (2009-02)
5.2 Mechanisms for the Reduction of Signalling Load
5.2.1 Provisioning of Number Length Information within Extension of the
Error-Info Field
5.2.1.1 Procedures
Upon receipt of an INVITE request with incomplete digits, some SIP proxy or B2BUA identifies that the number is
uncomplete, looks up information about a minimum number length as derived from the digits received in the INVITE,
and then rejects the INVITE request using a SIP 484 error response that encodes this information about a minimum
number length.
The SIP proxy could be:
1) The caller's S-CSCF that will need to take a routing decision based upon request URI. While the routeing
procedure is not fully standardized in TS 129 229 [i.7], this specification lists as a typical example that the
S-CSCF applies ENUM to query an external database to transform a Tel URI into a SIP URI including a host
portion for that purpose and then uses the host portion of the SIP URI for routeing.
2) An AS attached to the caller's S-CSCF, which could also use ENUM for the same purpose as described under
bullet 1.
3) An IBCF at the interconnection between the caller's and the callee's network.
4) The callee's I-CSCF, which needs to interact with the SLF to identify the S-SCSF of the called user and
requires the complete number for that purpose.
The min length information would allow the original gateway controller to optionally withhold sending further
SIP INVITE until the minimum number length is accumulated, thus removing an ineffective SIP INVITE that may have
been sent before that number length were reached.
This process may be repeated if the session establishment progressed to another SIP Proxy that recognized that even
more digits were required.
Figures 5.2-1 and 5.2-2 show example callflows. These figures also assume some digit collection functionality as
described in clause 5.2.3 for the first digits at the VGW.
ETSI
13 ETSI TR 183 056 V2.1.1 (2009-02)

Figure 5.2.1.1-1: Example of overlap communication including min number length information
provisioned by S-CSCF A and I-CSCF B
1-3: Analogue Phone is dialling the first digits.
4-5: A initial INVITE is sent towards the S-CSCF. The S-CSCF looks up the routeing database and
obtains information about the min Length of Digits required to route the call.
ETSI
14 ETSI TR 183 056 V2.1.1 (2009-02)
6-7: A 484 including the minimum number of digits required is sent back.
8-11: The VGW is collecting the further needed digits to reach the minimum of needed numbers.
12-14: The following INVITE includes the Request URI including all digits collected so far. The S-CSCF
has now the information to route the call.
15-16: The INVITE is forwarded to the terminating network.
17: The I-CSCF selects the S-CSCF assigned to the terminating user. If the numbers is incomplete, the
I-CSCF sends a 484 to request further digits, encoding the required number of digits within.
18-21: A 484 with the information about the minimum number of digits required is sent back towards the
originating VGW.
22-25: The VGW is collecting the further digits needed.
26-32: The INVITE containing all numbers requested is sent towards the destination. The terminating I-
CSCF and S-CSCF can route upon the delivered numbers towards UE-B.

Figure 5.2.1.1-2: Example of overlap communication including min number length information
provisioned by overlap AS
5.2.1.2 Encoding
One encoding proposal is to use the existing Error-Info SIP header field as defined in RFC 3261 [i.2], which can be
optionally used by any SIP proxy that rejects a SIP INVITE with the response '484'. When sending a 484 response, a
SIP proxy can optionally include this Error-Info SIP header field according to the profile endorsed by ETSI TISPAN
in ES 283 003 [i.1].
The error-info field is intended to carry a URI which points to where further information can be found on the minimum
numbers required at this point in the network. This URI can point to an announcement server or a HTTP URI to a web
page.
ETSI
15 ETSI TR 183 056 V2.1.1 (2009-02)
The URI could encode the min length information as parameters to the URI. The format of the URI parameters needs to
be standardized and be suitable for an automatic access by the AGCF or VGW.
As an example in the UK it is proposed to profile this field to point to an NICC web page with a parameter that
indicates the minimum number length to be displayed. A PSTN call server, with an AGCF serving overlap sending lines
would recognize this URI and directly read the parameter field without referencing to any announcement servicer or
web page (see figure 5.2-2). However it is also proposed that a web pages exist that would produce an appropriate
display in a web browser should an appropriate terminal (e.g. PC soft phone) with access to the public internet, made a
call to the PSTN with insufficient digits.
A reject to an INVITE could be optionally constructed as:
SIP/2.0 484 Address Incomplete
Via: ….
Via:…….
To: ……
From:…………
Call-ID:………
CSeq:………
Content-Length: …….
Error-Info: http://www.etsi.tispan.org/SIPErrInfoExtns?MinNumLen=nn

Where nn is the total minimum number length as recognized by the rejecting SIP node.
E.g. where an INVITE with 6 digits was sent and it was recognized that another 5 were required to get a complete
address then MinNumLen=11.
This proposal does not change any of the SIP protocol and is backwards compatible with implementations that do not
recognize this profile. Therefore it does not need approval from the IETF and such a mechanism also has advantage in
working with international calls.
5.2.2 Provisioning of Number Length Information within min/max Digit
MIME body
5.2.2.1 Procedures
See clause 5.2.1.1.
5.2.2.2 Encoding
An encoding proposal is to standardize a MIME type containing the min length. When sending a 484 response, a SIP
proxy can optionally include this MIME type as body of the SIP message.
Preferably, the MIME type contains XML contents. This XML body can be used to provide a minimum number length
indication as recognized by the rejecting SIP proxy.
A reject to an INVITE could be optionally constructed as:-
SIP/2.0 484 Address Incomplete
Via: ….
Via:…….
To: ……
From:…………
Call-ID:………
CSeq:………
Content-Length: …….
Media type name: application
Media subtype name: OVERLAP
Min-length …xx
Where xx is the total minimum number length as recognized by the rejecting SIP/IMS node.
E.g. where an INVITE with 6 digits was sent and it was recognized that another 5 were required to get a complete
address then Min-Length=11.
ETSI
16 ETSI TR 183 056 V2.1.1 (2009-02)
This proposal does not change any of the SIP protocol and is backwards compatible with implementations that do not
recognize this profile. Therefore it does not need approval from the IETF and such a mechanism also has advantage in
working with international calls.
5.2.3 Digit Collection at AGCF or VGW
Although an AGCF or VGW will not be able to determine the end of dialling without applying unacceptable long timers
in all cases, the AGCF/VGW may apply similar procedures as already implemented in some current local ISUP
exchanges at the caller's side to reduce the overlap signalling load:
• collect a fixed minimum number of digits before sending the first invite; or
• implement an incomplete numbering plan that contains information about the minimum number of digits for
different destinations (e.g. keeping apart local, national and international calls, or discriminating different
cities in the country);
• use short digit collecting timer (e.g. 1 s) to collect digits typed in as a sequence without any unusual interrupts.
On expiry of this timer a new INVITE will be sent and digit collection will continue.
The applied fixed minimum number of digits or incomplete numbering plan will need to be harmonized with the routing
data
...