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 ;tag=3 To: T. Watson Call-ID: 6601698@maple.bell-tel.com Cseq: 1 INVITE Contact: 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 ;tag=3 To: T. Watson Call-ID: 6601698@maple.bell-tel.com Cseq: 1 INVITE Contact: 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 ;tag=3 To: T. Watson Call-ID: 6601698@maple.bell-tel.com Chang [Page 16] Internet Draft sipping-bicc-network September 2001 Cseq: 1 INVITE Contact: 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 ;tag=3 To: T. Watson 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 ;tag=3 To: T. Watson 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 ;tag=3 To: T. Watson 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 ;tag=3 To: T. Watson 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 ;tag=3 To: T. Watson 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 ;tag=3 To: T. Watson 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 ;tag=3 To: T. Watson 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 ;tag=3 To: T. Watson 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 ;tag=3 To: T. Watson 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 ;tag=3 To: T. Watson 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 ;tag=3 To: T. Watson 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 ;tag=3 To: T. Watson 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 ;tag=3 To: T. Watson 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 ;tag=3 To: T. Watson 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 ;tag=3 To: T. Watson 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: 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: 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]