T Rec Q.1912.5 200403 I!!pdf e
T Rec Q.1912.5 200403 I!!pdf e
T Rec Q.1912.5 200403 I!!pdf e
ITU-T Q.1912.5
TELECOMMUNICATION (03/2004)
STANDARDIZATION SECTOR
OF ITU
Summary
This Recommendation defines the signalling interworking between the Bearer Independent Call
Control (BICC) or ISDN User Part (ISUP) protocols and SIP in order to support services that can be
commonly supported by BICC or ISUP and SIP-based network domains.
Source
ITU-T Recommendation Q.1912.5 was approved on 12 March 2004 by ITU-T Study Group 11
(2001-2004) under the ITU-T Recommendation A.8 procedure.
NOTE
In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
telecommunication administration and a recognized operating agency.
Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain
mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the
Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some
other obligatory language such as "must" and the negative equivalents are used to express requirements. The
use of such words does not suggest that compliance with the Recommendation is required of any party.
ITU 2004
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the
prior written permission of ITU.
1 Scope
This Recommendation defines the signalling interworking between the Bearer Independent Call
Control (BICC) or ISDN User Part (ISUP) protocols and Session Initiation Protocol (SIP) with its
associated Session Description Protocol (SDP) at an Interworking Unit (IWU). ISUP is defined in
accordance with ITU-T Recs Q.761 to Q.764 and BICC is defined in accordance with ITU-T
Recs Q.1902.1 to Q.1902.4. SIP and SDP are defined by the IETF. The capabilities of SIP and SDP
that are needed to interwork with BICC or ISUP are defined in Annex C.
An IWU may be stand-alone or may be combined with an ISUP exchange or BICC Interface
Serving Node (ISN). It is assumed in this Recommendation that the initial service requests are
forwarded and/or delivered via a trusted Adjacent SIP Node (ASN) within a SIP network domain.
The ASN is viewed as a trusted network entity rather than untrusted user entity, and thus the
interface between the IWU and the ASN is a Network-to-Network interface (NNI). Where Profile C
(SIP-I) is used, it is assumed that the remote SIP User Agent is able to process ISUP. Support for
SIP interworking at a User Network Interface (UNI) is out of scope of this Recommendation.
Interworking with forking in the SIP network is not specified in this Recommendation and is for
further study.
The services that can be supported through the use of the signalling interworking are limited to the
services that are supported by BICC or ISUP and SIP-based network domains. Services that are
common in SIP and BICC or ISUP network domains will interwork by using the function of an
Interworking Unit (IWU). The IWU will also handle (through default origination or graceful
termination) services or capabilities that do not interwork across domains.
The scope of this Recommendation is shown in Figures 1 and 2, respectively.
Figure 1 shows the scope of interworking between SIP and ISUP.
Items relating to security when interworking between two signalling systems in this
Recommendation are for further study.
2 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the
currently valid ITU-T Recommendations is regularly published. The reference to a document within
this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
– All IETF Standards Track RFC directly referenced by this Recommendation are listed in
Annex C.1.
– ITU-T Recommendation Q.731.7 (1997), Stage 3 description for number identification
supplementary services using Signalling System No. 7: Malicious call identification
(MCID).
– ITU-T Recommendation Q.732.2 (1999), Stage 3 description for call offering
supplementary services using Signalling System No. 7: Call diversion services: Call
forwarding busy, call forwarding no reply, call forwarding unconditional, call deflection.
– ITU-T Recommendation Q.732.3 (1993), Stage 3 description for call offering
supplementary services using Signalling System No. 7: Call forwarding no answer.
– ITU-T Recommendation Q.732.4 (1993), Stage 3 description for call offering
supplementary services using Signalling System No. 7: Call forwarding unconditional.
– ITU-T Recommendation Q.732.5 (1993), Stage 3 description for call offering
supplementary services using Signalling System No. 7: Call deflection.
– ITU-T Recommendation Q.732.7 (1996), Stage 3 description for call offering
supplementary services using Signalling System No. 7: Explicit call transfer.
3 Definitions
For BICC or ISUP specific terminology, reference shall be made to ITU-T Rec. Q.1902.2. For SIP
and SDP specific terminology, reference shall be made to RFC 3261 and RFC 2327 respectively.
Definitions for additional terminology used in this interworking Recommendation are as follows:
3.1 incoming or outgoing: This term is used in this Recommendation to indicate the direction
of a call (not signalling information) with respect to a reference point.
4 Abbreviations
This Recommendation uses the following abbreviations:
General
ABNF Augmented Backus-Naur Form (see RFC 2234)
AMR Adaptive Multirate (codec)
ASN Adjacent SIP Node
ATM Asynchronous Transfer Mode
B2BUA Back-to-Back User Agent
BICC Bearer Independent Call Control
BC-IWF Bearer Control-Interworking Function
BNC Backbone Network Connection
BNF Backus-Naur Form
CC Country Code
CLI Calling Line Identification
CONN CONNECT message (see ITU-T Rec. Q.931)
DISC DISCONNECT message (see ITU-T Rec. Q.931)
FFS For further study.
IANA Internet Assigned Numbers Authority
IETF Internet Engineering Task Force
I-IWU Incoming (to BICC/ISUP) InterWorking Unit
IPBCP Internet Protocol Bearer Control Protocol
ISDN Integrated Services Digital Network
ISN Interface Serving Node
ISUP ISDN User Part
IWU InterWorking Unit
MIME Multi-purpose Internet Mail Extensions
NDC National Destination Code
NNI Network-to-Network Interface
O-IWU Outgoing (from BICC/ISUP) InterWorking Unit
PSTN Public Switched Telephone Network
PT Payload Type
RFC Request For Comments
RTP Real-time Transport Protocol
SCCP Signalling Connection Control Part
SDP Session Description Protocol
SIP Session Initiation Protocol
SIP-I SIP with encapsulated ISUP
SN Subscriber Number
TLS Transport Layer Security
→
INVITE→ →
IAM→
Request-URI Called Party Number
userinfo
Address Signals
(sip: URI with user = phone)
Bits/Codes Meaning
0000 1010 "Ordinary calling subscriber"
For Profile C (SIP-I) the Calling Party's Category value shall be generated from the Calling Party's
Category parameter present in the encapsulated ISUP.
Other fields in the Nature of Connection Indicators should follow the current BICC/ISUP
Recommendation.
The codes in Table 4 should be set by the I-IWU as default in the Nature of Connection Indicators
parameter fields:
For Profile C (SIP-I), with the exception of Continuity Indicator (BICC)/Continuity Check Indicator
(ISUP) which receives a special treatment in 6.1.1 and 6.1.2, the Nature of Connection Indicators
should be generated by the I-IWU using the Nature of Connection Indicators received in the
encapsulated IAM message.
6.1.3.4 Forward Call Indicators (mandatory)
The indicators of the FCI parameter which are set by the I-IWU, are as follows:
Other fields in the FCI parameter should follow the current BICC/ISUP Recommendation.
For Profile A, the indicator values in Table 5 should be set by the I-IWU as default in the FCI
parameter:
image udptl t38 N/A or up to 64 kbit/s Based on T.38 "3.1 kHz audio" "3.1 kHz audio" "Facsimile
Group 2/3"
image tcptl t38 N/A or up to 64 kbit/s Based on T.38 "3.1 kHz audio" "3.1 kHz audio" "Facsimile
Group 2/3"
NOTE 1 – In this table, the codec G.711 is used only as an example. Other codec is possible.
NOTE 2 – CLEARMODE has not yet been standardized; and its usage is FFS.
NOTE 3 – HLC is normally absent in this case. It is possible for HLC to be present with the value "Telephony", although 6.3.1/Q.939 indicates that this would normally be
accompanied by a value of "Speech" for the Information Transfer Capability element.
Table 10/Q.1912.5 – Mapping of SIP From header field to BICC/ISUP Generic Number
("additional calling party number") parameter (network option)
Source SIP header Source
Generic Number
field and component Derived value of parameter field
parameter field
component value
– – Number Qualifier "additional calling party number"
Indicator
From, userinfo CC Nature of Address If CC is equal to the country code
component of URI Indicator of the country where I-IWU is
assumed to be in located AND the next BICC/ISUP
form node is located in the same
"+" CC + NDC + SN country, then set to "national
(significant) number" else set to
"international number"
– – Number Incomplete "complete"
Indicator
– – Numbering Plan Indicator "ISDN (Telephony) numbering
plan (Recommendation E.164)"
– – Address Presentation Use same setting as for calling
Restricted Indicator party number.
(APRI)
– – Screening Indicator "user provided, not verified"
From, userinfo CC, NDC, SN Address Signals If NOA is "national (significant)
component assumed number" then set to
to be in form NDC + SN.
"+" CC + NDC + SN
If NOA is "international number"
then set to CC + NDC + SN
When Profile C (SIP-I) is applicable, the Connect message is encapsulated in a 200 OK INVITE
final response.
When Profile C is applicable, the Answer message is encapsulated in a 200 OK INVITE final
response.
REL →
SIP Message →
Cause Indicators parameter
BYE Cause Value No. 16 (normal call clearing)
CANCEL Cause Value No. 31 (normal, unspecified)
On receipt of REL before receiving ANM or CON, the I-IWU shall send the appropriate SIP status
code in a final response to the SIP peer. See Table 21 for the mapping from BICC/ISUP Cause
Value to SIP status code. BICC/ISUP Cause Value not appearing in Table 21 shall have the same
mapping as the appropriate Q.850 class defaults.
For Profile C (SIP-I), the appropriate SIP status code of the SIP response that encapsulates the REL
message should be the same as the default mapping shown in Table 21 for Profiles A and B.
← REL
← SIP Message
Cause Indicators parameter
404 Not Found Cause Value No. 1 ("unallocated (unassigned) number")
500 Server Internal Error Cause Value No. 2 ("no route to network")
500 Server Internal Error Cause Value No. 3 ("no route to destination")
500 Server Internal Error Cause Value No. 4 ("Send special information tone")
404 Not Found Cause Value No. 5 ("Misdialled trunk prefix")
500 Server Internal Error (SIP-I only) Cause Value No. 8 ("Preemption")
500 Server Internal Error (SIP-I only) Cause Value No. 9 ("Preemption-circuit reserved for
reuse")
486 Busy Here Cause Value No. 17 ("user busy")
480 Temporarily unavailable Cause Value No. 18 ("no user responding")
480 Temporarily unavailable Cause Value No. 19 ("no answer from the user")
480 Temporarily unavailable Cause Value No. 20 ("subscriber absent")
480 Temporarily unavailable Cause Value No. 21 ("call rejected")
410 Gone Cause Value No. 22 ("number changed")
No mapping Cause Value No. 23 ("redirection to new destination")
480 Temporarily unavailable Cause Value No. 25 ("Exchange routing error")
502 Bad Gateway Cause Value No. 27 ("destination out of order")
484 Address Incomplete Cause Value No. 28 ("invalid number format (address
incomplete"))
500 Server Internal Error Cause Value No. 29 ("facility rejected")
← REL
← SIP Message
Cause Indicators parameter
480 Temporarily unavailable Cause Value No. 31 ("normal, unspecified")
(Class default)
486 Busy here if Diagnostics Indicator Cause Value in the Class 010 (resource unavailable,
includes the (CCBS indicator = "CCBS Cause Value No. 34)
possible")
else 480 Temporarily unavailable
500 Server Internal Error Cause Value in the Class 010 (resource unavailable,
Cause Value No. 38-47)
(47 is class default)
500 Server Internal Error Cause Value No. 50 ("requested facility not subscribed")
500 Server Internal Error (SIP-I only) Cause Value No. 55 ("incoming calls barred within CUG")
500 Server Internal Error Cause Value No. 57 ("bearer capability not authorized")
500 Server Internal Error Cause Value No. 58 ("bearer capability not presently
available")
500 Server Internal Error Cause Value No. 63 ("service or option not available,
unspecified")
(Class default)
500 Server Internal Error Cause Value in the Class 100 (service or option not
implemented Cause Value No. 65-79)
(79 is class default)
500 Server Internal Error (SIP-I only) Cause Value No. 87 ("user not member of CUG")
500 Server Internal Error Cause Value No. 88 ("incompatible destination")
500 Server Internal Error (SIP-I only) Cause Value No. 90 ("Non-existent CUG")
404 Not Found Cause Value No. 91 ("invalid transit network selection")
500 Server Internal Error Cause Value No. 95 ("invalid message, unspecified")
(Class default)
500 Server Internal Error Cause Value No. 97 ("Message type non-existent or not
implemented")
500 Server Internal Error Cause Value No. 99 ("information element/parameter
non-existent or not implemented")
480 Temporarily unavailable Cause Value No. 102 ("recovery on timer expiry")
500 Server Internal Error Cause Value No. 103 ("Parameter non-existent or not
implemented, passed on")
500 Server Internal Error Cause Value No. 110 ("Message with unrecognized
parameter, discarded")
500 Server Internal Error Cause Value No. 111 ("protocol error, unspecified")
(Class default)
480 Temporarily unavailable Cause Value No. 127 ("interworking, unspecified")
(Class default)
REL →
← SIP Trigger event
Cause Indicators parameter
484 Address Determination that insufficient digits are Not applicable.
Incomplete received. See Note in 6.1.
Receipt of subsequent INVITE within
overlap procedure, see 6.2.
480 Temporarily Congestion at the IWU. Not applicable.
Unavailable
BYE BICC/ISUP procedures result in release According to BICC/ISUP
after answer. procedures.
500 Server Internal Call release due to the BICC/ISUP According to BICC/ISUP
Error compatibility procedure (Note) procedures.
484 Address Call release due to expiry of T7 within According to BICC/ISUP
Incomplete the BICC/ISUP procedures procedures.
480 Temporarily Call release due to expiry of T9 within According to BICC/ISUP
Unavailable the BICC/ISUP procedures procedures.
480 Temporarily Other BICC/ISUP procedures result in According to BICC/ISUP
Unavailable release before answer procedures.
NOTE – If the I-IWU receives unrecognized ISUP or BICC signalling information and determines
that the call needs to be released based on the coding of the compatibility indicators, then
see 2.9.5.2/Q.764 and 13.4.3/Q.1902.4.
→
IAM→ →
INVITE→
Called Party Number Request-URI (see 7.1.2 and 7.2)
To (see 7.1.2)
Calling Party Number P-Asserted-Identity (see 7.1.3)
Privacy (see 7.1.3)
From (see 7.1.3)
Generic Number ("additional calling party number") From (see 7.1.3)
Hop Counter Max-Forwards (see 7.1.4)
TMR/USI Message Body (application/SDP) (see 7.1.1)
ISUP Message Message Body (application/ISUP) (Note)
NOTE – Profile C only. See 5.4.1.2
Has a Generic Number ("additional calling party number") with a complete E.164 number, with
Screening Indicator = "UPVP", and with APRI = "presentation allowed" been received?
Nature of "national (significant) addr-spec Add CC (of the country where the
Address Indicator number" IWU is located) to CgPN Address
Signals then map to URI
"international number" Map complete CgPN Address
Signals to URI
Table 31/Q.1912.5 – Mapping of BICC/ISUP APRIs into SIP Privacy header field
BICC/ISUP Value SIP Value
Parameter/field component
Calling Party Number Privacy priv-value
header field
APRI "presentation priv-value "id"
(See Table 27 to determine restricted" ("id" included only if the
which APRI to use for this P-Asserted-Identity header is included
mapping) in the SIP INVITE)
"presentation priv-value Omit Privacy header
allowed" or Privacy header without "id" if other
privacy service is needed)
NOTE – When Calling Party Number parameter is received, P-Asserted-Identity header is always derived
from it as in Table 27.
The code in Table 35 shall be set by the O-IWU in the Event Information parameter on receipt of
180 Ringing.
7.7.6.1 Special handling of 484 Address Incomplete response when TOIW3 is in use
On receipt of a 484 Address Incomplete response for the current INVITE (i.e., there are no other
pending INVITE transactions for this call), if the O-IWU is configured to propagate overlap
signalling into the SIP network, the O-IWU shall not send a REL message immediately and shall
instead start timer TOIW3. The REL message shall only be sent if TOIW3 expires. If the O-IWU is not
configured to propagate overlap signalling into the SIP network, then the timer shall not be started
and the REL shall be sent immediately to the BICC/ISUP network.
7.7.6.2 Special handling of 580 Precondition Failure received in response to either an
INVITE or UPDATE
A 580 Precondition failure response may be received as a response either to an INVITE or to an
UPDATE request.
7.7.6.2.1 580 Precondition Failure response to an INVITE
Release with Cause Value, as indicated in Table 40, is sent immediately to the BICC/ISUP network.
7.7.6.2.2 580 Precondition Failure response to an UPDATE within an early dialog
Release with Cause Code 127 "Interworking" is sent immediately to the BICC/ISUP network. A
BYE request is sent for the INVITE transaction within which the UPDATE was sent.
8 Bibliography (informative)
[1] ITU-T Q-series Recommendations – Supplement 45 (2003), Technical Report TRQ.2815:
Requirements for interworking BICC/ISUP network with originating/destination networks
based on SIP and SDP.
[2] ITU-T Recommendation Q.939 (1993), Typical DSS1 service indicator codings for ISDN
telecommunications services.
A.2 Interworking BICC to/from SIP with common media bearer technology and BICC
supports "Bearer Control Tunnelling"
If both BICC and SIP networks use the same media bearer technology, there is no media
intermediary and the BICC side uses bearer control tunnelling then the following procedures apply.
For BICC CS-2, the only defined Bearer Control Protocol carried by the Bearer Control Tunnelling
mechanism is IPBCP (ITU-T Rec. Q.1990). However, the procedures below apply equally to any
future Bearer Control Protocol for which interworking with SDP and the SDP offer/answer
procedures is defined.
A.2.1 Bearer Control Interworking
A Bearer Control Interworking function is assumed to exist which performs interworking between
Bearer Control information (in the BICC Bearer Control Tunnelling information element) and SDP
message bodies (in SIP messages). For IPBCP, the procedures for this interworking function are
defined in A.3.1.
A.2.1.1 Interworking from SDP offers to BICC Bearer Control Tunnelling information
On receipt of a SIP message containing an SDP offer, the Bearer Control Interworking function is
used to generate a Bearer Control Protocol Data Unit for inclusion in a BICC message. The
particular BICC message used depends on the procedures defined below.
The procedures of RFC 3264 and RFC 3261 are used to determine the SIP message that should
contain the SDP answer corresponding to this offer. Sending of this message is delayed until a
BICC message has been received containing a Bearer Control Protocol Data Unit as described
in A.2.1.3.
A.2.1.2 Interworking from SDP answers to BICC Bearer Control Tunnelling information
On receipt of a SIP message containing an SDP answer, the Bearer Control Interworking function is
used to generate a Bearer Control Protocol Data Unit for inclusion in a BICC message. The
particular BICC message used depends on the procedures defined below.
A.2.1.3 Interworking from BICC Bearer Control Tunnelling information to SDP
On receipt of a BICC message containing a Bearer Control Protocol Data Unit, the Bearer Control
Interworking Function is used to generate an SDP offer or answer for inclusion within a SIP
message.
If the SDP is an SDP offer, then the particular SIP message used depends on the procedures defined
below.
If the SDP is an SDP answer, then the SIP message sent is as identified in A.2.1.1.
Annex B
This annex describes service interworking of ISDN supplementary services between SIP
and BICC/ISUP.
Except where otherwise stated, services in Profile C (SIP-I) operation use the parameters of the
(de)encapsulated ISUP, and no other interworking is required. Accordingly, the service
interworking descriptions below are only for Profile A and B operation unless Profile C (SIP-I) is
specifically indicated.
B.8 Interworking of Explicit Call Transfer (ECT) supplementary service to SIP networks
Profiles A and B
The IWU shall act in accordance with the procedures described within 7.7/Q.732.7, under the clause
heading "Interactions with other networks".
Profile C (SIP-I)
No additional interworking beyond use of ISUP encapsulation.
B.16 Interworking of Closed User Group (CUG) supplementary service to SIP networks
Profiles A and B
The IWU shall act in accordance with the procedures described within 1.5.2.4.2/Q.735.1, under the
clause heading "Exceptional procedures".
Profile C (SIP-I)
No additional interworking beyond use of ISUP encapsulation.
Annex C
This annex contains references to normative Internet Engineering Task Force (IETF) RFCs and
materials originally sourced from the IETF but deemed normative to this Recommendation.
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-Asserted-Identity adr – o – o o -
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-Preferred-Identity adr – o – o o -
priv-value = "id"
Example:
Privacy: id
10 Examples
10.1 Network asserted identity passed to trusted gateway
In this example, proxy.cisco.com creates a P-Asserted-Identity header field from
an identity it discovered from SIP Digest authentication. It forwards this
information to a trusted proxy which forwards it to a trusted gateway. Note that
these examples consist of partial SIP messages that illustrate only those
headers relevant to the authenticated identity problem.
Normative description:
Section 9.1 of this document
Normative description:
Section 9.2 of this document
13.2 Registration of "id" privacy type for SIP Privacy header
Appendix I
I.2 Definitions
The vertical boxes represent two entities: a BICC SN and the IWU (SIP-BICC Interworking Unit).
The vertical dashed lines represent the access interface. Each access interface supports a single
access type: ISDN or SIP-NNI.
Solid horizontal arrows represent signalling messages and indicate their direction of propagation,
i.e., to or from the interworking unit. The interaction of messages shown along the vertical represent
increasing time in the downward direction. All events on the same vertical line are related, e.g. an
incoming message causes voice-path connections and triggers an outgoing message. Events on
different vertical lines are not related unless connected by dashed lines. A dashed line indicates that
an incoming message may trigger an event at a later time.
Wavy horizontal arrows (~~>) represent tones or announcements sent in-band.
Timers are represented as vertical arrows.
For call control, the following symbols are used within the vertical boxes to indicate the relationship
between the incoming and outgoing messages and the call control action taken.
I.4 Methodology
Call flow or "arrow' diagrams are provided to show the temporal relationships between signalling
messages during execution of a call control procedure. The general format of an arrow diagram is
shown in Figure I.1.
PRACK
200 OK PRACK
I.5.1.4 Simple segmentation procedures/call flow diagrams for basic call control
Figure I.5 shows a sequence of messages for successful call set-up for an incoming call from SIP to
BICC using the segmentation procedures on the BICC side. In this example, the IWU sends the
SGM independent of a message from the SIP side, and hence there is no interworking significance.
PRACK
200 OK PRACK
Figure I.5/Q.1912.5 – Basic call set-up using segmentation procedures from SIP to BICC
I.5.2 Example scenarios for outgoing call interworking from BICC to SIP at O-IWU
I.5.2.1 Successful call set-up procedures/call flow diagrams for basic call control
I.5.2.1.1 Backwards BICC bearer setup, SIP preconditions used
Figure I.6 shows a sequence of messages for successful call set-up for an outgoing call from BICC
to SIP. In this example, the O-IWU indicates mandatory local sendrecv preconditions in the
INVITE. The O-IWU then sends the UPDATE message upon completion of bearer setup, any local
resource reservation and reception of a COT message (if the IAM indicated "COT to be expected").
The UPDATE message will confirm that local preconditions have been met. It is assumed that a SIP
Proxy will be responsible for protecting against fraudulent use of the user plane.
PRACK
200 OK PRACK
CONN ANM 200 OK INVITE
CONN ACK ACK
I.5.2.2 Unsuccessful call set-up procedures/call flow diagrams for basic call control
Figure I.7 shows a sequence of messages for unsuccessful call set-up for an outgoing call from
BICC to SIP. In this example, the O-IWU sends the REL message upon reception of the
484 Address Incomplete message from the SIP side of the call.
ISDN Access BICC SN O-IWU SIP NNI
SETUP IAM INVITE
Bearer Setup 100 Trying
CALL PROC
Bearer Accept
REL 484 Address Incomplete
DISC
REL RLC ACK
REL COMP Bearer Release Req
Bearer Release Ack
I.5.2.4 Simple segmentation procedures/call flow diagrams for basic call control
Figure I.9 shows a sequence of messages for successful call set-up for an outgoing call from BICC
to SIP using the segmentation procedures. In this example, the O-IWU sends the INVITE message
upon reception of the SGM from the BICC side of the call.
ISDN Access BICC SN O-IWU SIP NNI
SETUP IAM
CALL PROC Bearer Setup
Bearer Accept
SGM INVITE
Figure I.9/Q.1912.5 – Basic call set-up using segmentation procedures from BICC to SIP
Appendix II
II.2 Definitions
The vertical boxes represent two entities: an ISUP exchange and IWU (SIP-ISUP Interworking
Unit).
The vertical dashed lines represent the access interface. Each access interface supports a single
access type: ISDN or SIP-NNI.
Solid horizontal arrows represent signalling messages and indicate their direction of propagation,
i.e., to or from the interworking unit. The interaction of messages shown along the vertical represent
increasing time in the downward direction. All events on the same vertical line are related, e.g. an
incoming message causes voice-path connections and triggers an outgoing message. Events on
different vertical lines are not related unless connected by dashed lines. A dashed line indicates that
an incoming message may trigger an event at a later time.
Wavy horizontal arrows (~~>) represent tones or announcements sent in-band.
Timers are represented as vertical arrows.
II.3 Abbreviations
See clause 4.
II.4 Methodology
Call flow or "arrow" diagrams are provided to show the temporal relationships between signalling
messages during execution of a call control procedure. The general format of an arrow diagram is
shown in Figure II.1.
II.5.1.2 Unsuccessful call set-up procedures and call flow diagrams for basic call control
Figure II.4 shows the sequence of messages for unsuccessful call set-up for an incoming call from
SIP to ISUP. In this sequence, the I-IWU sends the 500 Server Internal Error message upon
reception of the REL message (with Cause Value No. 34 (resource unavailable)) from the ISUP side
of the call.
II.5.2 Example scenarios for outgoing call interworking from ISUP to SIP at O-IWU
II.5.2.1 Successful call set-up procedures and call flow diagrams for basic call control
II.5.2.1.1 SIP preconditions used
Figure II.6 shows a sequence of messages for successful call set-up for an outgoing call from ISUP
to SIP. In this example, the O-IWU indicates mandatory local sendrecv preconditions in the
INVITE. The O-IWU then sends the UPDATE message upon reception of a COT message (if the
IAM indicated "continuity check performed on previous circuit" or "continuity check required on
this circuit") and completion of any local resource reservation. The UPDATE message will confirm
that the local preconditions have been met.
PRACK
200 OK PRACK
CONN 200 OK INVITE
ANM
CONN ACK ACK
II.5.2.2 Unsuccessful call set-up procedures and call flow diagrams for basic call control
Figure II.8 shows a sequence of messages for unsuccessful call set-up for an outgoing call from
ISUP to SIP. In this example, the O-IWU sends the REL message upon reception of the 484
Address Incomplete message from the SIP side of the call.
Appendix III
Tone Generation
Through-connection of the path in the backward direction
Through-connection of the path in the forward direction
NOTE 1 – Any SIP entity along the signalling path to the I-IWU, or the I-IWU itself, may return a 100 Trying provisional response
either by configuration or because it determines that a further response will take longer than 200 ms to generate. This is a purely SIP
matter with no interworking significance, but is depicted for realism in this and subsequent figures.
NOTE 2 – ACM contained the following indicators:
Called Party Status = “subscriber free”, ISDN Access Indicator = “ISDN access”
ACM
NOTE 1 – The complete re-assembled IAM message is encapsulated in the INVITE request.
NOTE 2 – The complete re-assembled ACM message is encapsulated in the 183 provisional response.
NOTE 1 – INVITE contains the Supported header field with the option tag 100rel.
NOTE 2 – In the case of immediate sending of IAM, it will contain “COT on previous circuit” indication.
NOTE 3 – The choice between deferred IAM and COT depends on the I-IWU configuration.
Resource Reservation
PRACK
Resource Reservation
200 OK PRACK
COT
(Note 3)
IAM/
UPDATE COT SETUP
[SDP] (Note 4) CALL PROC
200 OK UPDATE
[SDP]
NOTE 1 – INVITE contains mandatory end-to-end sendrecv preconditions and the Required header field with the option tag 100rel.
NOTE 2 – In the case of immediate sending of IAM, it will contain “COT on previous circuit” indication.
NOTE 3 – COT on the originating side is optional, depending on the indication in the IAM.
NOTE 4 – The choice between deferred IAM and COT depends on the I-IWU configuration, see 6.1.2.
ACK
NOTE – REL is not encapsulated in CANCEL because the latter is a hop-by-hop request. If the O-IWU supports the Reason header
field the Cause Value is mapped to that field. See 6.11.1 and 7.7.1.
Figure III.13/Q.1912.5 – Forward release during call setup, no early dialog is established
PRACK
200 OK PRACK
REL REL BYE REL
[REL] RLC
REL COMP RLC (Note 3)
200 OK BYE
[RLC]
NOTE 1 – The ACM is not mapped from a message from the destination user. It is independently generated at the destination exchange.
NOTE 2 – The 183 Session Progress response contains the To header field tag which creates an early dialogue.
NOTE 3 – Since an early dialogue has been established, the O-IWU can release the call with a BYE rather than a CANCEL. Since BYE
is end-to-end, it can encapsulate the REL.
Figure III.14/Q.1912.5 – Forward release during call setup, early dialog is already established
SUS SUS
Case: Clear backward (Network) INFO On-hook
Time (Network)
[SUS]
out (Note)
200 OK INFO
REL
RLC RLC
REL COMP
NOTE – The transparent transport of SUS is possible only in the case of Profile C (SIP-I) operation.
RES RES
Reanswer (Network) INFO (Network) Off-hook
[ RES ]
(Note)
200 OK INFO
NOTE – The transparent transport of SUS and RES is possible only in the case of Profile C (SIP-I) operation.
Series E Overall network operation, telephone service, service operation and human factors
Series J Cable networks and transmission of television, sound programme and other multimedia signals
Series L Construction, installation and protection of cables and other elements of outside plant
Series M TMN and network maintenance: international transmission systems, telephone circuits,
telegraphy, facsimile and leased circuits
Series Y Global information infrastructure, Internet protocol aspects and Next Generation Networks
Geneva, 2004