Internet Engineering Task Force Internet Draft Singh/Schulzrinne draft-singh-sip-h323-01.txt Columbia University May 16, 2000 Expires: November 2000 Interworking Between SIP/SDP and H.323 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 document describes the interworking between SIP and H.323, including the translation between H.245 and SDP. We list general requirements for such a translation and a solution which meets those requirements. We describe the call setup via message flows and pseudo code. 1 Introduction It appears likely that both SIP [1], with SDP [2], and H.323 [3] will be used for internet multimedia signaling in the next few years. Both these protocols run over IP (Internet Protocol) and use RTP (Real time Transport protocol [4]) for transferring realtime audio/video data, reducing the task of interworking between these protocols to merely translating the signaling protocols and session descriptions. We enumerate the requirements for a translation between H.323 and SIP/SDP and then propose a solution which meets those requirements. Singh/Schulzrinne [Page 1]
Internet Draft May 16, 2000 Issues related to a new enhanced version of SDP (Session Description Protocol [2]) is kept open while discussing the solution, so in future any change in SDP can be easily included in this document. Section 2 describes the scope of this document. Section 3 lists the terminology used in the document. Section 4 gives the requirements for a simple translation between SIP/SDP and H.323. Section 5 describes simple call scenarios for call setup and address resolution. In section 6 we have described a mapping between H.323 and SIP addresses. Section 7 describes an algorithm to find a common subset of H.323 and SIP capabilities. Section 8 lists the protocol level requirements for the interworking function. Pseudo-code for a simple translation is given in Appendix A. 2 Scope of This Document This document describes interworking between H.323 Version 2.0 and SIP Version 2.0. However, since an H.323v2 terminal may or may not support FastConnect, solutions without using this feature are also detailed. Only a simple call scenario is presented. It does not cover conferencing or advanced call services like call forwarding, call transfer. This document also describes the translation between H.323 and SDP for session description. Overlap sending of dialed digits is not supported. DataApplication (T.120), encryption, security and authentication are not covered in this document. 3 Terminology and Conventions Interworking function (IWF): The SIP-H.323 signaling gateway or the signaling translator described in this document. Endpoint: H.323 endpoint or SIP user agent. Signaling: Generic name for protocols specified by Q.931 [5], H.245 [6] or SIP [1]. Data traffic: RTP/RTCP encapsulated data (multimedia) traffic. Gatekeeper (GK): H.323 gatekeeper which can accept RRQ (registration request) and ARQ (admission request) messages belonging to the RAS protocol. Registrar: SIP server which accepts REGISTER requests. Cloud: Logical collection of entities using the same signaling protocol. In this document, we refer to the H.323 and SIP Singh/Schulzrinne [Page 2]
Internet Draft May 16, 2000 clouds. Note that we assume that both of these clouds use IP as their underlying network layer. The H.323 [3] and SIP [1] specifications provide additional terms used here. In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [7]. In message flow sequences, we label message flows as follows: =========> SIP message ~~~~~~~~~> RAS message ---------> Q.931 message --+--+---> H.245 message 4 Translation Requirements Basic requirements for any SIP-H.323 IWF are summarized below: 1. Protocol compliance: The IWF should use the components of H.323 and SIP. The IWF should handle all mandatory features of H.323 as well as SIP. Common call scenarios should be simple to implement. 2. User registration: The IWF should use the user registration in both the H.323 and SIP clouds to resolve the user name (alias or URL) to an IP address. In other words, it should provide a framework in which the user may dial any address without actually knowing whether it belongs to the H.323 or the SIP cloud. 3. Mapping between H.245 and SDP: The IWF should be able to map all the mandatory H.245 messages to apporopriate SDP messages and vice-versa, without the endpoint being aware that such conversion is taking place. Other optional features of H.245 and SDP should be mapped as much as possible to facilitate maximum interworking between the two clouds. 4. Direct RTP/RTCP traffic between the endpoints: Where possible, the IWF should route RTP/RTCP traffic directly between the endpoints involved in the conference Singh/Schulzrinne [Page 3]
Internet Draft May 16, 2000 without going through the IWF. This reduces the delay for media packets and helps building scaleable IWFs. 5. Transparent support for audio/video algorithms: The IWF should provide transparent support for audio/video algorithms, i.e., the IWF should not restrict the capabilities of the endpoints in terms of audio/video algorithms supported. 6. Call sequence mapping: The IWF should map the message sequence between H.323 and SIP in such a way that every important decision (accept or reject a call, choose an algorithm for a logical channel, and so on) is taken by the endpoints involved in the conference and not by the IWF itself. We assume throughout most of this document that the session description given by a SIP endpoint refers to both the transmit and the receive capabilities of the SIP endpoint. This may not be true in a particular application. If that is the case then the SIP endpoint is expected to give that information in SDP using recvonly or sendonly media attributes. The analysis of SIP-H.323 interworking can be split into o simple call setup; o mapping addresses; o finding a subset of capabilities described by H.245 and SDP; o conferencing and call services; o security and authentication. The last two issues are not addressed in this document. Section 5 describes call setup and teardown; while Section 6 describes address mapping and section 7 the capabilities calculation. 5 Call Scenario A simple IWF architecture is shown in Fig. 1. Note that an H.323 gatekeeper and/or a SIP server may be part of the IWF. The H.323 cloud is shown on the left hand side and the SIP cloud on the right hand side. The following subsections describe and evaluate different call Singh/Schulzrinne [Page 4]
Internet Draft May 16, 2000 Gateway +---------+ +------+------+ +-------+ | H.323 |---------| | | | SIP | | endpoint| | H.323| SIP |======| user | +---------+ |Termi-| user | | agent | | nal |agent | +-------+ +----------+ | | | | H.323 |---------| | | +------------+ |gatekeeper| | | |======| SIP Server | +----------+ | | | +------------+ +------+------+ Figure 1: SIP-H.323 IWF architecture scenarios. 5.1 User Registration and Address Resolution 5.1.1 IWF Contains SIP Proxy Server and Registrar Fig. 2 shows an IWF that contains a SIP proxy and registrar. SIP REGISTER |---------|-------------| RAS |-------------| ===========>| SIP | gateway |~~~~~~~>| Gatekeeper | |registrar| | | | |---------|-------------| |-------------| Figure 2: IWF colocated with SIP server When receiving a SIP REGISTER request, the IWF generates an H.323 RAS RRQ request to its local GKs. The callSignalAddress of the RAS Singh/Schulzrinne [Page 5]
Internet Draft May 16, 2000 message contains the network address of the IWF; the terminalType is set to "gateway" and the terminalAlias is derived from the SIP To SIP-Address, as described in Section 6. Thus, any address resolution request coming from the H.323 cloud to a SIP address can be resolved by H.323 gatekeeper(s) using H.323 RAS requests. Any request coming from the SIP cloud to H.323 is forwarded to the H.323 gatekeeper(s) by the IWF. H.323 gatekeeper(s) resolve this address using RAS/H.323. During initialization, the IWF registers its own alias address (e.g., gw1 ) with its local H.323 gatekeepers, so that anybody from the H.323 cloud can reach SIP endpoints by directly connecting to the alias address of the IWF and by providing a SIP address in the remote extension address of the SETUP message of H.323. Fig. 3 shows the message flow sequences for successful initialization. Address resolution from SIP to H.323 is shown in Fig. 4, while address resolution from H.323 to SIP is shown in Fig. 5. This scheme assumes that the IWF is aware of the client part of the H.323 RAS protocol so that it can talk to the gatekeeper. Each SIP UA that registers with the registrar also appears in the gatekeeper's database. 5.1.2 IWF Contains an H.323 Gatekeeper In an alternative architecture, shown in Fig. 6, the IWF contains an H.323 gatekeeper in addition to a SIP UA. Address resolution from SIP to H.323 is shown in Fig. 7. while address resolution from H.323 to SIP is shown in Fig. 8. 5.1.3 IWF Does Not Contain Gatekeeper or Registrar Instead of having the IWF contain a GK or registrar, it may be preferable to have the IWF resolve addresses when call setup requests arrive. Thus, the IWF does not store any address mappings of H.323 or SIP endpoints. When a call arrives at the IWF from SIP cloud, the IWF sends a RAS ARQ request to the H.323 cloud. If the address cannot be resolved or if the RAS request times out, it sends an appropriate Singh/Schulzrinne [Page 6]
Internet Draft May 16, 2000 H.323 GK1 GK2 GW SIP UA Terminal gw1 | | | | | | | | RRQ | | | | |<~~~~~~~~~~~~~| | | | | (gw1) | | | | | | | | | | RCF | | | | |~~~~~~~~~~~~~>| | | RRQ | | | | |~~~~~~~~~~~~~>| | | | | (kns10@columbia.edu) | | | | | | | | | RCF | | | | |<~~~~~~~~~~~~~| | | | | | | | REGISTER | | | | |<============| | | | | To: hgs@cs.columbia.edu | | | RRQ | | | | |<~~~~~~~~~~~~~| | | | | (hgs@cs.columbia.edu) | | | | | | | | | RCF | | | | |~~~~~~~~~~~~~>| | | | | | 200 OK | | | | |============>| | | | | | Figure 3: IWF initialization, as described in Section 5.1.1 response to the SIP endpoint. Similarly, calls from the H.323 cloud are translated into SIP requests and sent to a proxy or end system. This approach works well if calls are identified by URLs indicating the signaling scheme, i.e., if an H.323 request is directed to a SIP URL or vice versa. In that case, it is sufficient if the GK or proxy is pre-configured with the address of the IWF. If the destination address does not indicate the signaling protocol, a SIP proxy server has to forward all incoming requests to a local IWF, just in case the destination happens to be reachable via H.323. In this architecture, the IWF MUST implement the RAS LRQ (location Singh/Schulzrinne [Page 7]
Internet Draft May 16, 2000 H.323 Terminal GK1 GK2 GW SIP UA 128.59.16.1 columbia.edu The H.323 Terminal is initialized: | | | | | | RRQ | | | | |~~~~~~~~~~~~~>| | | | | kns10@columbia.edu | | | | | | | | | RCF | | | | |<~~~~~~~~~~~~~| | | | Call: | | | | INVITE | | | | |<============| | | | | To: kns10@columbia.edu | | | | | | | | | 100 Trying | | | | |============>| | | | ARQ | | | | |<~~~~~~~~~~~~~| | | | | kns10@columbia.edu | | | LRQ | | | | |<~~~~~~~~~~~~~| | | | | kns10@columbia.edu | | | | | | | | | LCF | | | | |~~~~~~~~~~~~~>| | | | | 128.59.16.1 | | | | | | | | | | | ACF | | | | |~~~~~~~~~~~~~>| | | | | 128.59.16.1 | | Figure 4: Address translation from SIP to H.323, as described in Section 5.1.1 request) and LCF (location confirmation) messages. When a call is initiated by an H.323 entity, its gatekeeper will send an LRQ request to other gatekeepers at the well-known GK multicast address. The IWF captures the LRQ message and can use one of two approaches to find out if a SIP end point is available at that address. In the first Singh/Schulzrinne [Page 8]
Internet Draft May 16, 2000 SIP UA GW GK2 GK1 H.323 Terminal cs.columbia.edu 128.59.16.2 | | | | | | REGISTER | | | | |=============>| | | | | To: hgs@cs.columbia.edu | | | | | | | | | | RRQ | | | | |~~~~~~~~~~~~~>| | | | | hgs@cs.columbia.edu | | | | at 128.59.16.2 | | | | | | | | | RCF | | | | |<~~~~~~~~~~~~~| | | | OK | | | | |<=============| | | | | | | | | The SIP UA has registered its address during initialization. | | | | ARQ | | | | |<~~~~~~~~~~~~| | | | | hgs@cs.columbia.edu | | | | | | | | LRQ | | | | |<~~~~~~~~~~~~~| | | | hgs@cs.columbia.edu | | | | | | | | | LCF | | | | |~~~~~~~~~~~~~>| | | | |128.59.16.2 | | | | | | | | | | | ACF | | | | |~~~~~~~~~~~~>| | | | | 128.59.16.2 | Figure 5: Address translation from H.323 to SIP, as described in Section 5.1.1 approach, the IWF sends a REGISTER request without Contact information to the domain identified in the request (see Section 6). If the registrar has information about the endpoint, it returns this Singh/Schulzrinne [Page 9]
Internet Draft May 16, 2000 RRQ +--------------------+ REGISTER +-------------+ ~~~~~~~~~~~>| H.323 |SIP UA |=========>| SIP | | gatekeeper | | | registrar | +--------------------+ +-------------+ GW Figure 6: IWF colocated with a gatekeeper information in the Contact headers of the response. The IWF then translates this information and responds to the H.323 cloud with a LCF (location confirmation) message. If the registrar returns a negative indication, the IWF responds with a LRJ (location reject) message or remains silent. (Note that it is permitted that a terminal responds to LRQ messages, so that a gatekeeper is not needed as a part of the IWF application.) This approach is equivalent to SIP third-party registration and will not work if the registrar requires authentication. The second approach uses SIP OPTIONS messages, but is otherwise identical. 5.1.4 Direct Connection If an IWF receives a Q.931 SETUP message, the IWF tries to parse the Q.931 destinationAddress. If the destinationAddress is not of the IWF itself and if it is able to resolve it to a SIP address, then the procedure described in section 5.2 is used to establish the call. (Note that the user registration steps are not involved in this scenario.) Otherwise, if the destination address is that of the IWF and a remote extension address is present in the SETUP message of Q.931, then the IWF should use the remote extension address to determine the SIP address. The IWF MAY also be configured to forward all requests to a pre-defined SIP proxy. 5.2 Call Establishment A call requires three crucial pieces of information, namely the logical destination address, the media transport address and the media description. Logical Destination address (A): This is the SIP address in To header or the destination alias address in the Q.931 SETUP message. Singh/Schulzrinne [Page 10]
Internet Draft May 16, 2000 H.323 Terminal GW/GK SIP server SIP UA gw1 columbia.edu | | | | | RRQ | | | |~~~~~~~~~~~~~~~~~~>| | | | kns10@columbia.edu| | | | | | | | | REGISTER | | | |==================>| | | | To: kns10@columbia.edu | | | Contact: kns10@gw1 | | | | | | | 200 OK | | | |<==================| | | RCF | | | |<~~~~~~~~~~~~~~~~~~| | | | | | | The H.323 terminal has registered its alias address. | | | INVITE | | | |<=================| | | | To: kns10@columbia.edu | | | | | | | 302 Moved | | | |=================>| | | | Contact: kns10@gw1 | | | | | | INVITE kns10@gw1 | | |<=====================================| | | To: kns10@columbia.edu | | | | | | | 100 Trying | | |=====================================>| | | | | Figure 7: Address translation from SIP to H.323 when IWF contains an H.323 GK Media Description (M): In SIP, M is the list of supported payload types as given by SDP media description ("m=") line. In H.245, M is given by the Terminal Capability Set. Singh/Schulzrinne [Page 11]
Internet Draft May 16, 2000 SIP UA SIP server GW/GK H.323 terminal x.cs.columbia.edu 128.59.16.1 | | | | | REGISTER | | | |==================>| | | | To: hgs@cs.columbia.edu | | | Contact: hgs@x.cs.columbia.edu | | | | | | | 200 OK | | | |<==================| | | | | | | SIP user agent has registered its address with the server. | | | ARQ | | | |<~~~~~~~~~~~~~~~~~| | | | hgs@cs.columbia.edu | | OPTIONS | | | |<==================| | | | To: hgs@cs.columbia.edu | | OPTIONS hgs@x.cs.columbia.edu | | |<==================| | | | To: hgs@cs.columbia.edu | | | | | | | 200 OK | | | |==================>| | | | | 200 OK | | | |==================>| | | | | ACF | | | |~~~~~~~~~~~~~~~~~>| | | | 128.59.16.1 | | | | | Figure 8: Address translation from H.323 to SIP when IWF contains an H.323 GK Media Transport Address (T): The media transport address indicates the IP address and port number at which RTP/RTCP packets can be received. This information is available in the "c=" and the "m=" lines of SDP and the Open Logical Channel message of H.245. The difficulty in translating between SIP and H.323 arises because A, M, and T are all contained in the SIP INVITE message, while H.323 may Singh/Schulzrinne [Page 12]
Internet Draft May 16, 2000 spread this information among several messages. 5.2.1 Call Establishment with H.323v2 Fast Connect With H.323v2 FastConnect, the protocol translation is simplified because there is a one-to-one mapping between H.323 and SIP call establishment messages. Both the H.323 SETUP message with FastConnect and the SIP INVITE request have all three components (A, M and T). Call scenarios are shown in Fig. 9 and 10. SIP UA GW H.323 terminal 128.59.19.194 128.59.21.152 | | | | INVITE | | |============================>| | | To: kns10@columbia.edu | | | c=IN IP4 128.59.19.194 | | | m=audio 8000 RTP/AVP 0 | | | | SETUP | | |--------------------------->| | | fastStart={g711Ulaw,Tx}, | | | {g711Ulaw,Rx,128.59.19.194:8000} | | | | | Connect | | |<---------------------------| | | fastStart= | | | {g711Ulaw,Tx,128.59.21.152:10000}, | | {g711Ulaw,Rx} | | 200 OK | | |<============================| | | c=IN IP4 128.59.21.152 | | | m=audio 10000 RTP/AVP 0 | | | | | | ACK | | |============================>| | | | | Figure 9: Call setup from SIP UA to H.323 terminal with FastConnect 5.2.2 Call Establishment without H.323v2 FastConnect Since H.323v2 terminals do not have to support the FastConnect Singh/Schulzrinne [Page 13]
Internet Draft May 16, 2000 H.323 terminal GW SIP UA 128.59.21.152 128.59.19.194 | | | | SETUP | | |---------------------------->| | | destination:hgs@cs.columbia.edu | | fastStart={g711Ulaw,Tx}, | | | {g711Ulaw,Rx,128.59.21.152:10000} | | | | | | INVITE | | |===========================>| | | To:hgs@cs.columbia.edu | | | c=IN IP4 128.59.21.152 | | | m=audio 10000 RTP/AVP 0 | | | | | | 200 OK | | |<===========================| | | c=IN IP4 128.59.19.194 | | | m=audio 8000 RTP/AVP 0 | | CONNECT | | |<----------------------------| | | fastStart={g711Ulaw,Tx,128.59.19.194:8000}, | | {g711Ulaw,Rx} | | | | ACK | | |===========================>| | | | Figure 10: Call setup from H.323 terminal to SIP UA with FastConnect feature, it is likely that the IWF receives incoming calls from the H.323 cloud without Fast Connect PDUs. When the call is initiated by a SIP UA all the call information (A, M and T) is present in the SIP INVITE message and can be used to format H.323 messages. But when the call in initiated by an H.323 terminal, A, M and T are present in different messages. In a H.323 call without FastConnect, A is found in the Q.931 SETUP message, the TerminalCapabilitySet of H.245/H.323 contains M and T is present in the H.245 OpenLogicalChannel message. There are different ways in which these can be combined to form a SIP INVITE message. Two possible approaches are discussed below (in section 5.2.3 and 5.2.4). 5.2.3 Call from H.323 cloud to SIP cloud with H.245 TerminalCapabilitySet (TCS) Mapped to SDP Singh/Schulzrinne [Page 14]
Internet Draft May 16, 2000 A first approach has the IWF send a SIP INVITE request when it receives a Q.931 SETUP message. The SDP body of the INVITE request contains a default session sescription. The default session description MUST be either empty or contain media description (m=) lines indicating the minimal capabilities of any H.323 terminal handled by the IWF. Currently, these minimal capabilities include only PCMU audio. If the session description is not empty, the IWF has two choices: 1. The IWF controls an RTP translator that can forward RTP packets between two different IP addresses. The SDP "c=" line indicates the address of the translator, with the port indicated in the "m=" line. 2. The "c=" line indicates a zero address and the "m=" line a zero port. When the IWF receives a 200 (OK) response for the INVITE request from the SIP cloud, the IWF transmits a Q.931 CONNECT message to the H.323 endpoint. The IWF initiates the H.245 capability with the TCS (Terminal Capability Set) sent to the H.323 endpoint. On receipt of the TCS from the H.323 end point, which has a list of media supported by the H.323 endpoint, a SIP ACK message is formed with an updated session description reflecting the TCS. However, T is still unknown at this point, so that the SDP "m=" and "c=" lines remain as described above. When the IWF receives an H.245 Open Logical Channel (OLC) message, the IWF acknowledges it with session information derived from the session description received from the SIP UA in the 200 (OK) response. When the first RTP packet of any media is received by the IWF from the SIP cloud, the IWF knows what payload type is used by the SIP UA for that media type and it can send OLC to the H.323 cloud. RTP packets received until OLC Ack is received are ignored or buffered for future transmission. The problem with this approach is that RTP packets from the SIP UA cannot directly go to the H.323 terminal, but are instead routed through the RTP translator, violating requirement 4 in Section 4. This problem can be solved by having the IWF send a re-INVITE to the SIP endpoint after the logical channels have been opened. This new INVITE message indicates media transport addresses (T) of the H.323 endpoint and not that of the translator. A second problem is caused by the different interpretation of dynamic payload type switching in H.323 and SIP. When the TCS is mapped to SDP, the "m=" line is likely to list more than one payload type. This indicates to the SIP-controlled media agent that it may switch Singh/Schulzrinne [Page 15]
Internet Draft May 16, 2000 dynamically between all the payload types listed, without any H.323 or SIP signaling. However, in H.323, switching payload types requires Open Logical Channel signaling. This problem can be solved by restricting the SDP sent to the SIP endpoint to contain only one payload type per media description line. It is not clear how this payload type should be chosen or how the SIP endpoint can then switch payload types. A third problem is that mapping a generic TCS to SDP requires enhancing SDP or SIP so that it can indicate different capability descriptors of H.245. For example, we could use SIP multipart message bodies, with each body part containing the SDP mapped from a single capability descriptor. (Section 7 describes how to calculate a common subset of H.245 and SDP capabilities.) To solve this problem, the IWF could send a SIP OPTIONS request to the SIP UA and use that to calculate the common subset of capabilities. 5.2.4 Call from H.323 Cloud to SIP Cloud Mapping H.245 Open Logical Channel (OLC) to SDP In the second approach, on receipt of a Q.931 SETUP message, the IWF sends a SIP INVITE request as in Section 5.2.3. The IWF performs the H.323 capability exchange with the H.323 cloud without involving the SIP UA. The IWF then calculates the subset of capabilities from the H.323 TCS and the SDP contained in the 200 (OK) response to the INVITE. The IWF then sends an H.245 OpenLogicalChannel message for each of the media present in this subset. The OpenLogicalChannelAck message received from H.323 terminal will have the media transport addresses (T) of the H.323 terminal. On receipt of OpenLogicalChannelAck for all the OpenLogicalChannel messages, the IWF sends a SIP ACK message with the new transport addresses. This call scenario is shown in figures 11 and 12. Dynamic switching of H.245 Mode or Logical Channels is accomplished using SIP re-INVITE. For example, if video logical channel is opened from H.323 to IWF after initial call setup procedure (i.e., Logical Channels for audio are already opened), then the IWF sends a re- INVITE message to the SIP side with new SDP describing the video capability also. When the IWF receives 200 response from the SIP side, it sends OpenLogicalChannelAck to H.323 side with the media transport address as received in SDP in the response. The IWF will also initiate OpenLogicalChannel procedure for the video channel in IWF to H.323 direction. Singh/Schulzrinne [Page 16]
Internet Draft May 16, 2000 If the media transport address of SIP UA changes during a call for a particular logical channel, (e.g., as a result of re-INVITE initiated by the SIP side) then the IWF sends RequestChannelClose H.245 message to the H.323 terminal for the logical channel. H.323 terminal will close the logical channel and will re-open it using OpenLogicalChannel. The changed media transport address of SIP UA can then be returned to H.323 terminal in OpenLogicalChannelAck message. In this approach, RTP packets can be sent directly between the two endpoints. However, the SIP UA is restricted to algorithms chosen by the IWF. Since these algorithms are derived from the subset of H.323 and SIP capabilities, communications should still be possible. A small problem with this message flow sequence is that ACK timeout on the SIP side and OLC timeouts on H.323 side may not match. This may result in lots of retransmission in SIP network. To avoid this, the IWF may choose to send an ACK immediately upon receipt of the 200 (OK) response from the SIP UA and then re-INVITE with an updated SDP after all OpenLogicalChannelAcks have been received from the H.323 endpoint. A third approach would accept the H.323 SETUP message before forwarding it to SIP endpoint. However, this approach violates some of the requirements listed before and are not deemed appropriate by the authors. We prefer the mapping of SDP to and from OpenLogicalChannel (section 5.2.4) for the following reasons: o Mapping OLC is simpler than mapping TerminalCapabilitySet to SDP, which requires modifications to SIP or SDP. o It avoids the introduction of a temporary RTP translator. 6 Address Conversion between H.323 and SIP A SIP address can be either a SIP URL or any URI. This document only describes the translation of the SIP ("sip:"), telephone ("tel:") and H.323 ("h323:") URL schemes. The BNF of a SIP address is given below for reference: SIP-Address _ (name-addr | addr-spec) name-addr _ [display-name] "<" addr-spec ">" addr-spec _ SIP-URL SIP-URL _ "sip:" [ userinfo "@" ] hostport url-parameters [headers] Singh/Schulzrinne [Page 17]
Internet Draft May 16, 2000 H.323 GW UA 128.59.21.152 128.59.19.216 128.59.19.194 | | | | Setup | | |---------------------------->| | | (hgs@cs.columbia.edu) | INVITE w/default SDP | | (no fastStart) |===========================>| | | c=IN IP4 128.59.19.216 | | | m=audio 0 RTP/AVP 0 | | | | | | 200 OK | | Connect |<===========================| |<----------------------------| c=IN IP4 128.59.19.194 | | | m=audio 8000 RTP/AVP 8 | | TCS | | |<--+--+--+--+--+--+--+--+--+-| | | {g711Alaw for tx and rx} | | | | | | TCSAck | | |--+--+--+--+--+--+--+--+--+->| | | | | | TCS | | |--+--+--+--+--+--+--+--+--+->| | | {g711Alaw and g711Ulaw} | | | | | | TCSAck | | |<--+--+--+--+--+--+--+--+--+-| | | | | | OLC | | |<--+--+--+--+--+--+--+--+--+-| | | {mode=g711Alaw} | | | | | | OLCAck | | |--+--+--+--+--+--+--+--+--+->| ACK with updated SDP | | {Rx=128.59.21.152:10000} |===========================>| | | c=IN IP4 128.59.21.152 | | | m=audio 10000 RTP/AVP 8 | | OLC | | |--+--+--+--+--+--+--+--+--+->| | | {mode=g711Alaw} | | | | | | OLCAck | | |<--+--+--+--+--+--+--+--+--+-| | | {Rx=128.59.19.194:8000} | | Figure 11: Call from H.323 to SIP with Conversion between OLC and SDP Singh/Schulzrinne [Page 18]
Internet Draft May 16, 2000 SIP UA GW H.323 terminal 128.59.19.194 128.59.19.216 128.59.21.152 | | | | INVITE | | |============================>| Setup | | (To:kns10@columbia.edu) |--------------------------->| | (c=IN IP4 128.59.19.194) | (destination:kns10@cs.columbia.edu) | (m=audio 8000 RTP/AVP 0) | (fastStart={g711Ulaw,Tx} | | | {g711Ulaw,Rx,128.59.19.194:8000}) | | | | | Connect | | |<---------------------------| | | (fastStart absent) | | | | | | TCS | | |--+--+--+--+--+--+--+--+--->| | | {g711Ulaw Tx and Rx} | | | | | | TCSAck | | |<--+--+--+--+--+--+--+--+---| | | | | | TCS | | |<--+--+--+--+--+--+--+--+---| | | {g711Alaw and g711Ulaw} | | | | | | TCSAck | | |--+--+--+--+--+--+--+--+--->| | | | | | OLC | | |--+--+--+--+--+--+--+--+--->| | | {mode=g711Ulaw} | | | | | | OLCAck | | 200 OK |<--+--+--+--+--+--+--+--+---| |<============================| {Rx=128.59.21.152:10000} | | c=IN IP4 128.59.21.152 | | | m=audio 10000 RTP/AVP 0 | | | | | | ACK | | |============================>| OLC | | |<--+--+--+--+--+--+--+--+---| | | {mode=g711Ulaw} | | | | | | OLCAck | | |--+--+--+--+--+--+--+--+--->| | | {Rx=128.59.19.194:8000} | Singh/Schulzrinne [Page 19]
Internet Draft May 16, 2000 Figure 12: Call from SIP to H.323 with Conversion between OLC and SDP userinfo _ user [ ":" password ] hostport _ host [ ":" port ] host _ hostname | IPv4address url-parameters _ *(";" url-parameter) url-parameter _ user-param | ... In the url-parameter, only the user-param parameter is relevant. The user name may be a telephone number. H.323 addresses are typically sequences of Alias Addresses (see H.225.0 [8]). The ASN.1 description of an H.323 Alias Address is: H323-Alias-Address ::= CHOICE { e164 IA5String (SIZE(1..128)) (FROM("0123456789#*,")), h323-ID BMPString (SIZE (1..256)), ..., url-ID IA5String ( SIZE(1 .. 512)),-- URL Style address transport-ID TransportAddress, -- IPv4, IPv6, IPX etc.,... email-ID IA5String (SIZE(1..512)), -- rfc822 compliant email address partyNumber PartyNumber } The PartyNumber parameter is not described in this document and is left for further study. Telephone numbers can be conveyed via e164 field of H323-Alias-Address or called/calling party number fields of Q.931 message. 6.1 Converting SIP Addresses to H.323 Addresses 6.1.1 h323-ID The SIP-Address is stored as is in the h323-ID of the Alias Address. If the SIP-Address contains more than 256 characters, only the addr- spec part is copied. If the addr-spec exceeds 256 characters, the IWF generates a SIP response of 414 (Address Too Long). Each BMP character in h323-ID stores the corresponding text character in the SIP Address. (BMP stands for basic multilingual plane i.e., Basic ISO/IEC 10646-1 (unicode) character set) Singh/Schulzrinne [Page 20]
Internet Draft May 16, 2000 The h323-ID MUST always be generated so that a terminal running version 1.0 of H.323 (which supports only e164 and h323-ID, but does not support transport-ID, url-ID or email-ID) can still decode the address. 6.1.2 e164 If the SIP-Address's user is a telephone-subscriber, user-param is set to phone and the user part does not contain a "w", it is converted to the e164 field of Alias-Address. The e164 field only allows characters from the set "0123456789#*,". Thus, any leading "+" is removed from the SIP telephone-subscriber part, as are any visual separators "-" and ".". The pause "p" is replaced with ",". 6.1.3 url-ID The SIP-URL part of the SIP address is copied verbatim to the url-ID parameter. If the SIP URL exceeds 512 bytes in size, the IWF generates the SIP status 414 (Address too long). 6.1.4 email-ID The user and host parts are used to generate an email identifier, as in " user @ host ", which is stored in the email-ID field of AliasAddress. If the size exceeds 512 characters, the IWF generates the SIP status 414 (Address Too Long). 6.1.5 transport-ID If the host part of the SIP-URL is indicated as a dotted quad, it is translated into a transport-ID. If a port parameter is present in the SIP address, the number is used. Otherwise, the port number depends on the context. For example, for the destination address of H.323 SETUP messages, it is set to 1720, otherwise it is set to 0. Although a numeric IP address requires no further address resolution, it is worth noting that other fields (e164, url-ID, h323-ID) are also needed. If the destination is a VoIP gateway, for example, then an Internet telephony gateway destination is mapped from the e164 field or the called party number. 6.1.6 Examples o The SIP Address "sip:j.doe@big.com" is converted to an H.323 Address sequence with three elements: { h323- ID="sip:j.doe@big.com", url-ID="sip:j.doe@big.com", email- ID="j.doe@big.com" } Singh/Schulzrinne [Page 21]
Internet Draft May 16, 2000 o The SIP Address "sip:+1-212-555-1212:1234@gateway.com; user=phone" is converted to the H.323 Address: { e164="12125551212", h323-ID="sip:+1-212-555- 1212:1234@gateway.com", url-ID ="sip:+1-212-555- 1212:1234@gateway.com", email-ID="+1-212-555- 1212:1234@big.com"} o The SIP Address "sip:alice@10.1.2.3" is converted to H.323 Address: { h323-ID="sip:alice@10.1.2.3", url- ID="sip:alice@10.1.2.3", tranport-ID= IPAddress 10.1.2.3:1720, email-ID="alice@10.1.2.3" } o The SIP Address "A. Bell <sip:a.g.bell@bell-tel.com>" is converted to H.323 Address: { h323-ID="A. Bell <sip:a.g.bell@bell-tel.com>", url-ID="sip:a.g.bell@bell- tel.com", email-ID="A. Bell <a.g.bell@bell-tel.com>" } 6.2 Converting H.323 Addresses to SIP Addresses In H.323, addresses are typically a sequence of Alias Addresses (referred to as H.323 addresses in this document). Since it is not possible to convert all the addresses to a single SIP Address, the IWF will have to drop some of the addresses. However, an IWF MAY try more than one converted addresses either sequentially or in parallel. The conversion is done in the following order. If the conversion succeeds in one step, the conversion concludes and the remaining steps are ignored. If a url-ID is present and it is a SIP-URL, then it is used as is in the SIP Address. If an h323-ID is present and it can be parsed as a valid SIP-Address, it is used. This is needed when talking to an H.323 terminal running version 1.0. If the transport-ID is present and it does not identify the IWF, then it forms the hostport portion of the SIP URL and the user portion is constructed using h323-ID or e164. If the email-ID is present, then it is used in the SIP-URI. The email-ID is prefixed by the scheme name "sip:". If all these efforts fail, then the IWF MAY attempt to construct a legal SIP Address using the information available. For example h323- ID may become the display-name, e164 may become the user and host may be some default domain name. Singh/Schulzrinne [Page 22]
Internet Draft May 16, 2000 If the IWF is configured to route all calls to a default proxy, then it will forward whatever SIP addresses it can form (from the H.323 Alias Address) to the proxy. This may be needed when the IWF implementation is split into two (physically separate) parts, namely an H.323 terminal and a SIP user agent. The H.323 terminal receives the call, maps the H.323 address to the SIP address and forwards the request to the SIP proxy server. 7 Calculating a Common Subset of Capabilities The capability set of a terminal or a user agent refers to the set of algorithms for audio, video and data that it can support. It also conveys information about constraints in the selection of algorithms it may have. For example, due to limited bandwidth, a terminal may indicate that it can use either G.711 without video or G.723.1 with H.261 video. The operating mode of a call refers to the selected algorithms which are used for the actual transfer of media. To determine the operating mode for a call it is often necessary to find out the intersection of the capabilities of the endpoints in the conference. This section presents a way to calculate this intersection of the capability sets described by H.245 Terminal Capability Set (TCS) and that by SDP. A maximal intersection of two capability sets is a capability set which is a subset of both the capability sets and no other superset of the maximal intersection is a subset of those capability sets. It can be proven that if M is an operating mode for capability set C1 as well as for capability set C2, then M will be an operating mode for maximal intersection of C1 and C2. Thus, we fulfill requirement 5 described in Section 4. H.245 defines Terminal Capabilities as a list of capability descriptors, ordered in decreasing preference. Any one of the capability descriptors can be used for selecting operating modes. Each capability descriptor includes a simultaneous capability set. Each element in the simultaneous capability set is an alternative capability set. Each element in the alternative capability set represents an algorithm. Each algorithm has a payload type and can be fully described by the payload type, a profile and some optional attributes. Convention: { } capability descriptor or simultaneous capability set [ ] alternative capability set Singh/Schulzrinne [Page 23]
Internet Draft May 16, 2000 Example: Let a1, a2, a3, a4, a5 be audio algorithms and v1, v2, v3 be video algorithms. C1 represents a capability set with two capability descriptors: C1 = { [a1, a2, a3] [v1, v2] } { [a1, a4, a5] [v1] } Operating modes could be (a1, v1), (a1, v2), (a4, v1), (a5), etc. Note that (a4, v2) is not an operating mode since a4 and v2 are drawn from different capability descriptors. Let C2 be another capability set. C2 = { [a1, a4, a2] [v1, v2, v3] } { [a1, a2, a5] [v1, v3] } The maximal intersection of C1 and C2 is C = { [a1, a2] [v1, v2] } { [a1, a4] [v1] } { [a1, a5] [v1] } Note that there are other capability sets which are intersections of C1 and C2 (e.g., {[a1,a2][v2]}), but they are subsets of C and hence can be derived from C. 7.1 Algorithm for Finding Maximal Intersection of Capability Sets An algorithm to find the maximal intersection of any two capability sets C1 and C2 is given below: 1. Set the result C to the empty set. 2. For each pair of capability descriptors (d1, d2), where d1 is from C1 and d2 is from C2, derive the permutations of alternative sets, s1 and s2. For each such permutation, where s1 is from d1 and s2 is from d2, intersect s1 and s2 (written as s=s1 ^ s2) and add Singh/Schulzrinne [Page 24]
Internet Draft May 16, 2000 s to C. 3. Remove duplicate entries from C. Example: Using the example with C1 and C2 given above, the outer loop runs for four iterations, since C1 and C2 both have two descriptors. 1. d1 = {[a1,a2,a3][v1,v2]}, d2 = {[a1,a4,a2][v1,v2,v3]} Inner loop runs for 2 iterations: 1) {[a1,a2,a3]^[a1,a4,a2],[v1,v2]^[v1,v2,v3]} = {[a1,a2][v1,v2]} 2) {[a1,a2,a3]^[v1,v2,v3],[v1,v2]^[a1,a4,a2]} = {[][]} /* Empty set */ 2. d1 = {[a1,a4,a5][v1]}, d2 = {[a1,a4,a2][v1,v2,v3]} 1) {[a1,a4,a5]^[a1,a4,a2], [v1] ^[v1,v2,v3]} = {[a1,a4][v1]} 2) {[a1,a4,a5]^[v1,v2,v3],[v1]^[a1,a4,a2]} = {[][]} /* Empty set */ 3. d1 = {[a1,a2,a3][v1,v2]}, d2 = {[a1,a2,a5][v1,v3]} 1) {[a1,a2,a3]^[a1,a2,a5],[v1,v2]^[v1,v3]} = {[a1,a2][v1]} 2) {[a1,a2,a3]^[v1,v3],[v1,v2]^[a1,a2,a5]} = {[][]} /* Empty set */ 4. d1 = {[a1,a4,a5][v1]}, d2 = {[a1,a2,a5][v1,v3]} Singh/Schulzrinne [Page 25]
Internet Draft May 16, 2000 1) {[a1,a4,a5]^[a1,a2,a5],[v1]^[v1,v3]} = {[a1,a5][v1]} 2) {[a1,a4,a5]^[v1,v3],[v1]^[a1,a2,a5]} = {[][]} /* Empty set */ After these iterations the intersection set becomes { [a1,a2] [v1,v2] } { } { [a1,a2] [v1] } { } { [a1,a4] [v1] } { } { [a1,a5] [v1] } { } After removing duplicates, the maximal intersection is { [a1,a2] [v1,v2] } { [a1,a4] [v1] } { [a1,a5] [v1] } Since H.323 does not require that all algorithms listed within a single alternative capability have the same media type, we need the inner loop to find out all the possible combinations. For example, if C1 = {[a1,a2,a3] [a1,a4,v2,v1]} and C2 = {[a1,a4,v2] [v1,v2,v3]}, then the above algorithm correctly finds the intersection as {[a1] [v1,v2]} {[a1,a4,v2]} 8 Implementation Requirements This section lists the messages which MUST be supported by the signaling IWF. It also highlights the typical values for parameters for the messages. 8.1 H.323 (H.225.0 and H.245) All the messages which are mandatory in the Q.931 portion of H.225.0 and H.245 MUST be supported. RAS is optional; if used, all messages that are mandatory in RAS MUST be supported. Parameter values (if not specified in this document) MUST be derived from H.225.0 version 2.0 and H.245 version 4.0 for Q.931 and H.245 messages, respectively. This assures that requirement 1 in Section 4 is fulfilled. Singh/Schulzrinne [Page 26]
Internet Draft May 16, 2000 8.1.1 Handling of Q.931 Messages The IWF SHOULD support the Q.931 messages listed in Table 1. An entry of "not applicable" in the table means that it is not visible to the SIP endpoint and is only local to the IWF's H.323 stack. Message IWF sends to H.323 H.323 sends to IWF ________________________________________________________ Alerting Supported Supported Call proceeding Supported Supported Connect Supported Supported Progress Not applicable Not applicable Setup Supported Supported Setup Ack Not applicable Not applicable Release Complete Supported Supported User Information Not applicable Not applicable Information Not applicable Not applicable Notify Not applicable Not applicable Status Not applicable Not applicable Status Inquiry Not applicable Not applicable Facility Not applicable Not applicable Table 1: Support for Q.931 messages A "Not applicable" entry in the table means that it is not visible to the SIP endpoint and is only local to the IWF's H.323 stack. The IWF MUST NOT close the call signaling channel after the call is established. However, if the call is routed through a gatekeeper and the gatekeeper closes the call signaling channel, the IWF MUST comply with H.323 and MUST NOT assume that the call is closed as long as H.245 channel is open. If the Q.931 TCP connection is closed without closing the call signaling channel, then the IWF SHOULD try reopening the TCP connection, as specified by H.323. In case of failure such as TCP connection refused or TCP connection timeout, the IWF SHOULD close the call on the SIP side also by sending a BYE. Q.931-specific information elements, other than user-user information element (UUIE), do not affect the operation of this IWF, however they are required for interoperation with other H.323 entities. The specific fields of UUIE used in translating to SIP message are given in Appendix A. Bearer Capability: Singh/Schulzrinne [Page 27]
Internet Draft May 16, 2000 Information transfer capability (octet 3, bits 0--5): Unless some other restrictions apply (e.g., the IWF is connected to a bandwidth-restricted ISDN network), the parameter SHOULD be set to "unrestricted digital information" or "restricted digital information" on outgoing side. If the IWF knows that the call is going to be voice only, it may choose to set it as "speech" or "3.1 kHz Audio". The IWF ignores this field on incoming requests. Information Transfer Rate and Rate multiplier: If bandwidth information is available from the gatekeeper or some external means (e.g., from bandwidth information in SDP message), then information transfer rate and rate multiplier may be set to values reflecting the bandwidth, else they should be set to some high value as appropriate. This way the bandwidth is not limited to 64 kb/s or 128 kb/s. On the incoming side these values SHOULD be ignored. Note that in Q.931 message the only possible values are multiples of 64 kb/s. Layer 1 protocol (octet 5, bits 1--5): For outgoing Q.931 messages, the parameter is set to H.221 ('00101'), indicating an H.323 video phone call, unless the IWF knows that the call is going to be voice only (e.g., if this is hardcoded in the IWF). In that case, it may encode the parameter as G.711 A-law or mu-law to indicate this. For incoming Q.931 messages, the IWF ignores this field. Calling or Called party number: For outgoing Q.931 messages, the IWF translates the SIP request-URI into an e164 number, as described in Section 6. The calling/called party subaddress is not included in Q.931 messages originating from the IWF. For incoming Q.931 messages, the IWF relies on user-user information element for addresses (e.g., sourceAddress and destinationAddress fields of UUIE) and ignores the Q.931 parameter. However, if the calling/called party number is present and e164-ID is not present in the H.323 Alias Address then the calling/called party number is used instead of e164-ID while translating address in section 6. H.323 specifies that the called and calling party Singh/Schulzrinne [Page 28]
Internet Draft May 16, 2000 Subaddress fields are needed for some circuit switched call scenarios and they SHOULD NOT be used for packet based network side only calls. Display: For incoming Q.931 messages, the IWF MAY copy the Display IE to the display parameter of the SIP To header field. Similarly, for outgoing Q.931 messages, the Display parameter MAY be copied from the display parameter of the SIP To field. Cause: For incoming Q.931 messages, the Q.931 Cause information element and/or the UUIE reason field are mapped to the appropriate SIP status response code, as described in Table 2. H.225.0 [8] specifies that either the Cause information element or the releaseCompleteReason MUST be present. It also gives a mapping between the Cause information element and the releaseCompleteReason. Table 2 gives the mapping between releaseCompleteReason and the appropriate SIP status response. Similarly, for outgoing Q.931 messages, the Q.931 Cause information element and the UUIE reason field are derived according to Table 2. User-User-Information-Element: Below, we detail the fields in UUIE which are relevant to H.323-SIP conversion. Other fields are interpreted as defined by H.225.0. sourceInfo/destinationInfo: In all messages from the IWF, this field SHOULD be set to indicate that this endpoint is a gateway. However, the sequence of supported protocols in "GatewayInfo" may be empty. H.245SecurityMode, tokens, cryptoTokens: These fields are interpreted as in H.323. Note that since H.245 is terminated at the IWF, this kind of security information is not relevant to the SIP cloud. fastStart: FastStart PDUs contain the OpenLogicalChannel (OLC) messages. The IWF converts incoming OLC messages to a SDP message body. One SDP media description line ("m=") is generated for each distinct session-ID. All Singh/Schulzrinne [Page 29]
Internet Draft May 16, 2000 SIP status releaseCompleteReason ____________________________________________________________ 400 Bad Request undefinedReason 401 Authentication Required noPermission 402 Payment Required undefinedReason 403 Forbidden noPermission 404 Not Found unreachableDestination 406 Not Acceptable undefinedReason 407 Proxy Authentication Required noPermission 409 Conflict undefinedReason 410 Gone undefinedReason 413 Request Entity Too Large undefinedReason 414 Request-URI Too Large badFormatAddress 415 Unsupported Media Type undefinedReason 420 Bad Extension badFormatAddress 480 Temporarily not available unreachableDestination 483 Too Many Hops undefinedReason 484 Address Incomplete badFormatAddress 485 Ambiguous badFormatAddress 486 Busy Here destinationRejection 600 Busy Everywhere destinationRejection 603 Decline destinationRejection 604 Does not exist anywhere unreachableDestination Table 2: Mapping between SIP status codes and reason fields logical channels with same session-ID appear as payload types in a single SDP media description line. When converting SIP to H.323, the SDP message is converted to a list of OpenLogicalChannel messages, one per payload type. H.323 endpoint will select atmost one OLC per session-ID. This selected OLC is returned by the H.323 endpoint in the fastStart field of Q.931 Connect message. When converting H.323 to SIP, each OLC in fastStart corresponds to a payload type of SDP. All the OLC messages with same session-ID form a single media description ("m=") line. The parameters for the Q.931 SETUP message are listed below. sourceAddress: Converted to/from SIP header From field as described in section 6. destinationAddress: Converted to/from SIP header To field as described in section 6. Singh/Schulzrinne [Page 30]
Internet Draft May 16, 2000 destCallSignalAddress: If the To SIP header field contains a numeric host identifier then destCallSignalAddress is set to the IPv4 address represented by the numeric identifier. conferenceGoal: Set to "create" in outgoing Q.931 messages. (Additional values may be supported in future versions of this specification that support conferencing.) remoteExtensionAddress: Not present in outgoing Q.931 messages. For incoming Q.931 messages, this parameter is combined with the DestinationAddress parameter to generate the SIP To header field and the request-URI. mediaWaitForConnect: Set to "false" in outgoing Q.931 messages. Ignored in incoming Q.931 messages, as media transmission is transparent to the IWF. canOverlapSend: Set to "false" in outgoing Q.931 messages and ignored in incoming Q.931 messages since this version of the specification does not support overlap sending. Use of the Q.932 facility message for call redirection is for further study. 8.1.2 Handling H.245 Messages Table 3 details how an IWF handles H.245 messages. An entry of "not applicable" means that the message does not affect the behavior within the SIP cloud. The remainder of this subsection lists the possible values of some of the fields of H.245 messages. Refer to H.245 version 4.0 for description and details of the ASN.1 structures for H.245. MasterSlaveDetermination: The terminalType parameter is set to indicate that this terminal is a gateway. H.323 specifies a set of numerical values of terminalType for different types of terminals. For example, a gateway without a multipoint controller (MC) has a terminalType of 60; A gateway with a MC and no multipoint processor (MP) has a terminalType value of 80. Other values of terminalType are not relevant to this IWF in the case where media traffic is transparent. See H.323 [3] for other possible values of terminalType. Singh/Schulzrinne [Page 31]
Internet Draft May 16, 2000 Message REQUIRED or Not applicable MasterSlaveDetermination/Ack/Rej/Rel Not Applicable TerminalCapSet/Ack/Reject/Release REQUIRED Send TerminalCapabilitySet Not Applicable OpenLogicalChannel/Ack/Reject REQUIRED OpenLogicalChannelConfirm Not Applicable CloseLogicalChannel/Ack REQUIRED RequestChannelClose OPTIONAL RequestMode/Ack/Rej/Rel RECOMMENDED RoundTripDelayReq/Res Not applicable MaintenanceLoopReq/Ack/Reject Not supported MaintenanceLoopOffCmd Not supported CommunicationModeReq/Res/Cmd For further study ConferenceReq/Res/Cmd/Indic For further study EndSessionCommand REQUIRED FlowControlCommand For further study Encryption Command For further study Jitter Indication For further study User Input OPTIONAL H2250MaxSkewIndic For further study MClocationIndication For further study FunctionNotUnderstood Not Applicable FunctionNotSupported Not Applicable vendorIdentifier Not Applicable MiscCommand/Indication For further study Table 3: Support for H.245 messages. An entry of "not applicable" means that it is not visible to the SIP endpoint and is only local to the IWF's H.323 stack. TerminalCapabilitySet: multiplexCapability::h2250Capability: maximumAudioDelayJitter should be set to max possible value as specified by H.323. MultipointCapabilities should reflect minimum capability of Centralized Control/ Audio/ Video/ Data. Other conferencing capabilities are for further study. RTCP videoControlCapability should be set to false because anyway H.245 indications have to be used for this purpose. MediaPacketizationCapability should contain the information about the dynamic payload types used by SIP endpoint. Transport Capability should be absent. redundancyEncodingCapability should be absent. This is not supported in this version. logicalChannelSwitchingCapability may be supported by Singh/Schulzrinne [Page 32]
Internet Draft May 16, 2000 the IWF's H.323 stack. This makes mapping SIP re- INVITE easier. t120DynamicPortCapability is set to false because T120 data is not supported in this version. CapabilityTableEntry and CapabilityDescriptor are mapped from the session description given by SDP. A single capability descriptor is used in H.245. All the payload types on a single media description line (m=) are combined to form an alternative capability set in H.245. All such media description lines are combined to form a simultaneous capability set (or a capability descriptor). Mapping multiple SDP received in multipart body of SIP to multiple capability descriptor is for further study. Capability: H233Encryption is not applicable. H235Security is not applicable. DataApplication capability is not supported in this version of the specification. ConferenceCapability is for further study and is not supported in this version of the specification. UserInputCapability may be supported by the IWF. This is used to convey DTMF digits. Use of the SIP INFO method is being considered for this purpose. maxPendingReplacementFor is not applicable. Audio and Video: A capability in H.323 represents a payload type. Refer to http://www.iana.org/assignments/media-types/media-types for a list of MIME types and http://www.iana.org/assignments/rtp-parameters for a list of static RTP payload types. Use of static RTP payload types in SDP is discouraged. The IWF should maintain a list of all currently available payload types and media formats and the corresponding RFC numbers. (An intelligent IWF MAY periodically download and parse these HTML pages to update its database). Singh/Schulzrinne [Page 33]
Internet Draft May 16, 2000 The predefined audio and video capabilities are mapped to appropriate media format and RTP payload type. This mapping is given in this document for ease of reference. This mapping should be used by the IWF to convert the H.323 capability to an SDP media description. When converting from H.323 to SDP, the IWF SHOULD use dynamic payload type. When converting from SDP to H.323, the IWF SHOULD NOT use dynamic payload types because many current implementations do not support these. However, the IWF MUST be able to receive dynamic payload types, in both H2250Capability.MediaPacketizationCapabilty.RTPPayloadType and in H2250LogicalChannelParameters.MediaPacketization. When dynamic RTP payload type are used, H225LogicalChannelParameters.dynamicRTPPayloadType MUST match the payload type description given in mediaPacketization. AudioCapability: A subset of IANA-registered formats and H.323- supported capabilities are listed in Table 4. H.323 IANA payload type clock/channels RFC g711Alaw64k PCMA 8 8000/1 RFC1890 g711Ulaw64k PCMU 0 8000/1 RFC1890 g711Alaw56k N/A g711Ulaw56k N/A g722-64k G722 9 8000/1 RFC1890 g722-56k N/A g722-48k N/A g7231 G723 4 8000/1 None g728 G728 15 8000/1 RFC1890 g729 G729? Dynamic/18? 8000/1 - g729AnnexA ? Dynamic 8000/1 ? g729wAnnexB ? g729AwB ? g7231AnnexC ? gsmFullRate GSM 3 8000/1 RFC1890 gsmHalfRate GSM-HR Dynamic 8000/1 - gsmEnhFullRate GSM-EFR Dynamic 8000/1 - Table 4: Audio capability mapping Singh/Schulzrinne [Page 34]
Internet Draft May 16, 2000 Note that H.323 only supports a clock rate of 8000 Hz; other values cannot be mapped to H.323. SDP attribute "ptime" gives the maximum length of time in milliseconds represented by media in a packet. This can be used for defining the maximum packet length. TBD: A fmtp SDP attribute for silence suppression should be defined if silence suppression is on. TBD: Another possible fmtp attribute could be the list of annexes which are supported. This is useful in translating g729AnnexB, g729AnnexAwAnnexB, g7231AnnexC and so on to SDP. VideoCapability: The mapping of video encodings is shown in Table 5. The Video MPI (Mean Picture Interval) is mapped to the SDP attribute "framerate" as follows: mpi = 30 / framerate It is assumed that 29.97 Hz is rounded to 30 Hz when calculating the framerate. So MPI of 1 become framerate 30.0, similarly MPI of 2 becomes framerate 15. However, the IWF shall do proper rounding error correction on the incoming side. So framerate of 29.97 should also map to MPI of 1. Note that in SDP any possible value for framerate is allowed, but in H.323 only multiples of 1/29.97 are allowed. The IWF should convert the framerate to the next lower value allowed in H.323. For example, a framerate of 12.3 frames per second in SDP is converted to an MPI value of 3 which is equivalent to 10 frames per second. H.323 IANA Payloadtype clock RFC h261VideoCap H261 31 90000 RFC2032 h262VideoCap ? h263VideoCap H263/H263+? 34 90000 RFC2190/2429? Table 5: Video capability mapping. DataApplicationCapability: Not supported in this version of the specification. Singh/Schulzrinne [Page 35]
Internet Draft May 16, 2000 Use of RSVP (Resource reservation protocol) to handle QoS (Quality of service) is for further study. A Detailed Description of IWF Behavior This section describes how messages are processed by a SIP--H.323 signaling IWF. The discussion is split into two subsections, with SIP-originated requests discussed in Section A.1 and H.323-originated requests in Section A.2. Only fields relevant to the conversion are presented here. Other parameters are specific to either H.323 or SIP and can be generated by the respective protocol engine in the IWF without conversion. The IWF maintains, apart from other call-state information, the capability sets and operating mode for each call. Capability sets are maintained for each H.323 and SIP endpoint, both receive and transmit directions. Operating mode contains the modes in each direction (SIP to H.323 and H.323 to SIP). A.1 SIP-originated Requests A.1.1 IWF Receives REGISTER The IWF sends a RAS RRQ message to the H.323 GK, where the callSignalAddress is the address of the IWF, the terminalType is set to "gateway" and the terminalAlias is mapped from the To header of the REGISTER request. The IWF stores the SIP Contact header field. A "200 OK" SIP status response is sent after receiving a RAS RCF message. A.1.2 IWF Receives INVITE for a New Call The IWF MAY respond with a 100 (Trying) response to the SIP entity that sent the INVITE request. It stores the SDP information as the terminal's SIP capability and convert the capability to H.245 format. If the IWF is registered with a gatekeeper, send a RAS ARQ message to the gatekeeper, where the destinationInfo and destCallSignalAddress is derived from the To SIP header, the srcInfo is derived from the From SIP header field and srcCallSignalAddress is the call signaling address of the IWF itself. The gatekeeper assigns an endpointIdentifier during registration. That value of endpointIdentifier is used in the endpointIdentifier field of the ARQ message. Next, the IWF should receive either a RAS ACF or ARJ message. If an ACF message is received, establish an Q.931 channel as described Singh/Schulzrinne [Page 36]
Internet Draft May 16, 2000 below. If an ARJ message is received, the behavior depends on the reason parameter: CalledPartyNotRegistered: The IWF responds with 404 (Not Found). callerNotRegistered: The IWF MAY register, with a RAS RRQ message, the SIP address with the gatekeeper and then retransmit the RAS request, with the endpointIdentifier returned in RCF. Alternatively, it MAY send a 400 (Caller not registered) response to the SIP entity. incompleteAddress: Send 484 (Address Incomplete) response to SIP entity. Other reasons: Send 400 (H.323 translation failure) response to SIP entity. If the IWF times out waiting for an ARQ response, it sends a SIP 504 (Gateway time-out) response. If the IWF is not registered with a gatekeeper and it is able to resolve the SIP address to a H.323 address or if the IWF is registered and has received an ACF for the registration request from the gatekeeper, the IWF sends a Q.931 SETUP message to the H.323 entity, where the sourceAddress is derived from the SIP From header, the destinationAddress is derived from the SIP To header or from the RAS ACF response, destCallSignalAddress is derived from the RAS ACF response or from the To SIP header. The remoteExtensionAddress is copied from RAS ACF if present or extracted from To SIP header if possible. sourceCallSignalAddress is the call signaling transport address of the IWF. fastStart PDUs are mapped from the session description in the INVITE message body. Each SDP payload type entry is converted to an OLC message. All the payload types on the SDP same media description line have the same session id in the OLC messages. This identifies them as belonging to the same group and the receiving H.323 entity will select one of these. (TBD: needs more description) If the IWF receives a Q.931 CallProceeding message, send a 100 (Trying) response to the SIP entity, if not already sent. If fastStart PDUs are present, store them. If the IWF receives a Q.931 Alerting message, send a 180 (Alerting) response to the SIP entity, indicating that the final destination is ringing. If fastStart PDUs are present, store them. If the IWF receives a Q.931 Connect message, the behavior depends on Singh/Schulzrinne [Page 37]
Internet Draft May 16, 2000 whether a FastStart indication is present. If a FastStart indication is present, the IWF maps the received OLCs to the SDP payload types contained in the original INVITE request. Format a new SDP packet with more constrained media description and correct media transport address of the H.323 entity. Now each media description line will contain a single payload type, depending on which OLC PDUs are present. The operating mode and H.323 capability set are set to this reduced set of payloads. The SDP message is sent in a 200 (OK) response. The IWF then waits for the ACK request from the SIP entity. If the IWF times out, it declares the call closed and terminates the H.323 call. Once an ACK has been received, the IWF may proceed with other H.245 signaling (CESE, RTDSE and so on). If the H.323 entity does not support FastStart, the IWF proceeds with H.245 signaling as described below. First, it sends a TCS to the the H.323 entity and uses the stored SIP capability set to generate the H.245 capabilities. If the IWF receives an H.245 TCS message, it updates the H.323 capability set and calculates maximal intersection of H.323 and SIP capability sets (call this C). Derive a suitable operating mode from C (say, M). For each element in M (for the data from the SIP UA to the H.323 terminal), send an H.245 OLC message to the H.323 entity. Use the transport address of the SIP capability set, derived from the SDP received in the original INVITE message. If the IWF receives an OLC message and the logical channel is present in the operating mode from the H.323 terminal to the SIP UA, the IWF sends an OLCAck to the H.323 terminal. The OLCAck contains the transport address from the SIP capability set, again derived from the SDP in the INVITE message body. If the logical channel is not present in that operating mode, the IWF sends an OLCReject. Once the IWF has received an OLCAck or OLCRej for all outstanding OLC requests, it updates the operating mode and sends a 200 (OK) . response to the SIP entity. The session description in that response is formed using the new operating mode and the transport addresses received in the H.245 OLCAcks. The IWF should wait for the ACK request from the SIP entity. If the IWF times out, it should close the H.323 call. This concludes the description of the non-FastStart handling. If, at any time, the IWF receives a Q.931 ReleaseComplete message, a H.323 call could not be established. The IWF sends a 400 (Client Singh/Schulzrinne [Page 38]
Internet Draft May 16, 2000 Failure) with reason phrase "H.323 call failed". If the Q.931 SETUP times out, the IWF sends a 504 (Gateway time-out) response. If the SIP address is not resolved to an H.323 address, send a 501 (Not Implemented) response to SIP entity. A.1.3 IWF Receives INVITE for Existing Call o Update the SIP capability set. o Recalculate the operating mode, minimizing changes. An H.245 Mode Request message is sent if the operating mode has changed. If the Mode Request fails, either close the media channel or the call. A.1.4 IWF Receives BYE Request The IWF sends an H.245 Endsession to the H.323 entity. Upon receipt of a response or on timeout, the IWF sends a Q.931 ReleaseComplete to H.323 entity. If the call was admitted by a GK, send a RAS DRQ (Disengage Request) message to the GK. A.1.5 IWF Receives OPTIONS Request TBD: how do we querry H.323 capabilities without establishing the call? A.2 H.323-Originated Requests A.2.1 IWF Receives RAS GRQ The IWF sends a RAS GCF (Gatekeeper Confirm) response to GRQ (Gatekeeper Request) only if the IWF also contains a gatekeeper implementation (see Section 5.1.2). A.2.2 IWF Receives RAS RRQ This is possible only if the IWF also contains a gatekeeper implementation (see Section 5.1.2). On receipt of RRQ (Registration Request) the IWF sends a SIP REGISTER message to the SIP server where the To SIP header field is derived from the terminalAlias parameter; the Contact SIP header field indicates the IWF's location. The callSignalAddress received in RRQ message is stored internally by the IWF. The IWF may send multiple REGISTER requests if the sequence of terminalAlias can be mapped to multiple SIP addresses Singh/Schulzrinne [Page 39]
Internet Draft May 16, 2000 Once the IWF receives a 2xx response to this REGISTER, it sends a RAS RCF (registration confirmation) message to the H.323 entity. If it receives any other status response or the REGISTER request times out, the IWF sends a RRJ (registration reject) to the H.323 entity. A.2.3 IWF Receives RAS ARQ This is possible only if the IWF also contains a gatekeeper implementation (see Section 5.1.2). Receipt of this message indicates that the H.323 entity knows that the destination is reachable via this IWF. One simple implementation is to accept the admission request giving the callSignalAddress of the IWF itself. Alternatively, a procedure similar to that given for RAS LRQ, below, can be followed. A.2.4 IWF Receives RAS LRQ If the IWF receives a RAS LRQ (Location Request) message, the IWF sends an OPTIONS message to the SIP entity, where the SIP entity address is resolved from the H.323 address. The To SIP header field is derived from the destinationAddress. The IWF MAY send multiple forking OPTIONS requests if the sequence of destinationAddresses can be mapped to multiple SIP addresses. If it receives a 2xx response for the OPTIONS request, it sends a RAS LCF message to the H.323 with the CallSignalAddress of the IWF itself. If any other response is received or the request times out, the IWF MAY choose to remain silent or it may send a RAS LRJ to the H.323 entity. A.2.5 IWF Receives a Q.931 Setup The IWF generates an ARQ/ACF sequence if required here as per H.323 standard. However, that is local to the H.323 stack and does not affect translation. If fastStart is present, convert it to H.323 capability set, else build some default H.323 capability set. The IWF MAY send a Q.931 CallProceeding message to H.323 entity. The IWF then sends an INVITE, where the To SIP header field is derived from the Q.931 destinationAddress and/or destCallSignalAddress. If destinationAddress is the IWF itself, then use remoteExtensionAddress. The From SIP header field is derived from sourceAddress and/or srcCallSignalAddress. The session description is constructed from the H.323 capability set. If the IWF receives a 2xx response for the INVITE, it updates the SIP Singh/Schulzrinne [Page 40]
Internet Draft May 16, 2000 capability set using the session description in the response body. It then sends a Q.931 Connect message to the H.323 entity. Then, the IWF sends an ACK request to the SIP entity. Then, it sends an H.245 TCS to the H.323 entity using the SIP capability set. If it receives a TCS, it updates the H.323 capability set and calculates the maximal intersection of the H.323 and SIP capability sets, called C. From C, the IWF derives a suitable operating mode (say M). For each element in M in the direction from SIP to H.323, send a H.245 OLC to the H.323 entity. The OLC messages use the transport addresses of the SIP capability set, derived from the session description in the 2xx response body. If the IWF receives an OLC and the logical channel is present in the operating mode from H.323 to SIP, it responds with an OLCAck. The OLCAck uses the transport addresses of the SIP capability set. If the logical channel is not present in the operating mode, the IWF sends an OLCReject Once the IWF has received OLCAck or OLCRej for all the requests, update the operating mode. Then, the IWF sends a re-INVITE. The session description is formed using the new operating mode if it is different from what was sent in the first INVITE message and the transport addresses received in OLCAcks. The IWF should wait for a 2xx response from the SIP entity and respond with an ACK request. If it times out or if it fails, it should close the call. If the IWF receives a 180 (Alerting) SIP response, send a Q.931 Alerting message to the H.323 entity. If the IWF receives any other 1xx SIP response, it sends a Q.931 CallProceeding message to H.323, but only if not already sent for this call. If no response is received or a failure response, the IWF sends a Q.931 ReleaseComplete message to the H.323 entity. A.2.6 IWF Receives Mode Request or Change in Logical Channels Update operating modes, Send re-INVITE to SIP entity. If that fails then reject the Mode Request or Open Logical Channel request. A.2.7 IWF Receives H.245 EndSession If the IWF receives a H.245 EndSession, it closes the H.245 call. Singh/Schulzrinne [Page 41]
Internet Draft May 16, 2000 Send H.245 EndSession and Q.931 ReleaseComplete to H.323 entity and send RAS DRQ to gatekeeper if it admitted the call. A.2.8 IWF Receives Q.931 ReleaseComplete If the IWF receives a Q.931 ReleaseComplete, the H.323 side of the call is closed. The IWF sends a BYE to the SIP entity if the call has been established. A.2.9 IWF Receives RAS DRQ If the call is active, close it. Send RAS DCF (disengage confirm) to H.323 entity. A.2.10 IWF Receives RAS URQ If the IWF receives a RAS URQ (unregister request) message, the behavior depends on whether the IWF also acts as a gatekeeper. If the IWF also contains a gatekeeper, unregister the endpoint as specified by RAS. otherwise the request must have come from a gatekeeper. Close all the associated calls on both SIP and H.323 sides and send a RAS UCF (unregister confirm) to the H.323 entity. B H.323 Call Without Fast-Connect Message flow for normal call connect in H.323 between two terminals registered with different gatekeepers is shown in Fig. 13. C Acknowledgments We would like to thank Chris Kang, Jonathan Lennox and Gautam Nair for their help in implementation and general discussions. The work described here was supported by Sylantro. D Authors' Addresses Kundan Singh Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA electronic mail: kns10@cs.columbia.edu Henning Schulzrinne Dept. of Computer Science Columbia University Singh/Schulzrinne [Page 42]
Internet Draft May 16, 2000 H.323 Terminal 1 GK1 GK2 H.323 Terminal 2 | | | | |~~~~~ GRQ ~~~~~~~~~>| |<~~~~~~~ GRQ ~~~~~~~~~~| (Gatekeeper |<~~~~ GCF ~~~~~~~~~~| |~~~~~~~~ GCF ~~~~~~~~~>| Discovery) |~~~~~ RRQ ~~~~~~~~~>| |<~~~~~~~ RRQ ~~~~~~~~~~| (Registration) |<~~~~ RCF ~~~~~~~~~~| |~~~~~~~~ RCF ~~~~~~~~~>| |~~~~~ ARQ ~~~~~~~~~>| | | (Admission) | |~~~~ LRQ ~~~>| | | |<~~~ LCF ~~~~| | |<~~~~ ACF ~~~~~~~~~~| | | | | |--------------------- Setup ----------------------------->| (Q.931 setup) |<-------------------- Call Proceeding --------------------| | |<~~~~~~~ ARQ ~~~~~~~~~~| | |~~~~~~~~ ACF ~~~~~~~~~>| (Admission) |<-------------------- Alerting ---------------------------| (Ringing) |<-------------------- Connect ----------------------------| (Q.931 successful) | | |-+--+--+--+--+--+--+- Terminal Capability Set -+--+--+--->| (H.245/CESE) |<---+--+--+--+--+--+- Terminal Capability Set Ack +--+----| |<---+--+--+--+--+--+- Terminal Capability Set -+--+--+----| |-+--+--+--+--+--+--+- Terminal Capability Set Ack +--+--->| | | ... Master Slave Determination and Round Trip Delay not shown ... | | |-+--+--+--+--+--+--+- Open Logical Channel -+--+--+--+--->| (H.245/LCSE) |<---+--+--+--+--+--+- Open Logical Channel Ack +--+--+----| |<---+--+--+--+--+--+- Open Logical Channel -+--+--+--+----| |-+--+--+--+--+--+--+- Open Logical Channel Ack +--+--+--->| | | |<---+--+--+--+--+--+- EndSessionCommand -+--+--+--+--+----| (Terminating) |-+--+--+--+--+--+--+- EndSessionCommand -+--+--+--+--+--->| |--------------------- Release Complete ------------------>| (Q.931 closed) |~~~~~ DRQ ~~~~~~~~~>| |<~~~~~~~ DRQ ~~~~~~~~~~| (RAS Disengage) |<~~~~ DCF ~~~~~~~~~~| |~~~~~~~~ DCF ~~~~~~~~~>| Figure 13: H.323 Call Without Fast-connect 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA electronic mail: schulzrinne@cs.columbia.edu E Bibliography Singh/Schulzrinne [Page 43]
Internet Draft May 16, 2000 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments (Proposed Standard) 2543, Internet Engineering Task Force, Mar. 1999. [2] M. Handley and V. Jacobson, "SDP: session description protocol," Request for Comments (Proposed Standard) 2327, Internet Engineering Task Force, Apr. 1998. [3] International Telecommunication Union, "Packet based multimedia communication systems," Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998. [4] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a transport protocol for real-time applications," Request for Comments (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. [5] International Telecommunication Union, "Digital subscriber signalling system no. 1 (dss 1) - isdn user-network interface layer 3 specification for basic call control," Recommendation Q.931, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Mar. 1993. [6] International Telecommunication Union, "Control protocol for multimedia communication," Recommendation H.245, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998. [7] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, Mar. 1997. [8] International Telecommunication Union, "Media stream packetization and synchronization on non-guaranteed quality of service LANs," Recommendation H.225.0, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Nov. 1996. Full Copyright Statement Copyright (c) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Singh/Schulzrinne [Page 44]
Internet Draft May 16, 2000 Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Table of Contents 1 Introduction ........................................ 1 2 Scope of This Document .............................. 2 3 Terminology and Conventions ......................... 2 4 Translation Requirements ............................ 3 5 Call Scenario ....................................... 4 5.1 User Registration and Address Resolution ............ 5 5.1.1 IWF Contains SIP Proxy Server and Registrar ......... 5 5.1.2 IWF Contains an H.323 Gatekeeper .................... 6 5.1.3 IWF Does Not Contain Gatekeeper or Registrar ........ 6 5.1.4 Direct Connection ................................... 10 5.2 Call Establishment .................................. 10 5.2.1 Call Establishment with H.323v2 Fast Connect ........ 13 5.2.2 Call Establishment without H.323v2 FastConnect ...... 13 5.2.3 Call from H.323 cloud to SIP cloud with H.245 TerminalCapabilitySet (TCS) Mapped to SDP ...................... 14 5.2.4 Call from H.323 Cloud to SIP Cloud Mapping H.245 Open Logical Channel (OLC) to SDP .............................. 16 6 Address Conversion between H.323 and SIP ............ 17 6.1 Converting SIP Addresses to H.323 Addresses ......... 20 6.1.1 h323-ID ............................................. 20 6.1.2 e164 ................................................ 21 6.1.3 url-ID .............................................. 21 6.1.4 email-ID ............................................ 21 6.1.5 transport-ID ........................................ 21 6.1.6 Examples ............................................ 21 Singh/Schulzrinne [Page 45]
Internet Draft May 16, 2000 6.2 Converting H.323 Addresses to SIP Addresses ......... 22 7 Calculating a Common Subset of Capabilities ......... 23 7.1 Algorithm for Finding Maximal Intersection of Capability Sets ................................................ 24 8 Implementation Requirements ......................... 26 8.1 H.323 (H.225.0 and H.245) ........................... 26 8.1.1 Handling of Q.931 Messages .......................... 27 8.1.2 Handling H.245 Messages ........................ 31 A Detailed Description of IWF Behavior ...... 36 A.1 SIP-originated Requests ............................. 36 A.1.1 IWF Receives REGISTER ............................... 36 A.1.2 IWF Receives INVITE for a New Call .................. 36 A.1.3 IWF Receives INVITE for Existing Call ............... 39 A.1.4 IWF Receives BYE Request ............................ 39 A.1.5 IWF Receives OPTIONS Request ........................ 39 A.2 H.323-Originated Requests ........................... 39 A.2.1 IWF Receives RAS GRQ ................................ 39 A.2.2 IWF Receives RAS RRQ ................................ 39 A.2.3 IWF Receives RAS ARQ ................................ 40 A.2.4 IWF Receives RAS LRQ ................................ 40 A.2.5 IWF Receives a Q.931 Setup .......................... 40 A.2.6 IWF Receives Mode Request or Change in Logical Channels ....................................................... 41 A.2.7 IWF Receives H.245 EndSession ....................... 41 A.2.8 IWF Receives Q.931 ReleaseComplete .................. 42 A.2.9 IWF Receives RAS DRQ ................................ 42 A.2.10 IWF Receives RAS URQ ................................ 42 B H.323 Call Without Fast-Connect ..................... 42 C Acknowledgments ..................................... 42 D Authors' Addresses .................................. 42 E Bibliography ........................................ 43 Singh/Schulzrinne [Page 46]