Internet Engineering Task Force Young-Fu Chang
Internet Draft Lucent Technologies
draft-chang-sipping-bicc-network-00.txt
September 2001
Expires: March 2002
BICC extension of SIP in Inter-Network Configuration
STATUS OF THIS MEMO This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet- Drafts.
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.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract:
This Internet Draft describes a framework of extending SIP to support
call control across different networks. This extension encapsulates
Bearer Independent Call Control (BICC) in the SIP message to provide the
information needed across networks. Integrating both SIP and BICC
features, this extension provides service providers a vehicle to deploy
services across different administration domains and different types of
network.
1. Introduction
The capabilities of SIP provide a good foundation for integrating
various communication media into single platform [1]. To address the
needs of interworking with PSTN, the SIP-T proposal [2] supports
interworking between the PSTN network and the SIP network.
Interworking between SIP/SIP-T and BICC is also proposed [3] to address
the need of protocol interworking. However, these proposals did not
address the needs of providing SIP services in different service
domains. Two additional services should be provided for the SIP:
- A service provider should be able to control and manage the traffic
origination from its network or the traffic termination on its network.
- SIP should be extended to bridge network-to-network signaling
Chang [Page 1]
Internet Draft sipping-bicc-network September 2001
These two requirements are important to service providers when dealing
with a controlled environment in their packet networks. SIP-T [2]
provided a solution for services between service providers, however, its
scope is limited to SS7/TDM interface. On the other hand,
interworking between SIP/SIP-T and BICC [3] provided a solution to
different transport domain IP/ATM/TDM, however, it lost the SIP
services, such as redirect or web enabled service, after interworking
with another protocol.
The next section describes a general information flow model in the
network. Section 3 briefly describes BICC network components and
interfaces. Section 4 describes several basic constructs for integrating
both SIP and BICC protocols. Section 5 will discuss various supported
network configurations to validate the coverage of proposed basic
constructs. The role of SIP components, required support, and network
features are also covered in this proposal.
2. An Information Flow Model
When establishing a session between two SIP end-points, there are many
steps and information flows contributing to the connection. Using
Figure 1 as an example, User 1 starts a session to connect User 2.
This example illustrates an example of sessions that go between two SIP
networks.
|
|
Service Provider A | Service Provider B
SIP Network | SIP Network
+-----+ Session + +-----+
+--------+ |B2BUA| Network Info |B2BUA|
|Location| | X |---|--(4)---->| Y |--|
| Server | +-----+ | +-----+ |
+--------+ ^ | (5) Session
^ Location |Session| | Info
| Info (3) Info | |
(2) +-------+ | | +-------+
|--->|Proxy A|----| | |Proxy B|
+-------+ | +-------+
^ | |
Session | | (6) Session
Info (1) | | Info
| | v
+------+ | +-------+
| User1| | | User2 |
+------+ | +-------+
Figure 1. Information Flow Model in Two SIP Networks
Step 1: The session information is inserted into the message between
User 1 and Proxy A. The information at this step provides enough
information for Service Network Provider A to manage the session.
Chang [Page 2]
Internet Draft sipping-bicc-network September 2001
Information, such as Called ID, Calling ID, are provided in this step as
the interface between a user and the service provider.
When processing the session information in Step 1, Proxy A needs to find
out the translated address of the called address by going to the
Location Server.
Step 2: Translated address is obtained from Location Server. This step
provides the routing information in the network of Service Provider A.
Step 3: Deciding on the session routing, Service Provider Network A
sends the session to MGC A for a session that will go across two service
providers.
Step 4: Going between two service provider networks, this session is
augmented by additional network information between B2BUA X and B2BUA Y
B. This information flow could support the session across different
service administration domains as well different types of networks. The
information, such as network ID or billing information across networks,
helps service providers resolve the services across different networks.
On the other hand, when the session goes between two different types of
network, network components such as Media Gateways (MG) serve as the
media conversion point between two types of network. The information and procedures exchanged resolve the differences between networks.
Step 5: Resolving the network-to-network services, B2BUA Y passes on
only the session information needed by Proxy B, which hosts User 2.
Step 6: This session terminates on User 2.
The scenario described above is a typical information flow model in the
service network. The session information supports the connection between
User 1 and User 2. However, additional information is inserted into the
flow and deleted from the flow at various points in the network. It is
not practical and also inefficient to provide all the information at
once.
There are two possible approaches to support the network-to-network
information needed in the information flow model described above.
- Expand the SIP parameters and procedures to support network-to-network
information.
- Encapsulate the network-to-network protocol such as BICC in the SIP to
supplement the information needed across networks.
Encapsulating the BICC information in SIP messages has the following
advantages:
(1) It is an extension of the SIP. It inserts/deletes network
information at the edge of the network. Only the components, such as MGC
or B2BUA, at the edge of the network need to be aware of this extension.
Chang [Page 3]
Internet Draft sipping-bicc-network September 2001
(2) The BICC protocol modifies ISUP and enhances it for packet network
features. These features support many network-to-network interfaces and
extension in many countries. Supplementing the SIP with BICC
information, this framework automatically picks up the long efforts
devoted to solve the network-to-network interface.
(3) Encapsulating the BICC message in the SIP messages provides a good
way of passing BICC through a SIP network. Otherwise, the SIP network
must perform interworking from BICC to SIP and SIP to BICC.
The scope of this contribution covers Step 4, i.e., the interface
between two networks. These two networks can be the same type of
network, such as the SIP network, but are administrated by different
service providers. On the other hand, two networks can be different
types of network, e.g., SIP/BICC network. The next section introduces
some terms of the BICC network.
3. Overview of the BICC Network
+-----+ +-----+ +-----+ +-----+ +-----+
|CSF-N|<-BICC->|CSF-T|<-BICC->|CSF-C|<-BICC->|CSF-G|<-BICC->|CSF-G|
+-----+ +-----+ +-----+ +-----+ |---- |
| | | |
|CBC |CBC |CBC |
| | | |
+----+ +----+ +----+ +----+
|BIWF|<--BCP-->|BIWF|<----------BCP--------->|BIWF|<--BCP-->|BIWF|
+----+ +----+ +----+ +----+
ISN-A TSN-x CMN-x GSN-x GSN-y
Figure 2. BICC Network
Figure 2 shows various components in a BICC network.
- Call Service Function (CSF):
This functional entity supports the following service control function:
- Call Service Nodal Function (CSF-N): In an Interface Serving Node
(ISN), it supports narrowband and BICC signaling interworking.
- Call Service Transit Function (CSF-T): In a Transit Serving Node
(TSN), it establishes and maintains a network backbone call between CSF-
Ns.
- Call Service Gateway Function (CSF-G): In a Gateway Serving Node
(GSN), it establishes and maintains calls between CSF-N peers across
different networks.
- Call Service Coordination Function (CSF-C): In a CMN, it supports call
coordination and mediation.
Chang [Page 4]
Internet Draft sipping-bicc-network September 2001
- Bearer Inter-Working Function (BIWF): A functional entity supports
bearer control and media mapping switching. It performs these functions
according to the service node characteristics. The BIWF is functionally
equivalent to the Media Gateway (MG) with bearer control function.
- Bearer Independent Call Control (BICC): The BICC is the signaling at
the call control level between different service nodes.
- Call & Bearer Control (CBC): It is an interface between the CSF and
the Bearer Control Function (BCF) in the BIWF
- Bearer Control Protocol (BCP): It is the interface between BIWFs to
set up the bearer connection.
- Call Mediation Node: A functional entity provides Call Service
Coordination Function without an associated Bearer Control Function.
By separating the call control and the bearer control, the BICC network
supports different transport types with a common call control signaling
across networks. Without extending the session information in the BICC
message, current BICC network has limited capability to support various
SIP features in the network. Extending the SIP scope with the BICC gives
the SIP network a much better coverage of the network-to-network
interface in the packet network environment.
4. Information Taxonomy
4.1 Layer of Information
Figure 3 illustrates the protocol chart used when a SIP session goes
across network boundary. The BICC information is introduced when a
session goes across network boundary. The other network should process
BICC information introduced at this point. If the network is SIP-
capable, the SIP features should be supported beyond the entry point of
the other network. If the network does not have all the SIP features,
then the SIP protocol with BICC information should be terminated on the
entry point of the network.
Network
Boundary
+-----------+ |
| B2BUA | |
| +----+ | |
| |BICC| | |
SIP | |----| | |
----------| SIP|--------|---> SIP(BICC)
| +----+ | |
+-----------+ |
Figure 3. Protocol chart of SIP supplemented with BICC
Figure 4 shows another case that the BICC protocol is used between a
SIP network and the BICC network. This case uses SIP as transport
mechanism to get the BICC protocol across a SIP network. Depending on
the configuration, the SIP network may or may not have to handle bearer
interworking. Section 5 has more detailed network configurations.
Chang [Page 5]
Internet Draft sipping-bicc-network September 2001
Network Network
Boundary Boundary
| |
| +-----------+ +-----------+ |
| |B2BUA/MGC | |B2BUA/MGC | |
| | |----| | | |----| | |
BICC <--|-----|BICC| | | |BICC|-------|--> BICC
| | |----| | SIP(BICC) | |----| | |
| | |SIP |------------------| SIP| | |
| | |----| | | |----| | |
| +-----------+ +-----------+ |
Figure 4. Protocol chart of BICC transported in SIP network
Encapsulated BICC is used in Figure 3 and Figure 4. Depending on the
role of the B2BUA or MGC, both cases are supported across network
boundary.
Another model shown in Figure 5 is the Interworking Model that MGC
servers as the interworking point. This model is not within the scope
of this paper. More information of this model can be found in another contribution [7].
Network
Boundary
| +-------------+
| | MGC |
| |+----+ +---+|
BICC | ||BICC|--|SIP|| +--- ----+
--------|-|+----+ +---+|----| SIP UA |
| +-------------+ +--------+
Figure 5. SIP interworking Model
4.2. Basic Constructs
The BICC protocol has specified messages, coding, procedures, and etc.
in CS1, and CS2 documents. Mapping all the BICC information into SIP
requires mass documentation. Providing basic constructs of the mapping
is the strategy of this contribution. After supporting the basic
constructs, this framework can easily be used to derive many other
procedures.
4.2.1. Message Constructs
Table 1 lists the mapping from BICC messages into SIP messages. It is
desired that the mapping keeps the SIP semantics and BICC semantics.
Using this mapping as basic building blocks, all the BICC information
can be carried in the SIP message across the network boundary.
Chang [Page 6]
Internet Draft sipping-bicc-network September 2001
|-------------|-------|-----|-------|-----|-----|--------|------|
| SIP| INVITE| 18x | PRACK | BYE | 200 | NOTIFY | INFO |
|BICC | | | | | | | |
|-------------|-------|-----|-------|-----|-----|--------|------|
|IAM | X |
|ACM | 180 |
|Early ACM | 183 |
|CPG | 183 |
|FOT | 181 |
|ANM | X |
|CON | X |
|COT | X |
|SUS | X X |
|REL | X |
|RLC | X |
|---------------------------------------------------------------|
|Backward APM,| 183 |
|FAC,INR, SGM | |
|-------------|-------------------------------------------------|
|Forward APM, | X |
|FAC,INF,SAM, | |
|SGM | |
|-------------|-------------------------------------------------|
|CGB,CFN,CGU, | |
|CQM,GRS,RES, | |
|RSC,UCIC | X |
|---------------------------------------------------------------|
|CGBA,CGUA,CQR| |
|GRA,RSC | X |
|---------------------------------------------------------------|
Table 1. BICC messages mapped into SIP
4.2.2. Procedure Constructs
Three types of procedure constructs are described as follows:
(1) General Procedure
These procedures are for those messages have one-one mapping into SIP
messages, E.g., IAM is mapped into INVITE, and ACM is mapped into 180
or 183. All the messages in Table 1 are in this category expect those
are specified in the next two categories.
(2) Procedure for the ANM Message
For keeping the semantics of the SIP procedure, the BICC ANM message is
mapped into the SIP 200 OK message and one additional SIP ACK message as
shown in Figure 6.
Chang [Page 7]
Internet Draft sipping-bicc-network September 2001
|<--200(ANM)----|
| |
|---- ACK------>|
Figure 6. BICC ANM procedure
(3) Additional Procedure for Forward Messages
The messages using this procedure are those mapped into PRACK in Table
1. Figure 7 uses APM as an example to show the procedure.
|-- PRACK(APM)->|
| |
|<--- 200 OK ---|
Figure 7. Additional Procedure for BICC Forward Message
Using the basic constructs of message and procedure, different
variation of the BICC scenarios can be mapped into these building
blocks. The next section gives several examples of these building blocks
in a list of supported network configurations.
5. Configurations of SIP Networks
This section elaborates supported network configurations. Using these
configurations as examples, bundling of the basic constructs described
in Section 4 demonstrates a systematic approach to address various
scenarios.
5.1. Service across network boundary
When a SIP session traverses through different service providers, there
is a need to provide the information needed between service providers.
Some of the capabilities have been adopted by the SIP protocol. For the
completeness, the SIP message needs to carry information handled between
service providers. Services provided between service providers such as
transit network selection, local service provider identification,
blocking/unblocking traffic are important to service providers. BICC
adopted ISUP and enhanced the signaling to handle the packet bearer
interface. Service providers also demand a controlled external interface
so that the internal addressing and other information will not be
revealed to external networks. Figure 8 depicts the session in SIP VoIP
across different service providers. It is important to have extended
BICC interface between LEC 1 SIP network and LEC 2 SIP network so that
either network has the capability of managing traffic from/to the other
network.
Chang [Page 8]
Internet Draft sipping-bicc-network September 2001
+---------------------+ +---------------------+
| +-----+ +-----+ | SIP(BICC) | +-----+ +-----+ |
| |Proxy|<->|B2BUA|<-------------->|B2BUA|<->|Proxy| |
| | A | | X | | | | Y | | B | |
| +-----+ +-----+ | | +-----+ +-----+ |
| ^ | | ^ |
| | | | | |
| | | | | |
| LEC 1 | | | | LEC 2 |
| SIP | +----------------------+ | SIP |
|Network| | | | | | Network|
| | | | | | | |
+-------|-------|-----+ +----|-------|--------+
V V V V
+---------+ +---------+
|SIP Phone| |SIP Phone|
+---------+ +---------+
Figure 8. Extended SIP for Packet Interworking and Service Interworking
Figure 9 shows the session establishment and release between two SIP
Phones in Figure 8. It only shows messages exchanged between two
Proxies.
Proxy A B2BUA X B2BUA Y Proxy B
| | | |
| (1)INVITE | | |
|---------------->|(2)INVITE(IAM) | |
| |---------------->| (3)INVITE |
| | |---------------->|
| | | (4)180 |
| | (5)180(ACM) |<----------------|
| (6)180 |<----------------| (7)200 OK |
|<----------------| (8)200(ANM) |<----------------|
| (9)200 |<----------------| |
|<----------------| | |
| (10)ACK | | |
|---------------->| (11)ACK | |
| |---------------->| (12)ACK |
| | |---------------->|
|================== CONVERSATION =====================|
| (13)BYE | | |
|---------------->| (14)BYE(REL) | |
| |---------------->| (15)BYE |
| | |---------------->|
| | | (16)200 OK |
| | (17)200(RLC) |<----------------|
| (18)200 |<----------------| |
|<----------------| | |
Figure 9. Call Flow between two SIP networks
Chang [Page 9]
Internet Draft sipping-bicc-network September 2001
The basic constructs used in Figure 9 are:
- IAM
- ACM
- ANM
- REL
- RLC
The step-by-step descriptions of this procedure are in Appendix A.
5.2. BICC bridging using SIP
When serving as the bridge between two BICC networks, SIP can transport
the BICC messages across the SIP network with this extension. Figure 10
shows a bridging SIP network between two BICC networks.
+-------------+ +---------------------+ +--------------+
|+---+ +---+| BICC |+---+ SIP(BICC) +---|| BICC |+---| +---+ |
||CSF|<->|CSF|<----->||MGC|<--------->|MGC|<------>|CSF|<->|CSF| |
|+---+ | A || || X | | Y || || B | +---+ |
| +---|| |+---+ +---+| |+---+ |
|+----+ +----+| |+--+ +--+| |+----+ +----+ |
||BIWF|-|BIWF|--------|MG|-------------|MG|--------|BIWF--|BIWF| |
|+----+ +----+| |+--+ +--+| |+----+ +----+ |
+-------------| +---------------------+ +--------------+
BICC Network SIP Network BICC Netwrok
Figure 10 SIP as a bridging network
Figure 11 uses the following basic constructs to achieve the procedure
of forward setup:
- IAM
- Backward APM
- Forward APM
- ACM
- ANM
- REL
- RLC
Proxy A MGC X MGC Y Proxy B
| | | |
| (1)IAM | | |
|---------------->|(2)INVITE(IAM) | |
| |---------------->| (3)IAM |
| | |---------------->|
| | | (4)APM |
| | (5)183(APM) |<----------------|
| |<----------------| |
Chang [Page 10]
Internet Draft sipping-bicc-network September 2001
| (6)APM | | |
|<----------------| | |
| (7)APM | | |
|---------------->| | |
| | (8)PRACK(APM) | |
| |---------------->| (9)APM |
| | (10)200 OK |---------------->|
| |<----------------| (11)ACM |
| | (12)180(ACM) |<----------------|
| (13)ACM |<----------------| (14)ANM |
|<----------------| (15)200(ANM) |<----------------|
| (16)ANM |<----------------| |
|<----------------| | |
|================== CONVERSATION =====================|
| (17)REL | | |
|---------------->| (18)BYE(REL) | |
| |---------------->| (19)REL |
| | |---------------->|
| | | (20)RLC |
| | (21)200(RLC) |<----------------|
| (22)RLC |<----------------| |
|<----------------| | |
Figure 10. Call Flow of Fast Forward Setup with tunnelling
In other network configurations, MGs are not required for media
interworking. Figure 12 illustrates an example of the configurations
that do not require MGs.
+-------------+ +------------------------+ +-------------+
|+---+ +---+| BICC |+-----+ SIP(BICC)+-----+| BICC|+---+ +---+|
||CSF|<->|CSF|<------>|B2BUA|<--------->|B2BUA|<----->|CSF|<->|CSF||
|+---+ | a || || X | | Y || || b | +---+|
| +---+| |+-----+ +-----+| |+---+ |
| | | | | |
|+----+ +----+| +------------------------+ |+----+ +----+|
||BIWF|-|BIWF|---------------------------------------|BIWF--|BIWF||
|+----+ | a || || b | +----+|
| +----+| |+----+ |
+-------------+ +-------------+
BICC Network SIP Network BICC Network
Figure 12. SIP serves as a Call Mediation Node
Using the basic constructs described above, Figure 13 shows a scenario
for the call mediation configuration. More detailed descriptions of the
flow are in Appendix B.
Chang [Page 11]
Internet Draft sipping-bicc-network September 2001
CSF A B2BUA X B2BUA Y CSF B
| | | |
| (1)IAM | | |
|---------------->|(2)INVITE(IAM) | |
| |---------------->| (3)IAM |
| | |---------------->|
| | | (4)APM |
| | (5)183(APM) |<----------------|
| (6)APM |<----------------| |
|<----------------| | |
Figure 13. Call Flow of SIP as a Call Mediation Node
5.3. Extended SIP between different network transport
In this case, the session between a SIP terminal and an ISDN terminal
goes between the SIP network and the BICC network. There are two
possible scenarios between the MGC of the SIP network and the CSF in the
BICC network:
(1) BICC is used between MGC/B2BUA and CSF: In this scenario, the MGC
must support the BICC-to-SIP interworking function in the MGC/B2BUA.
(2) SIP with BICC extension is used between B2BUA/MGC and CSF: In this
scenario, CSF must support the extended SIP to ISDN interworking
function.
Case (1) is similar to the T1S1 contribution [5]. Case (2) is the
scenario that B2BUA/MGC supports the SIP across network boundary. The SIP
session needs to go through signaling interworking in the CSF.
Figure 14 depicts the first option that extended SIP is used between a
SIP network and a BICC network.
+---------------------+ +-----------------+
| +-----+ +-----+ | SIP(BICC) | +---+ |
| |Proxy|<->|B2BUA|<-------------->|CSF| |
| +-----+ +-----+ | | +---+ |
| ^ | | ^ LEC 2 |
| | | | | |
| LEC 1 | | | +-v--+ BICC |
| SIP | +------------------>|BIWF| Network |
|Network| | | | +----+ |
| | | | | ^ |
+-------|-------|-----+ +----|------------+
| | |
v v v
+---------+ +----------+
|SIP Phone| |ISDN Phone|
+---------+ +----------+
Figure 14. Extended SIP across different network transport
Chang [Page 12]
Internet Draft sipping-bicc-network September 2001
Figure 15 shows another option that a Media-Gateway and a Media-Gateway
Controller are supported at the SIP network boundary. This option
provides a solution for incompatible media between networks. MG in this
configuration performs transcoding between SIP phone and the voice
coding that is agreed upon between service providers.
+---------------------+ +-----------------+
| +-----+ +-----+ | SIP(BICC) | +---+ |
| |Proxy|<->| MGC |<-------------->|CSF| |
| +-----+ +-----+ | | +---+ |
| ^ ^ | | ^ LEC 2 |
| | | | | | |
| LEC 1 | +-V--+ | | +-v--+ BICC |
| SIP | | MG |--------------->|BIWF| Network |
|Network| +----+ | | +----+ |
| | | | | ^ |
+-------|-------|-----+ +----|------------+
| | |
v v v
+---------+ +----------+
|SIP Phone| |ISDN Phone|
+---------+ +----------+
Figure 15. MG used for different network transport
In Figure 15, the media stream between the SIP phone and the BIWF has
two sections. The media negotiation between MG and BIWF can be done
either by the SDP of the SIP or the SDP of the BICC.
6. Enhanced SIP Roles
- B2BUA/MGC
The B2BUA/MGC is a signaling point between networks. It supports the
translation/mapping between protocols such as BICC, SIP, and ISUP.
Traffic control between networks is also a function of the MGC. When the
MG is required in the interworking, MGC performs the signaling
interworking and the media control interface to the MG.
- Media Gateway (MG)
The MG supports conversion between different media types. In some
network configurations, the MG can support media proxy function, so that
the internal network configurations and addressing scheme can be
independent of external addresses. Functions of the MG can be
interworking, interworking + firewall, or as simple as router only.
7. Required Support
Similar to the ISUP to SIP-T mapping [3], SIP with BICC extension
mustsupport the following capabilities:
- Supports the method and procedure of pure SIP as defined by RFC
2543.
Chang [Page 13]
Internet Draft sipping-bicc-network September 2001
- Encapsulation
- Similar to ISUP MIME type [6], the BICC MIME type must be supported
for this extension
- Interworking/Mapping
- SDP
Depending on the role of the SIP in the network, the SDP in SIP may or
may not exist. If the SDP exists in the SIP protocol, the media between
two MGs should follow the specification in the SIP SDP. Otherwise, the
bearer characteristics should follow what specified in the BICC.
- Mid-call events: These events should be mapped into the SIP INFO
message.
- Mid-call reconfigurations due to mid-call events.
8. Network Features
- Traffic Control
Existing traffic control in the BICC message should be supported by
enhanced SIP. Blocking/Unblocking and Reset these messages should be
supported by encapsulated in the SIP NOTIFY/ACK messages.
- Other features: Other network features, such as automatic repeat
attempt, hop counter procedure, call collect request procedure and etc.,
must be supported by mapping into SIP features or BICC procedures.
9. Acknowledgement
The author would like to thank Richard Hemmeter, and Hui-Lan Lu for
their comments and suggestions.
10. Acronyms
ACM Address Complete Message
ANM Answer
CFN Confusion
CGB Circuit Group Blocking
CGBA Circuit Group Blocking Acknowledgement
CGU Circuit Group Unblocking
CGUA Circuit Group Unblocking Acknowledgement
CON Connect
COT Continuity
CPG Call Progress
CQM Circuit Query
CQR Circuit Query Response
CRA Circuit Reservation Acknowledgement
FOT Forward Transfer
GRS Group Reset
IAM Initial Address Message
INF Information
REL Release
RES Resume
RLC Release Complete RSC Reset Circuit
SUS Suspend
UCIC Unequipped Circuit Identification Code
Chang [Page 14]
Internet Draft sipping-bicc-network September 2001
11. References
[1] Handley, et al, "SIP: Session Initiation Protocol," RFC 2543,
IETF, March 1999.
[2] Vemuri, Peterson, "SIP for Telephony (SIP-T): Context and
Architectures," draft-vemuri-sip-t-context-02.txt, February
2001.
[3] Mainwaring, "Requirements for interworking between
SIP/SIP-T and ISUP/BIC," T1S1.3-108/2001 T1S1.7/2001-153,
April 2001.
[4] ITU-T Recommendations Q.1902.1 - Q.1902.6 (2001), Bearer
Independent Call Control protocol (CS2).
[5] Gonzalo, Roach "ISUP to SIP Mapping," draft-ietf-sip-isup-
00.txt, November 2000.
[6] Zimmerer, Vemuri, Peterson, Ong, Zonoun, Watson, "MIME media
types for ISUP and QSIG objects," draft-ietf-sip-isup-mime-
09.txt, January 2001.
[7] Bin-wen Ho, "Application of SIP to support BICC (Bearer Independent
Call Control," to be submitted to IETF.
12. Author's Address
Young-Fu Chang
Lucent Technologies, Inc.
PO Box 7033
1960 Lucent Lane
Naperville, IL 60566-7033
email: yfchang@lucent.com
APPENDICES
Appendix A
(1) INVITE sip: watson@chicago.optical-net.com SIP/2.0
Via:SIP/2.0/UDP oak.bell-tel.com
Via:SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 1 INVITE
Contact: <sip:a.g.bell@maple.bell-tel.com>
Subject: Mr. Watson, come here.
Content-Type: application/sdp
Content-length: . . .
Chang [Page 15]
Internet Draft sipping-bicc-network September 2001
v=0
o=bell 53655768 2353687636 IN IP4 135.234.2.23
s=Mr. Watson, come here
t=3149328600 0
c=IN IP maple.bell-com.com
m=audio 4567 RTP/AVP 0 3 4 5
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:4 G723/8000
a=rtpmap:5 DVI4/8000
(2) INVITE sip:watson@chicago.optical-net.com SIP/2.0
Via: SIP/2.0/UDP pine.bell-tel.com
Via: SIP/2.0/UDP oak.bell-tel.com
Via: SIP/2.0/UDP maple.bell-tel.com
Supported: 100rel
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 1 INVITE
Contact: <sip:a.g.bell@maple.bell-tel.com>
Subject: Mr. Watson, come here.
Content-length: . . .
Content-Type: multipart/mixed; boundary=unique-boundary-1
MIME-Version: 1.0
--unique-boundary-1
Content-Type: application/SDP;
....
--unique-boundary-1
Content-Type: application/BICC; version=cs2;
Base=itu-2000
Content-Disposition: signal; handling=required
IAM (CIC=10), (Action Indicator = None),
(Bearer Control Tunneling = tunneling to be used),
(Calling Party addr=???), (Called Party Addr=???),
(Bearer Network Connection Characteristics = IP),
(Bearer Control Information)
--unique-boundary-1
Note: The encoding of BICC message is binary. For readability,
the BICC message is represented in text form in the message
above.
(3) INVITE sip:watson@chicago.optical-net.com SIP/2.0
Via: SIP/2.0/UDP jupiter.optical-net.com
Via: SIP/2.0/UDP pine.bell-tel.com
Via: SIP/2.0/UDP oak.bell-tel.com
Via: SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Chang [Page 16]
Internet Draft sipping-bicc-network September 2001
Cseq: 1 INVITE
Contact: <sip:a.g.bell@maple.bell-tel.com>
Subject: Mr. Watson, come here.
Content-Type: application/sdp
Content-length: . . .
(4) SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pine.bell-tel.com
Via: SIP/2.0/UDP oak.bell-tel.com
Via: SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 1 INVITE
CContent-length: . .
(5) SIP/2.0 180 Ringing
Via: SIP/2.0/UDP oak.bell-tel.com
Via: SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 1 INVITE
Content-Type: application/BICC; version=cs2;
Base=itu-2000
Content-Disposition: signal; handling=required
ACM (CIC=10)
(6) SIP/2.0 180 Ringing
Via: SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 1 INVITE
(7) SIP/2.0 200 OK
Via: SIP/2.0/UDP pine.bell-tel.com
Via: SIP/2.0/UDP oak.bell-tel.com
Via: SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 1 INVITE
(8) SIP/2.0 200 OK
Via: SIP/2.0/UDP oak.bell-tel.com
Via: SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 1 INVITE
Content-length: . . .
Content-Type: application/BICC; version=cs2;
Base=itu-2000
Chang [Page 17]
Internet Draft sipping-bicc-network September 2001
Content-Disposition: signal; handling=required
ANM (CIC=10)
(9) SIP/2.0 200 OK
Via: SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 1 INVITE
(10) SIP/2.0 ACK
Via: SIP/2.0/UDP oak.bell-tel.com
Via: SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 1 INVITE
(11) SIP/2.0 ACK
Via: SIP/2.0/UDP pine.bell-tel.com
Via: SIP/2.0/UDP oak.bell-tel.com
Via: SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 1 INVITE
(12) SIP/2.0 ACK
Via: SIP/2.0/UDP jupiter.optical-net.com
Via: SIP/2.0/UDP pine.bell-tel.com
Via: SIP/2.0/UDP oak.bell-tel.com
Via: SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 1 INVITE
(13) SIP/2.0 BYE
Via: SIP/2.0/UDP oak.bell-tel.com
Via: SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 2 BYE
(14) SIP/2.0 BYE
Via: SIP/2.0/UDP pine.bell-tel.com
Via: SIP/2.0/UDP oak.bell-tel.com
Via: SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 2 BYE
Chang [Page 18]
Internet Draft sipping-bicc-network September 2001
Content-length: . . .
Content-Type: application/BICC; version=cs2;
Base=itu-2000
Content-Disposition: signal; handling=required
REL (CIC=10)
(15) SIP/2.0 BYE
Via: SIP/2.0/UDP jupiter.optical-net.com
Via: SIP/2.0/UDP pine.bell-tel.com
Via: SIP/2.0/UDP oak.bell-tel.com
Via: SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 2 BYE
(16) SIP/2.0 200 OK
Via: SIP/2.0/UDP pine.bell-tel.com
Via: SIP/2.0/UDP oak.bell-tel.com
Via: SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 2 BYE
(17) SIP/2.0 200 OK
Via: SIP/2.0/UDP oak.bell-tel.com
Via: SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 2 BYE
Content-length: . . .
Content-Type: application/BICC; version=cs2;
Base=itu-2000
Content-Disposition: signal; handling=required
RLC (CIC=10)
(18) SIP/2.0 200 OK
Via: SIP/2.0/UDP maple.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3
To: T. Watson <sip:watson@chicago.optical-net.com>
Call-ID: 6601698@maple.bell-tel.com
Cseq: 2 BYE
Appendix B
(1) IAM (CIC=10), (Action Indicator= Connect Backwards),
(Tunnel Indication = No), (Calling Party addr=19789492000),
(Called Party Addr=16309792000), (T-BIWF address=BIWFa),
(Bearer Service Characteristics),(BNC-ID=5698),
(BNC characteristics), (Codec list), (BCU-ID=A)
Chang [Page 19]
Internet Draft sipping-bicc-network September 2001
(2) INVITE tel:+16309792000 SIP/2.0
Via: SIP/2.0/UDP oak.bell-tel.com
From: tel:+19789492000;tag=3
To: tel:+16309792000
Call-ID: 6601698@oak.bell-tel.com
Cseq: 1 INVITE
Contact: <sip:admin@oak.bell-tel.com>
Content-length: . . .
Content-Type: application/BICC; version=cs2;
Base=itu-2000
Content-Disposition: signal; handling=required
IAM (CIC=10),(Action-ID= Connect Backwards),
(Tunnel Indication = No), (Calling Party addr=19789492000),
(Called Party Addr=16309792000), (T-BIWF address=BIWFa),
(Bearer Service Characteristics),(BNC-ID=5698),
(BNC characteristics), (Codec list), (BCU-ID=A)
Note: The encoding of BICC message is binary. For readability, the
BICC message is represented in text form in the message above.
(3) IAM (CIC=50), (Action Indicator = Connect Backwards),
(Tunnel Indication = No), (Calling Party addr=19789492000),
(Called Party Addr=16309792000), (T-BIWF address=BIWFa),
(Bearer Service Characteristics),(BNC-ID=5698), (Codec list), (BCU-
ID=A)
(4) APM (CIC=50), (Action Indicator = Selected Codec), (Selected Codec),
(Supported Codec), (BNC-ID=5698), (BCU-ID=A)
(5) SIP/2.0 183 Session Progress
From: tel:+19789492000;tag=3
To: tel:+16309792000
Call-ID: 6601698@oak.bell-tel.com
Cseq: 1 INVITE
Contact: <sip:admin@oak.bell-tel.com>
Content-length: . . .
Content-Type: application/BICC; version=cs2;
Base=itu-2000
Content-Disposition: signal; handling=required
APM (CIC=50), (Action Indicator = Codec Selected), (Selected Codec),
(Supported Codec), (BNC-ID=5698), (BCU-ID=A)
(6) APM (CIC=10), (Action Indicator = Codec Selected), (Selected Codec),
(Supported Codec), (BNC-ID=5698), (BCU-ID=A)
Expires: March 2002
Chang [Page 20]