[-Internet Engineering Task Force Hemant Agrawal Internet Draft Telverse Communications draft-agrawal-sip-h323-interworking-01.txt Radhika R Roy July 13, 2001 AT&T Expires: Jan 2002 Vipin Palawat Cisco Systems Inc Alan Johnston MCI WorldCom Charles Agboh Ebone David Wang Nuera Communications Inc Henning Schulzrinne Kundan Singh Columbia University Joon Maeng ipDialog Inc SIP-H.323 Interworking Status of this Memo-] This [-document is an-] Internet-Draft [-and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. Internet-Drafts are working-] {+has been deleted. Unrevised+} documents [-of-] {+placed in+} 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-] {+directories have+} a maximum {+life+} 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-] {+months. After that time, they are deleted. This Internet-Draft was not published+} as [-"work in progress." The list of current-] {+an RFC.+} 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. This document is a product of the SIP-H.323 Interworking Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mailing list sip-h323@yahoogroups.com.com. Copyright Notice Copyright (c) The Internet Society (2000). All Rights Reserved. Abstract This-] {+are not an archival+} document [-describes the interworking between SIP-] {+series,+} and [-H.323 protocol. It defines the the logical entity known-] {+expired drafts, such+} as [-the SIP-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between the SIP (Session Initiation Protocol) and H.323 protocol. This includes the call sequence mapping, message parameter mapping, translation between H.245 and SDP, state machines, and handling of different call procedures. Agrawal, et al. [Page 1] Internet Draft SIP-H.323 Interworking July 2001 Table of Contents 1. Terminology 2. Introduction 3. Background 4. Scope of the document 5. Definitions 6. Overview of IWF Functionality 7. Interworking Requirements for IWF 8.Mapping Between SIP and H.323 in IWF 8.1. Alias Addresses Mapping 8.1.1. Converting SIP Addresses to H.323 Addresses 8.1.2. Converting H.323 Addresses to SIP Addresses 8.2 Message Mapping 8.3 Call Sequence Mapping 8.4 Message Parameters Mapping 8.5 Audio/Video Formats Mapping 9. Basic Message Handling 9.1 Handling of H.323 Signaling Messages 9.2 Handling of SIP Signaling Messages 10.Interworking Call Scenarios for Different Configurations 11. State Machine 12. Implementation Requirements 13. Activities Planned for Next Phase 14. Security Considerations 15. Known Issues 16. To Be Done 17. Conclusion Appendix A: Calculating common subset of capabilities Appendix B: Modification in ASN.1 syntax of H.225 Appendix C: Call Flow Message Details Appendix D: Summary of SIP-H.323 Interworking Requirements References Acknowledgments Authors' Addresses Full Copyright Statement 1 Terminology 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 [2] and indicate requirement levels for compliant implementations. 2. Introduction The primary objective of SIP-H.323 Interworking function (IWF) is to provide protocol conversion between SIP and H.323 protocol. Both of these protocols use similar formats (e.g. RTP) to transfer media (audio/video/data) over the Packet Network. It is, therefore, required Agrawal, et al. [Page 2] Internet Draft SIP-H.323 Interworking July 2001 to perform the mapping between SIP and H.323 signaling messages only to achieve the interworking between the two protocols. The objective is to transmit media end-to-end directly between the two end systems in H.323 and SIP networks. However, some of the special scenarios may require media to be routed through the IWF using MSF. Such scenarios are out of the scope of the current document. The logical relationship between the IWF and other SIP and H.323 entities is shown in Figure 1. H.323 Entity SIP Entity +---------------+ | H.323 GK | +----------------+ | |\ | SIP | +---------------+ \ | Server | \ /+----------------+ \ / +---------------+ +---------------+/ | H.323 MCU |----| Interworking | | MC,or Terminal| | Function | +---------------+ +---------------+\ / \ / \+----------------+ +---------------+ / | SIP | | H.323 Gateway |/ | User Agent | | | +----------------+ +---------------+ Figure 1 : Logical Relationship between IWF and SIP/H.323 entities 3. Background Two standards-] {+one,+} are [-currently popular for IP telephony signaling: the H.323 protocol suite by ITU-T, and the Session Initiation Protocol (SIP) by IETF. Both of these signaling protocols provide mechanisms-] {+not available; please do not ask+} for [-call establishment and teardown, call control and supplementary services, and capability exchange. In terms of functionality and services that can be supported, H.323 version 2 [5] and SIP Version 2 [3] are very similar. However, supplementary services in H.323 are quite different from SIP. H.323 and SIP are improving themselves and the differences between them are diminishing with each new version. At present, H.323 and SIP networks are coexisting with different service providers in many parts of the world as-] {+copies...+} they [-think to provide services to satisfy their customers' needs. Agrawal, et al. [Page 3] Internet Draft SIP-H.323 Interworking July 2001 +-----------+--------+--------+-------+--------+---------+------+ | H.225 | | | | H.225 | Codecs | | | Call | SDP | H.245 | SIP | RAS |-------- | RTCP | | Signaling | | | | | RTP | | +-----------+--------+--------+---+---+--------+---------+------+ | | | | TCP | UDP | | | | +-----------+--------+--------+-------+--------+---------+------+ | | | IP | | | +-----------+--------+--------+-------+--------+---------+------+ | | | Linked and Physical Layer | | | +-----------+--------+--------+-------+--------+---------+------+ Figure 2: SIP and H.323 Protocol stacks SIP-H.323 IWF is a solution for those service providers who want to support both H.323 and SIP networks. There-] are [-different forums involved in the standardization of SIP-H.323 IWF. The aim of all these forums is to provide an agreed upon specifications so that there will be no interoperability issues between different vendor implementations. This work is also under progress in ETSI TIPHON and IMTC aHit! forums. 4. Scope of this document This document describes interworking between H.323 Version 2.0 [5] and SIP Version 2.0 [3]. However, since H.323v2 terminal may or may-] not [-support FastConnect, solutions without using this feature are also detailed in this document. This Interworking recommendation is being defined in two phases. The Current (first) phase defines the basic call establishment, call termination. It also defines the translation between H.245 and SDP for session description.-] {+available.+} The [-second phase will include optional messaging of the two protocols, advanced features and services. Both phases-] {+Secretariat does not+} have {+information as+} to [-meet the general requirements specified in the SIP-H323 Interworking Requirement draft [9]. The support for-] future [-versions-] {+plans+} of [-H.323 and SIP MAY be addressed in the next phase. 5. Definitions Endpoint (EP): This is an entity from which-] the [-media originates or finally terminates. This can either be H.323 terminal-] {+authors+} or [-SIP user agent. Agrawal, et al. [Page 4] Internet Draft SIP-H.323 Interworking July 2001 H.323 Gatekeeper (GK) : The Gatekeeper (GK) is an OPTIONAL H.323 entity on the network that provides address translation and controls access to the network for H.323 terminals, Gateways and MCUs. The Gatekeeper may also provide other services to the terminals, Gateways and MCUs such as bandwidth management and locating Gateways. H.323 Terminal: A H.323 Terminal is an endpoint on the network which provides-] {+working groups WRT+} the [-real-time, two-way communications with another H.323 terminal, Gateway,-] {+deleted Internet-Draft. For more information+} or [-Multipoint Control Unit. This communication consists-] {+a copy+} of [-control, indications, audio, moving color video pictures, and/or data between-] the [-two terminals. A terminal may provide speech only, speech and data, speech and video, or speech, data and video. H.323 Side: The H.323 side of the IWF is the part of the IWF that terminates and originates H.323 signaling from and to the H.323 network respectively. Interworking Function (IWF): It allows interworking between the H.323 and SIP networks. Media Switching Function (MSF): This is an OPTIONAL logical entity present in the IWF, which will perform the task of witching/transcoding RTP from one logical port to other. SIP User Agents (UA): A logical entity which can act as both SIP user agent client and SIP user agent server. SIP Server: This can be either SIP Proxy, Redirect, Location or Registrar server. SIP Proxy Server: A logical entity which acts as both server and a client. SIP messages will be processed and passed to other SIP entities. A SIP proxy server interprets, and, if necessary, rewrites a SIP message before forwarding it. SIP Redirect Server: A logical entity which is primarily used for address translation and locating a SIP user. It may take the help of location server for locating a SIP user. SIP redirect server does not accept calls and does not initiate a SIP request on behalf of a calling SIP endpoint. SIP redirect server sends a response to a request for locating a SIP user. SIP Location Server: A location service is used by a SIP proxy or SIP redirect server to obtain information about the callee's possible location(s). SIP Registrar Server: A SIP registrar is a server that accepts REGISTER requests from SIP endpoints. A SIP registrar is typically co-located with a SIP proxy or SIP redirect server and MAY make its information available through the location server. Agrawal, et al. [Page 5] Internet Draft SIP-H.323 Interworking July 2001 SIP Side: The SIP side of the IWF is the part of the IWF that terminates and originates SIP signaling from and to the SIP network respectively. 6. Overview of IWF Functionality When the IWF receives call signaling messages from an H.323 entity, it performs the necessary translation and sends the corresponding equivalent messages to SIP entity on the SIP side of the IWF and vice versa. The IWF SHALL provide signaling translation for all phases of a call. This IWF does not include media format conversion. However, it MAY include a Media Switching Function for switching RTP packets which is out of scope of this document. +---------------------------------------+ | +--------------------+ | | | SIP-H.323 | | | | Interworking | | | | Function | | | +--------------------+ | | / \ | | +---------------+ +---------------+ | | | | | | | | | H.323 Stack | | SIP Stack | | | | | | | | | +---------------| +---------------+ | +---------------------------------------+ / \ +-------------+ +------------+ | | | | | H.323 | Media Flow | SIP | | Network |========================| Network | +-------------+ +------------+ Figure 3: Overview of the IWF There are several scenarios where SIP-H.323 IWF can be placed with different network elements in the SIP and H.323 networks. The way the messages are generated during a call establishment between H.323 EP and a SIP UA, is different depending on the scenario. Scenario 1: IWF without H.323 GK and SIP Server +----------+ +--------+ +--------+ | | | | | | | H.323 EP |<---------------->| IWF |<----------------->| SIP UA | | | | | | | +----------+ +--------+ +--------+ Agrawal, et al. [Page 6] Internet Draft SIP-H.323 Interworking July 2001 Scenario 2: IWF with H.323 GK and without SIP Server +----------+ +----------+ +--------+ +---------+ | | | | | | | | | H.323 EP |<->| H.323 GK |<->| IWF |<---------------->| SIP UA | | | | | | | | | +----------+ +----------+ +--------+ +---------+ Scenario 3: IWF with SIP Server and without SIP Server +----------+ +--------+ +----------+ +---------+ | | | | | Proxy or | | | | H.323 EP |<---------------->| IWF |<->| Redirect |<->| SIP UA | | | | | | Server | | | +----------+ +--------+ +----------+ +---------+ Scenario 4: IWF with H.323 Server and SIP Server +------_---+ +----------+ +--------+ +----------+ +--------+ | | | | | | | Proxy or | | | | H.323 EP |<->| H.323 GK |<->| IWF |<->| Redirect |<->| SIP UA | | | | | | | | Server | | | +----------+ +----------+ +--------+ +----------+ +--------+ The IWF can be configured manually similar to SIP servers , H.323 GKs and GWs or one can use DNS SRV or DNS. 7. Interworking Requirements for IWF The requirement for SIP-H.323 IWF has already been addressed in detail in "SIP-H.323 Interworking Requirements" [9]. The summary of SIP-H.323 interworking requirements is given for reference in Appendix D. 8. Mapping Between SIP and H.323 in IWF 8.1. Addresses Mapping There are different formats of alias addresses in H.323 and the corresponding addresses in SIP. H.323 Version 2 supports the following schemes of alias addresses: H323Id, E164Id, Email Id, url Id, transport Id and partyNumber H.323 Version 1 supports only H323Id and E164Id. The ASN.1 description of an H.323 Alias Address in H.323 Version 2 is: H323-Alias-Address ::= CHOICE { Agrawal, et al. [Page 7] Internet Draft SIP-H.323 Interworking July 2001 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 that contains public numbering plan or data/telex/private/public numbering digits is not described in this document and is left for further study. On the other hand, SIP address can be defined by the following BNF from the description provided in RFC 2543 [3]: SIP-Address - (name-addr | addr-spec) name-addr - [display-name] "<" addr-spec ">" addr-spec - SIP-URL|URI SIP-URL - "sip:"[userinfo"@"]hostport url-parameters [headers] userinfo - [user|telephone-subscriber][":"password] user - *(unreserved|escaped|"&"|"="|"+"|"$"|"," |";"|"?"|"/") password - *(unreserved|escaped|"&"|"="|"+"|"$"|",") hostport - host[":"port] host - hostname|Ipv4address|IPV6reference hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum toplabel = alpha | alpha *( alphanum | "-" ) alphanum IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit port = *digit url-parameters - *(";"url-parameter) url-parameter - transport-param | user-param | method-param | ttl-param | maadr-param | other-param ttl = 1*3DIGIT ; 0 to 255 maddr-param = "maddr=" host user-param = "user=" ( "phone" | "ip" ) method-param = "method=" Method other-param = ( token | ( token "=" ( token | quoted-string ))) headers = "?" header *( "&" header ) header = hname "=" hvalue hname = 1*uric hvalue = *uric uric = reserved | unreserved | escaped reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," digits = 1*DIGIT The SIP URI components can be described as stated below : Agrawal, et al. [Page 8] Internet Draft SIP-H.323 Interworking July 2001 telephone-subscriber = global-phone-number | local-phone-number global-phone-number = "+" 1*phonedigit [isdn-subaddress] [post-dial] local-phone-number = 1*(phonedigit | dtmf-digit | pause-character) [isdn-subaddress] [post-dial] isdn-subaddress = ";isub=" 1*phonedigit post-dial = ";postd=" 1*(phonedigit | dtmf-digit | pause-character) phonedigit = DIGIT | visual-separator visual-separator = "-" | "." pause-character = one-second-pause | wait-for-dial-tone one-second-pause = "p" wait-for-dial-tone = "w" dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D" Alias address are mapped based on procedures described in the subsequent sections. 8.1.1. Converting SIP Addresses to H.323 Addresses * E164 SIP URL which contains the "user=phone" and does not contain a "w" in the user part will be mapped to E164 Id of H323. 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 ".". For example: +1-978-985-7193 will be converted to "19789857193". The pause "p" is replaced with ",". If the phone number exceeds 128 characters, the IWF generates a SIP response of 414 (Request-URI Too Long). E164 in H.323 can be either E.164 number in H.323 Alias Address or it may also be derived from the caller/callee number in Q.931 messages. Thus, SIP URL with phone numbers may also be mapped to caller/callee number in Q.931 messages. SIP URL which do not contain "user=phone", but contains numerical digits in user part may be converted to E164 numbers. The conversion of tel Url to E164 number is for further discussion. * H323Id In most of the cases, userinfo part of SIP URL will be mapped to H323 Id of H323. 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). Agrawal, et al. [Page 9] Internet Draft SIP-H.323 Interworking July 2001 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. 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 (Request-URI Too Long). * Email Id If the SIP URL looks like an Email Id i.e. user@group, then it will be mapped to Email Id of H323. To indicate an email-like address, an H.323v1 entity shall send it in H323-ID and prefix it with the seven characters "mailto:". In this case the string after the colon must be an RFC 822 compliant email address. An example of such an address is as follows: mailto:abc@company.com If the size exceeds 512 characters, the IWF generates the SIP status 414 (Request-URI Too Long). * Transport Id If the SIP URL contains the IPv4 address in the host part, then it will be mapped to the transport Id of H323. To indicate an IP-like address, an H.323v1 entity shall send it in H323-ID and prefix it with the three characters "ip:". In this case the string after the colon must contain an address in dotted decimal form, with an optional colon and port number at the end. An example of such an address is as follows: ip:10.0.0.1:5050. 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. * Url Id If the SIP URL looks like a url i.e., user@domain, then it will be mapped to the url Id of H323. If the SIP URL exceeds 512 bytes in size, the IWF generates the SIP status 414 (Request-URI too long). Examples of Address Resolution o The SIP Address "sip:j.doe@big.com" is converted to H.323 Address: { h323-ID = "sip:j.doe@big.com", url-ID = "sip:j.doe@big.com", email-ID= "j.doe@big.com" } Agrawal, et al. [Page 10] Internet Draft SIP-H.323 Interworking July 2001 o The SIP Address "sip:+1-212-555-1212:1234@iwf.com; user=phone" is converted to H.323 Address: { e164 = "12125551212", h323-ID = "sip:+1-212-555-1212:1234@iwf.com", url-ID = "sip:+1-212-555-1212:1234@iwf.com", email-ID= "+1-212-555-1212:1234@iwf.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 " is converted to H.323 Address: { h323-ID = "A. Bell", url-ID = "sip:a.g.bell@bell-tel.com", email-ID = "A. Bell " } 8.1.2. Converting H.323 Addresses to SIP Addresses *E164 Id It will be put in a SIP URL with a telephone number. The number will either be globalized or left as a local number in which case it will require the information of From header. "phone-context" is used to represent the local number. sip:telephone-subscriber@host; user=phone For Example: E164Id = +1-719-227-9665 can be mapped to sip:+1-719-227-9665@host;user=phone 'host' is a host name (domain name of IPv4 address) followed by an optional port number. It is a mandatory in SIP URL. The E164 Id in H.323 does not provide any direct information of the host part of the SIP URL (the host part should identify a SIP server with the IPv4 address of the domain name). The host part may be determined using some specialized service either by location server or by pre-provisioning in IWF. If Called/Calling Party Number is present in H.323 messages (other than UUIE part of Q.931 message), it may be treated like a E164 Id and mapping may be done as discussed above. The mapping of E164 address to tel Url is for further discussion. Agrawal, et al. [Page 11] Internet Draft SIP-H.323 Interworking July 2001 *H323Id It will be mapped to userinfo part of SIP URL. If the H323 Id is similar to "mailto:user@domain", then it should be mapped to SIP URL after replacing "mailto:" with "sip:" However for the cases where H323 Id is in the form of an email id with fully qualified domain name, it may be used as a SIP URL. However, it shall not result into more than one '@' in the SIP URL. *EmailId It will be mapped to SIP-URL/URI after adding the "sip:" prefix. For Example: email ID = userA@gateway.iwf.com will be mapped to sip:userA@gateway.iwf.com *UrlId It will be mapped to SIP URL after adding the "sip" prefix if it is not present in the url Id. For Example: url Id = h225://userA@gateway.iwf.com:2030 will be mapped to sip:userA@gateway.iwf.com:2030 *Transport Id It will be mapped to host part of SIP URL if it is a IPv4 address. User part of SIP URL in this case may be mapped to either H323 Id, Email Id or E164 Id. If no port is specified then the default port number 5060 will be used. The IWF SHOULD not map transport Id to SIP URL if it corresponds to the IP address of IWF itself. In this case, the other aliases will reflect the callee address. For Example: Transport Id = 164.164.28.132 can be mapped to sip:164.164.28.132:5060 Transport Id = 164.164.28.132:2030 can be mapped to sip:164.164.28.132:2030 Zone prefix in H.323 non-standard parameter of registration MAY be used during address resolution on H.323 Gatekeeper. This will be further discussed in next release of this draft. In cases with no H.323 Address, the H.323 Transport Address (TSAP) may be used for the SIP Url with the user name as "Unknown". The H.323 call signaling port, if default should be coverted into default SIP port address. For example. H.323 destination address 198.192.12.35:1720 can be converted into sip:unknown@198.192.12.35:5060 Agrawal, et al. [Page 12] Internet Draft SIP-H.323 Interworking July 2001 8.2. Message Mapping Some of the SIP and H.323 messages have direct one to one mappings. These are listed below. These tables hold good for both conversions i.e. SIP messages to H.323 messages and vice versa. SIP Message H.323 Message ------------ ------------- INVITE SETUP (without GK in network) INVITE ARQ (with GK in network) OPTIONS(Accept:application/sdp) H.245 Send Terminal Capability Set 180 Ringing H.225 Alerting 183 Session Progress H.225 Alerting/Progress 300 Multiple Choices H.225 ReleaseComplete (reason=undefinedReason) 301 Moved Permanently ACF with updated Address of SIP's Contact header field (If GK is present) or update local lookup table. 302 Moved Temporarily ACF with updated Address of SIP's Contact header field (If GK is present) or update local lookup table. 380 Alternative Service H.225 Facility 400 Bad Request H.225 ReleaseComplete (reason=undefinedReason) 401 Unauthorized H.225 ReleaseComplete (reason=securityDenied) 402 Payment Required H.225 ReleaseComplete (reason=undefinedReason /noPermission) 403 Forbidden H.225 ReleaseComplete (reason=noPermission /destinationRejection) 404 Not Found H.225 ReleaseComplete (reason=unreachableDestination) 405 Method Not Allowed H.225 ReleaseComplete (reason=undefinedReason) 406 Not Acceptable H.225 ReleaseComplete (reason=undefinedReason) 407 Proxy Auth. Required H.225 Release Complete (reason=securityDenied) 408 Request Timeout H.225 ReleaseComplete (reason=adaptiveBusy) 409 Conflict H.225 ReleaseComplete (reason=undefinedReason) 410 Gone H.225 ReleaseComplete (reason=unreachableDestination) 411 Length Required H.225 ReleaseComplete (reason= undefinedReason) 413 Request Entity Too Large H.225 ReleaseComplete (reason=badFormatAddress) 414 Request-URI Too Large H.225 ReleaseComplete (reason=badFormatAddress) Agrawal, et al. [Page 13] Internet Draft SIP-H.323 Interworking July 2001 415 Unsupported Media Type H.225 ReleaseComplete (reason=undefinedReason) 420 Bad Extension H.225 ReleaseComplete (reason=badFormatAddress) 480 Temporarily not available H.225 ReleaseComplete (reason=adaptiveBusy) 481 Call Leg/Transaction H.225 ReleaseComplete Does Not Exist (reason=undefinedReason) 482 Loop Detected H.225 ReleaseComplete (reason=undefinedReason) 483 Too Many Hops H.225 ReleaseComplete (reason=undefinedReason) 484 Address incomplete H.225 ReleaseComplete (reason=badFormatAddress) 485 Ambiguous H.225 ReleaseComplete (reason= undefinedReason) 486 Busy Here H.225 ReleaseComplete (reason=inConf) 487 Request Terminated H.225 ReleaseComplete (reason=undefinedReason) 488 Not Acceptable Here H.225 ReleaseComplete (reason=undefinedReason) 500 Server Internal Error H.225 ReleaseComplete (reason=undefinedReason) 501 Not Implemented H.225 ReleaseComplete (reason=undefinedReason) 502 Bad Gateway H.225 ReleaseComplete (reason=gatewayResources) 503 Service Unavailable H.225 ReleaseComplete (reason=gatewayResources) 504 Server Time-out H.225 ReleaseComplete (reason=adaptiveBusy) 505 Version Not Supported H.225 ReleaseComplete (reason=invalidRevision) 600 Busy Everywhere H.225 ReleaseComplete (reason=adaptiveBusy) 603 Decline H.225 ReleaseComplete (reason=destinationRejection) 604 Does not exist anywhere H.225 ReleaseComplete (reason=unreachableDestination) 606 Not Acceptable H.225 ReleaseComplete (reason=undefinedReason) INFO H.245 UserInputIndication BYE H.245 EndSessionCommand (H.225 ReleaseComplete message needs to be sent to close the Call Signaling Channel, if it is open) H.323 Message SIP Message ------------- ----------- H.245 sendTerminalCapabilitySet OPTIONS H.245 EndSessionCommand BYE H.225 Release Complete CANCEL or BYE(if call is connected) RAS DRQ CANCEL or BYE(if call is connected) Agrawal, et al. [Page 13] Internet Draft SIP-H.323 Interworking July 2001 Table 1: One to one mapping of SIP-H.323 messages In most of the cases, the error messages from SIP side like 4xx, 5xx and 6xx will be mapped to H.225 Release Complete message. The ReleaseCompleteReason will describe the type of error on the SIP side. Some of the error messages on one side may not always map to a corresponding error message on the other side. The mapping of Release Complete Reason in H.225 ReleaseComplete message with SIP Response messages is: ReleaseCompleteReason SIP Message --------------------- ---------------------------- noBandwidth 480 Temporarily not available gatekeeperResources 480 Temporarily not available unreachableDestination 404 Not Found destinationRejection 603 Decline invalidRevision 505 Version Not Supported noPermission 401 Unauthorized unreachableGatekeeper 503 Service Unavailable gatewayResources 480 Temporarily not available badFormatAddress 400 Bad Request adaptiveBusy 486 Busy Here inConf 486 Busy Here undefinedReason 500 Server Internal Error facilityCallDeflection 486 Busy Here securityDenied 401 Unauthorized calledPartyNotRegistered 404 Not Found callerNotRegistered 401 Unauthorized If IWF has been registered with GK, the mapping of H.225 Admission Reject, Location Reject and Disengage Reject Messages with SIP Response messages is: AdmissionRejectReason SIP Message --------------------- ---------------------------- CalledPartyNotRegistered 404 Not Found InvalidPermission 401 Unauthorized RequestDenied 503 Service Unavailable UndefinedReason 500 Server Internal Error CallerNotRegistered 401 Unauthorized routeCallToGatekeeper(*) 305 Use Proxy invalidEndpointIdentifier 500 Server Internal Error resourceUnavailable 503 Service Unavailable securityDenial 401 Unauthorized qosControlNotSupported 501 Not Implemented incompleteAddress 484 Address incomplete routeCallToSCN (*) 302 Moved Temporarily aliasesInconsistent 485 Ambiguous LocationRejectReason SIP Message --------------------- ---------------------------- NotRegistered 401 Unauthorized InvalidPermission 401 Unauthorized RequestDenied 503 Service Unavailable UndefinedReason 500 Server Internal Error Agrawal, et al. [Page 14] Internet Draft SIP-H.323 Interworking July 2001 SecurityDenial 401 Unauthorized routeCallToSCN(*) 302 Moved Temporarily aliasesInconsistent 485 Ambiguous DisengageRejectReason SIP Message --------------------- ---------------------------- NotRegistered 401 Unauthorized RequestToDropOther 401 Unauthorized SecurityDenial 401 Unauthorized Mapping of 200 OK: ---------------------- In Response of INVITE H.225 Connect In Response of BYE - In Response of OPTIONS -/Terminal Capability Set ACK message on SIP side may be sent as a result of OLC ACK or it may be simply sent in response of 200 OK response of an INVITE response. However, this mapping depends on the particular pattern of the call flow. OPTIONS message on SIP side if requested with Accept header of 'application/sdp' should be mapped to 'H.245 Send Terminal Capability Set' message. The response from H.323 network in form TCS messages should be acknowledged with TCS Ack messages and the TCS messages should be mapped to a 200 OK message to SIP networks. The reverse is true when receiving H.245 Send Terminal Capability Set message from H.323 side. H.225 Facility message may be used for carrying the H.245 tunnelled messages. As call Forwarding and Call Queued is not supported in the present phase of IWF specifications, following handling should be done on receipt of these messages. 181 Call is Being Forwarded 501 Not Implemented H.225 Release Complete (reason=undefinedReason) 182 Queued 501 Not Implemented H.225 Release Complete (reason=undefinedReason) 8.3. Call Sequence Mapping Some of the messages from either SIP side or H.323 side invokes a fixed call sequence (series of messages) i.e. exchange of more than one messages on other side. These call sequences are given below: SIP Message H.323 Message Sequence ----------- ---------------------- BYE H.245 End Session Command H.225 Release Complete RAS DRQ Agrawal, et al. [Page 16] Internet Draft SIP-H.323 Interworking July 2001 For a outgoing call, if 200 OK has not been received, the H.245 End Session Command or H.225 Release Complete will be mapped to Cancel. SIP Message H.323 Message Sequence ----------- ---------------------- CANCEL H.245 End Session Command(if open) H.225 Release Complete RAS DRQ H.323 Message SIP Message Sequence ------------- -------------------- DRQ 4XX BYE or CANCEL 8.4. Message Parameters Mapping This section contains the mapping of every possible parameter of all mandatory messages of H.323 and SIP. Details will be added in the next release of the draft. 8.5. Audio/Video Formats Mapping A subset of IANA-registered formats and corresponding H.323-supported capabilities are listed in Table 2. Payload IANA H.323 Codec Audio/video clock rate channels Type Encoding Name (A/V) (Hz) (audio) ____________________________________________________________________ 0 PCMU g711Ulaw64k A 8000 1 ? ? g711Ulaw56k A 8000 1 2 G726-32 ? A 8000 1 3 GSM gsmFullRate A 8000 1 Dynamic GSM-HR gsmHalfRate A 8000 1 Dynamic GSM-EFR gsmEnhFullRate A 8000 1 4 G723 g7321 A 8000 1 8 PCMA g711Alaw64k A 8000 1 ? ? g711Alaw56k A 8000 1 9 G722 g722-64k A 8000 1 ? ? g722-56k A 8000 1 ? ? g722-48k A 8000 1 15 G728 g728 A 8000 1 18 G729 g729 A 8000 1 dyn ? g729AnnexA A 8000 1 ? g729wAnnexB A ? g729AwB A ? g729AnnexC A ? g729Extensions A 31 H261 h261VideoCap V 90000 34 H263 h263VideoCap V 90000 dyn H263-1998 ? V 90000 Table 2: IANA-ITU Codec mapping Agrawal, et al. [Page 17] Internet Draft SIP-H.323 Interworking July 2001 Note: 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 MAY be used for defining the maximum packet length. A fmtp SDP attribute for silence suppression SHOULD be defined if silence suppression is on. Another possible fmtp attribute MAY be the list of annexes which are supported. This MAY be useful in translating g729AnnexB, g729AnnexAwAnnexB, g7231AnnexC and so on to SDP. The Video MPI (Mean Picture Interval) SHOULD 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. 9. Basic Message Handling 9.1. Handling of H.323 Signaling Messages a) Calls from H.323 network directed towards IWF MAY contain the signaling address of IWF in the destination address and the SIP address in remote extension address of Setup message. In these cases, remote extension address will be used to route the call else destination alias address will be resolved to the corresponding IP address or SIP Server address. b) Call from H.323 network directed towards IWF MAY contain the destination address, terminal capabilities and channel information in different messages. This information SHALL be combined and mapped to create the SDP information of INVITE or ACK. 9.1.1 RAS Messages IWF is an H.323 Gateway in functionality. It can receive or send any message which can be received or sent by an H.323 Gateway [5]. a)IWF sends RAS Messages GRQ - This message is used in H.323 network to discover the H.323 GK [5]. RRQ - This message is used in H.323 network to register with H.323 GK. Agrawal, et al. [Page 18] Internet Draft SIP-H.323 Interworking July 2001 URQ - This message is used in H.323 network to unregister with H.323 GK. UCF - This message is used in H.323 network in response of Unregister request from H.323 GK [5]. URJ - This message is used in H.323 network in response of Unregister request from H.323 GK [5]. ARQ - This message is used in H.323 network, when IWF receives an INVITE message from SIP network. BRQ - This message is used in H.323 network [5]. BCF This message is used in H.323 network [5]. BRJ This message is used in H.323 network [5]. IRR This message is used in H.323 network [5]. DRQ This message is used in H.323 network, when IWF receives a BYE/CANCEL or other SIP error response. DCF This message is used in H.323 network [5]. DRJ This message is used in H.323 network [5]. LRQ This message is used in H.323 network [5], when IWF receives an INVITE message and IWF is not registered with H.323 GK NSM This message is used in H.323 network [5]. XRS This message is used in H.323 network [5]. RIP This message is used in H.323 network [5]. RAI This message is used in H.323 network [5]. b) IWF receives RAS Messages GCF This message is used in H.323 network [5]. GRJ This message is used in H.323 network [5]. RCF This message is used in H.323 network as a response for register with H.323 GK. RRJ This message is used in H.323 network as a response for register with H.323 GK. UCF This message is used in H.323 network as a response for unregister with H.323 GK. Agrawal, et al. [Page 19] Internet Draft SIP-H.323 Interworking July 2001 URJ This message is used in H.323 network as a response for unregister with H.323 GK. ACF This message is used in H.323 network as a response for admission request with H.323 GK. ARJ This message is used in H.323 network as a response for admission request with H.323 GK. BRQ This message is used in H.323 network [5]. BCF This message is used in H.323 network [5]. BRJ This message is used in H.323 network [5]. IRQ This message is used in H.323 network [5]. IACK This message is used in H.323 network [5]. INAK This message is used in H.323 network [5]. DRQ If the call is active, close it. Send RAS DCF (disengage confirm) and Release Complete to H.323 entity. The corresponding BYE, CANCEL, 4xx, 5xx or 6xx message may also be sent to the SIP side of the network. DCF This message is used in H.323 network [5]. DRJ This message is used in H.323 network [5]. LCF -Send SETUP to the H.323 network for establishing the call. LRJ - Send a SIP error response corresponding to LocationRejectReason. NSM This message is used in H.323 network [5]. XRS This message is used in H.323 network [5]. RIP This message is used in H.323 network [5]. RAC This message is used in H.323 network [5]. 9.1.2 Q.931 Messages 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 SHALL send a Q.931 CallProceeding message immediately on receiving a Call Setup message Agrawal, et al. [Page 20] Internet Draft SIP-H.323 Interworking July 2001 from H.323 entity. The IWF then sends an INVITE, where the SIP To header field is derived from the Q.931 destinationAliasAddress and/or destCallSignalAddress. If destinationAddress is the IWF itself, then use remoteExtensionAddress. The From SIP header field is derived from sourceAliasAddress 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 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. It then completes the opening of channels in both the directions. Call Proceeding This message is used in H.323 network [5]. 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. Alerting If the IWF receives a 180 Alerting SIP response, send a Q.931 Alerting message to the H.323 entity. An Alerting message can be sent on the receipt of 183 Progress SIP response. On receipt of an Alerting message from H.323 entity, a 180 Alerting should be sent to SIP entity. Connect It sends a Q.931 Connect message to H.323 entity on the receipt of 200 OK response of a INVITE messge from SIP entity and vice versa. Release Complete If no response is received or a failure response, the IWF sends a Q.931 ReleaseComplete message to the H.323 entity. 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 SIP error response should be generated for corresponding ReleaseCompleteReason in other cases. Facility It is used in H.323 network for carrying various service specific informations[5]. 9.1.3 H.245 Messagers (a) Master-slave determination messages After opening the H.245 Channel, IWF completes the Master-slave determination with the H.323 entity. This is for internal use of IWF only. Agrawal, et al. [Page 21] Internet Draft SIP-H.323 Interworking July 2001 (b) Terminal Capability Messages In order to establish the logical channels for a call in Non-Fast Connect mode, IWF sends the Terminal Capability message to H.323 entity with the media capabilities of the SIP entity. The SIP messages contains the media capability in the SDP format. If it receives a Terminal Capability Set (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 Open Logical Channel (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. When an IWF receives a TCS message , it will be mapped to the "m=" line of SDP with each line containing only one payload type. (c) Logical Channel signaling messages 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 there is a change in SDP description for a Logical Channel, IWF issues a Close Logical channel, Request Channel Close, messages. IWF also supports their responses. (d) 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. (e) EndSession Command If the IWF receives a H.245 EndSession, it closes the H.245 call. Send H.245 EndSession and Q.931 ReleaseComplete to H.323 entity and send RAS DRQ to gatekeeper if it admitted the call. If the IWF receives a BYE or SIP error response for a call with H.245 session, it sends an H.245 EndSession commands to H.323 entity. (f) When an IWF receives a UserInputIndication message, it MAY be sending the DTMF to SIP using SIP INFO method. Only the alphanumeric method of userinputIndication is considered for this release of the draft. Other mapping between the INFO msg body and the signal type of userinput is left for further study. Agrawal, et al. [Page 22] Internet Draft SIP-H.323 Interworking July 2001 IWF MAY use a proprietary non-INFO method based solution that interworks with H.245 UserInputIndication. IWF May Use a proprietary INFO method based solution that interworks with H.245 UserInputIndication. IWF May Use a proprietary/standard non-INFO method based solution that could backhaul in-band DTMF signaling to the IWF and which would interwork with H.245 UserInputIndication (g) Send Terminal Capability Set IWF issues this command corresponding to SIP OPTIONS messages to determine the capability of H.323 entity. On receipt of Send Capability Set command from H.323 entity, IWF sends an OPTION command to SIP entity for determining its media capability. 9.2. Handling of SIP Signaling Messages (a) Receiving INVITE for a New Call The IWF SHALL respond with a 100 (Trying) response to the SIP entity immediately after receiving the INVITE request. It stores the SDP information as the terminal's SIP capability and convert the SIP UA capabilities to create the H.245 TCS. 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 sourceInfo is derived from the From SIP header field and sourceCallSignalAddress 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 below. If an ARJ message is received, the behavior depends on the reason parameter as follows: 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 (Bad Request) response to SIP entity for H.323 translation failure. Agrawal, et al. [Page 23] Internet Draft SIP-H.323 Interworking July 2001 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. The 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 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. Agrawal, et al. [Page 24] Internet Draft SIP-H.323 Interworking July 2001 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 (Bad Request) for the request 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. (b) Sending INVITE for a new call On receipt of SETUP message from H.323 side, IWF sends an INVITE message to SIP entity. (c) INVITE for an 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. (d) 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. Agrawal, et al. [Page 25] Internet Draft SIP-H.323 Interworking July 2001 (e) OPTIONS Request TBD: how do we query H.323 capabilities without establishing the Call because there is no standard mechanism in H.323? 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. 10. Interworking Call Scenarios for Different Configurations In cases where SIP Server or H.323 GK coexists with IWF, they will still be treated as separate logical entities. This is because seperate instances of H.323 stack will be running for H.323 GK and IWF. Similarly, there will be seperate instances of SIP stack running at both IWF and SIP server. All call flow diagrams will therefore shows IWF as a seperate logical entity and SHALL always include call messaging between IWF and H.323 GK/SIP Server (if they exists). 10.1. Registration and Address Resolution Services 10.1.1. Registration In H.323, registration is the process by which an endpoint joins a Zone,and informs the Gatekeeper of its Transport Address and alias addresses.As a part of their configuration process, all endpoints shall register with the Gatekeeper identified through the discovery process. Registration shall occur before any calls are attempted and may occur periodically as necessary (for example, at endpoint power-up or before registration timeout). An endpoint shall send a Registration Request (RRQ) message to a Gatekeeper. This is sent to the Gatekeeper's RAS Channel Transport Address. The endpoint has the Network Address of the Gatekeeper from the Gatekeeper discovery process and uses the well-known RAS Channel TSAP Identifier. The Gatekeeper shall respond with either a Registration Confirmation (RCF) or a Registration Reject (RRJ) message. In SIP, the REGISTER request allows a client to let a proxy or redirect server know at which address(es) it can be reached. A client MAY also use it to install call handling features at the server. A client uses the REGISTER method to register the address listed in the To header field with a SIP server. The Register request MAY contain a Contact header field; future non- REGISTER requests for the URI given in the To header field SHOULD be directed to the address(es) given in the Contact header. A user agent MAY register with a local server on startup by sending a REGISTER request to the well-known "all SIP servers" multicast address Agrawal, et al. [Page 26] Internet Draft SIP-H.323 Interworking July 2001 "sip.mcast.net" (224.0.1.75). This request SHOULD be scoped to ensure it is not forwarded beyond the boundaries of the administrative system. The unicast method can also be used for registration if address of the registration is known. The SIP server registers the user in its contact database and returns a response 200 OK to the user's SIP client. The response includes the user's current contact list in Contact headers. During initialization, the IWF MAY 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. 10.1.2. Address Resolution In H.323, an endpoint or Gatekeeper which has an alias address for an endpoint and would like to determine its contact information may issue a Location Request (LRQ) message. This message may be sent to a specific Gatekeeper's RAS Channel TSAP Identifier, or may be multicast to the Gatekeeper's well-known Discovery Multicast Address. The Gatekeeper with which the requested endpoint is registered, shall respond with the Location Confirmation (LCF) message containing the contact information of the endpoint or the endpoint's Gatekeeper. Contact information shall include the Call Signalling Channel and RAS Channel addresses to be used to reach the endpoint and optionally additional destination information which can provide dialling information and extension information concerning the requested endpoint. All Gatekeepers with which the requested endpoint is not registered, shall return Location Reject (LRJ) if they received the LRQ on the RAS Channel. Any Gatekeeper with which the requested endpoint is not registered, shall not respond to the LRQ, if it received the LRQ on the Discovery Multicast address. In SIP, the REGISTRATION method is used to register the address(es) of the user in the SIP server (register, redirect, proxy) and the SIP server registers the address(es) in its contact database. A SIP register/redirect/proxy server returns the list to the client as Contact headers. A SIP register/redirect/proxy server can return the address(es) where the user can be contacted. The OPTION method of SIP can also be used to resolve the addresses. For example, the SIP server may be queried for knowing its capabilities using the OPTION method. If the server that believes it can contact the user, such as a user agent where the user is logged in and has been recently active, MAY respond to this request with a capability set along with the address(es) where the user can be contacted. Agrawal, et al. [Page 27] Internet Draft SIP-H.323 Interworking July 2001 10.1.3. Registration and Address Resolution Scenarios An RRQ contains an endpointType, which will, in the IWF case, contain a GatewayInfo SEQUENCE that contains the SupportedProtocols. In H.323v2, each of these SupportedProtocols contains a SEQUENCE OF dial prefixes. This is where the number ranges are specified by way of prefixes. Also, most GKs support some form of static configuration to do the same job by less elegant means if either IWF or GK is version 1 or doesn't support this feature for other reasons. This method of dial prefixes and number range will help in address resolution in cases when the SIP and H.323 domain are well defined with a dialing plan. * Registration of the IWF as SIP User Agent TRIP may be used, but left for further study. 10.1.4. Advertisement of SIP Support by H.323 Gateways As the Session Initiation Protocol (SIP) gains wider acceptance, it is important to build gateways that provide an interworking function between the two protocols. It is our recommendation that we add SIP to the list of supported protocols advertised by an H.323 gateway to its gatekeeper. The semantics of existing desired/supported protocol information elements were not appropriate for an H.323 gateway to indicate SIP support to an H.323 gatekeeper. Currently, the best practice for a H.323 gateway (supporting SIP) implementation is to use the h323 information element in the SupportedProtocols choice for this purpose. The use of such a field means that this H.323 gateway (supporting SIP) is a pure H.323 proxy, which is not semantically correct. Appendix B gives the modified ASN.1 to show the additions to the H.225 for the support of SIP protocol. 10.2. Call Flows for Basic Configuration H.323 EP ---- IWF ---- SIP EP a) Simple Call from H.323 terminal to SIP terminal. H.323 EP IWF SIP EP User A User B (164.164.28.101) (164.164.28.121) (164.164.28.141) RTP = 2326 RTP = 4346 RTCP = 2327 RTCP = 4347 |Setup(vipin@iwf.sip.com) F1| | |-------------------------->| INVITE F2 | | Call Proc F3 |-------------------------->| |<--------------------------| c=IN IP4 164.164.28.121 | | | m=audio 0 RTP/AVP 0 | | | a=rtpmap:0 PCMU/8000 | Agrawal, et al. [Page 28] Internet Draft SIP-H.323 Interworking July 2001 | | | | | 100 Trying F4 | | |<--------------------------| | | 180 Ringing F5 | | Alerting F6 |<--------------------------| |<--------------------------| 200 OK F7 | | Connect F8 |<--------------------------| |<--------------------------| c=IN IP4 164.164.28.141 | | | m=audio 4346 RTP/AVP 0 | | | a=rtpmap:0 PCMU/8000 | | TCS F10 | ACK F9 | |-------------------------->|-------------------------->| | TCS Ack F11 | | |<--------------------------| | | TCS F12 | | |<--------------------------| | | TCS Ack F13 | | |-------------------------->| | | MSD F14 | | |-------------------------->| | | MSD F14A | | |<--------------------------| | | MSD Ack F15 | | |<--------------------------| | | MSD Ack F16 | | |-------------------------->| | |OLC(RTCP=2327,g711Ulaw) F17| | |-------------------------->| | | OLC Ack(RTP=4326, F18 | | |<--------------------------| | | 164.164.28.141) | | | | | |OLC(RTCP=4347,g711Ulaw) F19| | |<--------------------------| | | | | | OLC Ack(RTP=2326, F20 | | |-------------------------->| INVITE F21 | | 164.164.28.101 |-------------------------->| | | c=IN IP4 164.164.28.101 | | | m=audio 2326 RTP/AVP 0 | | | a=rtpmap:0 PCMU/8000 | | | | | | 200 OK F22 | | |<--------------------------| | | c=IN IP4 164.164.28.141 | | | m=audio 4346 RTP/AVP 0 | | | a=rtpmap:0 PCMU/8000 | | | | | | ACK F23 | | |-------------------------->| Agrawal, et al. [Page 29] Internet Draft SIP-H.323 Interworking July 2001 | RTCP | 2327 |<=====================================================>| 4347 | RTP | 2326 |<=====================================================>| 4346 This call flow shows the use of a re-INVITE (F20) by the IWF to update the SIP end point SDP. The initial INVITE (F2) contains "dummy" SDP of the IWF, since the SDP of the H.323 EP is not yet known. The details of call flow messages are given in Appendix C.1. b) Call from H.323 terminal to SIP terminal using H.245 tunneling. H.323 SIP EP IWF EP User A UserB | Setup(tunn= true,MSD,TCS) F1 | |------------------------->| INVITE F2 | | |-------------------------->| | | 180 Ringing F3 | | Alerting F4 |<--------------------------| |<-------------------------| | | | 200 OK F5 | | Connect(MSD Ack,TCS F6 |<--------------------------| |<-------------------------| | | TCS Ack) | | | | | | Facility(TCS Ack,OLC F7 | | |------------------------->| | | MSD Ack) | | | | | | Facility(OLC Ack,OLC) F8 | | |<-------------------------| | | Facility(OLC Ack) F9 | | |------------------------->| | | | | | | | | | ACK F10 | | |-------------------------->| | RTP | |<====================================================>| This call flow shows the delayed SDP approach, where the initial INVITE (F2) does not contain SDP, but the ACK (F10) does. In this call flow, it is possible that the SIP end point will time out and retransmit the 200 OK (F5) response, thinking that it had been lost. For simplicity, it is not shown here. The details of call flow messages are given in Appendix C.2. Agrawal, et al. [Page 30] Internet Draft SIP-H.323 Interworking July 2001 c) Call from H.323 terminal to SIP terminal using early H.245. H.323 SIP EP IWF EP | Setup(H245 Address) | | |------------------------->| INVITE | | |-------------------------->| | H245 Start here | | |<------------------------>| 180 Ringing | | Alerting |<--------------------------| |<-------------------------| 200 OK | | Connect |<--------------------------| |<-------------------------| | | H245 Ends upto this | | |<------------------------>| ACK | | |-------------------------->| | RTP | |<====================================================>| This call flow and message exchanges are very much similar to Section (10.2 a) except that IWF in this case gets the H.245 address of H.323 EP in Setup message. Using this H.245 address and TSAP identifier, IWF opens an H.245 channel with H.323 EP prior to completing Q.931. In this case, all the normal H.245 messages will be exchanged on the seperate H.245 channel but it will be done simultaneously along with Q.931. The ACK on SIP side will be sent only after completing the H.245 message exchange on the H.323 side. d) Call from H.323 terminal to SIP terminal using fast connect procedure. H.323 SIP EP IWF EP | Setup(fastStart=true,OLC)| | |------------------------->| INVITE F2 | | F1 |-------------------------->| | | 180 Ringing F3 | | Alerting F4 |<--------------------------| |<-------------------------| 200 OK F5 | | Connect(fastStart=true, |<--------------------------| |<-------------------------| | | OLC) F6 | ACK F7 | | |-------------------------->| | RTP | |<====================================================>| This call flow has the most perfect matching of H.323 message and parameters with SIP message and parameters. Setup from H.323 endpoint will contain the media channel information for forward and reverse channels. This will help in mapping the complete channel information to SDP of SIP INVITE. Similarly, SDP of 200 OK response Agrawal, et al. [Page 31] Internet Draft SIP-H.323 Interworking July 2001 from SIP side can be easily mapped to open the channels on H.323 side. This call flow will give the immediate availability of media channels from both sides after H.323 Connect and SIP Ack. The details of call flow messages are given in Appendix C.3. e) Call from H.323 terminal to SIP terminal using overlapped sending. H.323 SIP EP IWF EP User A User B | Setup(canOverlapSend= F1 | | |------------------------->| | | true, Incomplete Add.) | | | | | | Setup Ack F2 | | |<-------------------------| INVITE F3 | | |-------------------------->| | | 484 Address Inc. F4 | | |<--------------------------| | | ACK F5 | |Information(additional F6 |-------------------------->| |------------------------->| | | address) | INVITE F7 | | |-------------------------->| | | 180 Ringing F8 | | Alerting F9 |<--------------------------| |<-------------------------| 200 OK F10 | | Connect F11 |<--------------------------| |<-------------------------| | | H245 F12 | | |<------------------------>| ACK F13 | | |-------------------------->| | RTP | |<====================================================>| This call flow shows overlapped dialing. On the SIP side, the Call-ID remains the same throughout the flow. The SETUP message contains either: a) no called number information; or b) incomplete called number information; or c) called number information which the network cannot determine to be complete. On receipt of such a SETUP message, the network starts timer T302 (as specified in Q.931), sends a SETUP ACKNOWLEDGE message to the user, and enters the overlap sending state. In case a), the network will return dial tone, if required by the tone option. In this case further address information will be available in the SETUP ACKNOWLEDGE message. Agrawal, et al. [Page 32] Internet Draft SIP-H.323 Interworking July 2001 When the SETUP ACKNOWLEDGE message is received, the user enters the overlap sending state and optionally starts timer T304 (the value of timer T304 is specified in Q.931 [12]). After receiving the SETUP ACKNOWLEDGE message, the user sends the remainder of the call information (if any) in one or more INFORMATION messages. The called party number information may be provided by the user as follows: a) in the called party number information element; or b) in the keypad facility information element, exclusively. The called party number must be sent in a unique way. The details of call flow messages are given in Appendix C.4. g) Call from SIP terminal to H.323 terminal using H.245 tunneling. User B User A SIP H.323 EP IWF EP | INVITE F1 | | |------------------------->| Setup(tunn. =true,TCS,MSD)| | |-------------------------->| | | F2 | | | | | | Alerting(tunn.=true,TCSAck| | |<--------------------------| | 180 Ringing F4 | MSD Ack,TCS) F3 | |<-------------------------| | | |Facility(mess-body=empty, | | |-------------------------->| | |TCS Ack,OLC,MSD Ack) F5 | | | | | |Facility(OLC Ack,OLC) F6 | | |<--------------------------| | |Facility (OLC Ack) F7 | | |-------------------------->| | | Connect F8 | | 200 OK F9 |<--------------------------| |<-------------------------| | | ACK F10 | | |------------------------->| | | RTP | |<====================================================>| The details of call flow messages are given in Appendix C.5. Agrawal, et al. [Page 33] Internet Draft SIP-H.323 Interworking July 2001 h) Call from SIP terminal to H.323 terminal using early H.245. SIP H.323 EP IWF EP | INVITE | | |------------------------->| Setup(h245 Address) | | |-------------------------->| | | Early H245 starts here | | |<------------------------->| | | Alerting | | 180 Ringing |<--------------------------| |<-------------------------| Connect | | |<--------------------------| | | Early H245 ends upto this | | 200 OK |<------------------------->| |<-------------------------| | | ACK | | |------------------------->| | | RTP | |<====================================================>| The call flow diagram for this call is similar to call flow f) except that in this case the H.245 channel was opened immediately after an H.323 endpoint received the H.225 Setup message. i) Call from SIP terminal to H.323 terminal using fast connect procedure. SIP H.323 EP IWF EP | INVITE | | |------------------------->| Setup(fastStart=true,OLC) | | |-------------------------->| | | Alerting | | 180 Ringing |<--------------------------| |<-------------------------|Connect(fastStart=true,OLC)| | 200 OK |<--------------------------| |<-------------------------| | | ACK | | |------------------------->| | | RTP | |<====================================================>| This call flow gives a perfect matching of call sequence and parameters. Agrawal, et al. [Page 34] Internet Draft SIP-H.323 Interworking July 2001 j) Call from SIP terminal to H.323 terminal using overlapped sending. SIP H.323 EP IWF EP User B User A | INVITE F1 | | |------------------------->| Setup(canOverlapSend=true) F2 | |-------------------------->| | 484 Address Incomplete F3| | |<-------------------------| | | ACK F4 | | |------------------------->| Setup Ack. F5 | | |<--------------------------| | | | | INVITE F6 | | |------------------------->| Information(Additional F7 | | |-------------------------->| | | Address) | | | | | | Alerting F8 | | 180 Ringing F9 |<--------------------------| |<-------------------------| Connect F10 | | |<--------------------------| | | H245 F11 | | 200 OK F12 |<------------------------->| |<-------------------------| | | ACK F13 | | |------------------------->| | | RTP | |<====================================================>| This call flow shows overlapped dialing. On the SIP side, the Call-ID remains the same throughout the flow. The details of call flow messages are given in Appendix C.6. 10.3 Calls using both H.323 GK and SIP Server H.323 EP ---- H.323 GK ---- IWF ---- SIP Server ---- SIP EP Assumption: GK routes the call up to Q.931 signaling only. This section only gives the details of call sequence. Message details are similar and can be derived from the details of Section 10.2. a) Simple Call from H.323 terminal to SIP terminal. Agrawal, et al. [Page 35] Internet Draft SIP-H.323 Interworking July 2001 (i) With SIP Proxy H.323 H.323 SIP SIP EP GK IWF Proxy EP | ARQ | | | | |------------>| | | | | ACF | | | | |<------------| | | | | Setup | | | | |------------>| Setup | | | | |------------>| | | | | ARQ | | | | |<------------| | | | | ACF | | | | |------------>| INVITE | | | | |------------>| INVITE | | | | |------------>| | | | | 180 Ringing | | | | 180 Ringing |<------------| | | Alerting |<------------| | | Alerting |<------------| | | |<------------| | | 200 OK | | | | 200 OK |<------------| | | Connect |<------------| | | Connect |<------------| | | |<------------| | | | | H.245 | | | |<------------------------->| ACK | | | | |------------>| ACK | | | | |------------>| | | | | | | | RTP | | |<=====================================================>| (ii) With SIP Redirect H.323 H.323 SIP SIP EP GK IWF Redirect EP | ARQ | | | | |------------>| | | | | ACF | | | | |<------------| | | | | Setup | | | | |------------>| Setup | | | | |----------->| | | | | ARQ | | | | |<-----------| | | | | ACF | | | | |----------->| INVITE | | | | |----------->| | | | | 302 Moved | | | | |<-----------| | Agrawal, et al. [Page 36] Internet Draft SIP-H.323 Interworking July 2001 | | | ACK | | | | |----------->| | | | | INVITE | | | |-------------------------->| | | | 180 Ringing | | | Alerting |<--------------------------| | Alerting |<-----------| | |<------------| | 200 OK | | | Connect |<--------------------------| | Connect |<-----------| | |<------------| | | | H.245 | | |<------------------------>| ACK | | |-------------------------->| | RTP | |<====================================================>| This call flow shows the message sequence in case of H.323 GK and SIP Server. Details of messages are similar to other call flows explained above. b) Call from H.323 terminal to SIP terminal using H.245 tunneling. H.323 H.323 SIP SIP EP GK IWF Proxy EP | ARQ | | | | |------------>| | | | | ACF | | | | |<------------| | | | |Setup(tunn= | | | | |------------>| ARQ | | | |true,TCS,MSD)|----------->| | | | | ACF | | | | |<-----------| | | | |Setup(tunn= | | | | |----------->| INVITE | | | |true,TCS,MSD|----------->| INVITE | | | | |------------->| | | | | 180 Ringing | | | |180 Ringing |<-------------| | |Alerting(MSD|<-----------| | |Alerting(MSD |<-----------| | | |<------------|Ack,TCS Ack,| | 200 OK | |Ack,TCS Ack, |TCS) | 200 OK |<-------------| |TCS) | |<-----------| | | | | | | |Facility(OLC)| | | | |------------>|Facility(OLC| | | | |----------->| | | | | | | | Agrawal, et al. [Page 37] Internet Draft SIP-H.323 Interworking July 2001 | |Facility(OLC| | | |Facility(OLC |<-----------| | | |<------------|Ack,OLC) | | | |Ack,OLC) | | | | | | | | | |Facility(OLC | | | | |------------>|Facility(OLC| | | | Ack) |----------->| | | | | Ack) | | | | | | | | | | Connect | | | | Connect |<-----------| | | |<------------| | | | | H245 | | | |<------------------------>| ACK | | | | |----------->| ACK | | | | |------------->| | RTP | | |<====================================================>| In this call scenario, it takes too much time between "200 OK" and "ACK". The other approach can be to send the ACK immediately and then resend a "INVITE" after completing H.245 message exchange. c) Call from H.323 terminal to SIP terminal using early H.245. H.323 H.323 SIP SIP EP GK IWF Proxy EP | ARQ | | | | |------------>| | | | | ACF | | | | |<------------| | | | |Setup(H245 | | | | |------------>| ARQ | | | | Address) |------------>| | | | | ACF | | | | |<------------| | | | | Setup(H245 | | | | |------------>| INVITE | | | | Address) |------------>| INVITE | | H245 Starts here | |------------>| |<------------------------->| | 180 Ringing | | | 180 Ringing |<------------| | | Alerting |<------------| 200 OK | | Alerting |<------------| 200 OK |<------------| |<------------| Connect |<------------| | | Connect |<------------| | | |<------------| | | | | H245 Ends upto this | | | |<------------------------->| ACK | | | | |------------>| ACK | | | | |------------>| | | RTP | | |<====================================================>| Agrawal, et al. [Page 38] Internet Draft SIP-H.323 Interworking July 2001 d) Call from H.323 terminal to SIP terminal using fast connect procedure. H.323 H.323 SIP SIP EP GK IWF Proxy EP | ARQ | | | | |------------>| | | | | ACF | | | | |<------------| | | | |Setup(fast | | | | |------------>| ARQ | | | |Conn,OLC) |------------>| | | | | ACF | | | | |<------------| | | | |Setup(fast | | | | |------------>| INVITE | | | |Conn,OLC) |------------>| INVITE | | | | |------------>| | | | | 180 Ringing | | | | 180 Ringing |<------------| | | Alerting |<------------| 200 OK | | Alerting |<------------| 200 OK |<------------| |<------------| Connect |<------------| | | Connect |<------------| | | |<------------| | | | | H245 | | | |<------------------------->| ACK | | | | |------------>| ACK | | | | |------------>| | | RTP | | |<=====================================================>| e) Call from H.323 terminal to SIP terminal using overlapped sending. H.323 H.323 SIP SIP EP GK IWF Proxy EP |ARQ(Incomp. | | | | |------------>| | | | | Address) | | | | | | | | | |ARJ(rejectRea| | | | |<------------| | | | |son=Incomp. | | | | | Address) | | | | | | | | | |ARQ(Addition | | | | |------------>| | | | |al Address) | | | | | | | | | Agrawal, et al. [Page 39] Internet Draft SIP-H.323 Interworking July 2001 | ACF | | | | |<------------| | | | | Setup | | | | |------------>| Setup | | | | |------------>| | | | | ARQ | | | | |<------------| | | | | ACF | | | | |------------>| INVITE | | | | |------------>| INVITE | | | | |------------>| | | | | 180 Ringing | | | | 180 Ringing |<------------| | | Alerting |<------------| | | Alerting |<------------| | | |<------------| | | 200 OK | | | | 200 OK |<------------| | | Connect |<------------| | | Connect |<------------| | | |<------------| | | | | H.245 | | | |<------------------------->| ACK | | | | |------------>| ACK | | | | |------------>| | | | | | | | RTP | | |<=====================================================>| f) Simple call from SIP terminal to H.323 terminal. (i) With SIP Proxy SIP SIP H.323 H.323 EP Proxy IWF GK EP | | | | | | INVITE | | | | |------------>| INVITE | | | | |------------>| ARQ | | | | |------------>| | | | | ACF | | | | |<------------| | | | | Setup | | | | |------------>| Setup | | | | |------------>| | | | | ARQ | | | | |<------------| | | | | ACF | | | | |------------>| | | | | Alerting | | | | Alerting |<------------| | | 180 Ringing |<------------| | Agrawal, et al. [Page 40] Internet Draft SIP-H.323 Interworking July 2001 | 180 Ringing |<------------| | | |<------------| | | Connect | | | | Connect |<------------| | | |<------------| | | | | H.245 | | | 200 OK |<------------------------->| | 200 OK |<------------| | | |<------------| | | | | ACK | | | | |------------>| ACK | | | | |------------>| | | | | RTP | | |<=====================================================>| (ii) With SIP Redirect SIP SIP H.323 H.323 EP Redirect IWF GK EP | INVITE | | | | |------------>| | | | | 302 Moved | | | | |<------------| | | | | ACK | | | | |------------>| | | | | INVITE | | | |-------------------------->| ARQ | | | | |------------>| | | | | ACF | | | | |<------------| | | | | Setup | | | | |------------>| Setup | | | | |------------>| | | | | ARQ | | | | |<------------| | | | | ACF | | | | |------------>| | | | | Alerting | | | | Alerting |<------------| | |180 Ringing |<------------| | |180 Ringing |<------------| | | |<------------| | | Connect | | | | Connect |<------------| | | |<------------| | | | | H.245 | | 200 OK |<------------------------->| |<--------------------------| | | | ACK | | | |-------------------------->| | | | | RTP | | |<=====================================================>| Agrawal, et al. [Page 41] Internet Draft SIP-H.323 Interworking July 2001 g) Call from SIP terminal to H.323 terminal using H.245 tunneling. SIP SIP H.323 H.323 EP Proxy IWF GK EP | | | | | | INVITE | | | | |------------>| INVITE | | | | |------------>|Setup(tunn.= | | | | |true,MSD,TCS)| | | | |------------>| | | | | ARQ | | | | |<------------| | | | | ACF | | | | |------------>| Setup(MSD, | | | | | TCS) | | | | |------------>| | | | | ARQ | | | | |<------------| | | | | ACF | | | | |------------>| | | | |Alerting(MSD | | | | |Ack,TCS Ack, | | | | |TCS,MSD) | | | |Alerting(MSD |<------------| | | |Ack,TCS Ack, | | | | |TCS,MSD) | | | | 180 Ringing |<------------| | | 180 Ringing |<------------| | | |<------------| |Facility(TCS | | | | |Ack,MSD Ack, | | | | |OLC) | | | | |------------>|Facility(TCS | | | | |Ack,MSD Ack, | | | | |OLC) | | | | |------------>| | | | |Facility(OLC | | | | |Ack,OLC) | | | |Facility(OLC |<------------| | | |Ack,OLC) | | | | |<------------| | | | |Facility(OLC | | | | |Ack) | | | | |------------>|Facility(OLC | | | | |Ack) | | | | |------------>| | | | | Connect | | | | Connect |<------------| | | 200 OK |<------------| | | 200 OK |<------------| | | |<------------| | | | | ACK | | | | |------------>| ACK | | | | |------------>| | | | | RTP | | |<=====================================================>| Agrawal, et al. [Page 42] Internet Draft SIP-H.323 Interworking July 2001 h) Call from SIP terminal to H.323 terminal using early H.245. SIP SIP H.323 H.323 EP Proxy IWF GK EP | | | | | | INVITE | | | | |------------>| INVITE | | | | |------------>|Setup(H245 | | | | |------------>|Setup(H245 | | | |Address) |------------>| | | | | Address) | | | H245 starts here | | | |<------------------------->| | | | | Alerting | | | | Alerting |<------------| | | 180 Ringing |<------------| Connect | | 180 Ringing |<------------| Connect |<------------| |<------------| |<------------| | | | | H245 ends up to this | | | 200 OK |<------------------------->| | 200 OK |<------------| | | |<------------| | | | | ACK | | | | |------------>| ACK | | | | |------------>| | | | | RTP | | |<=====================================================>| i) Call from SIP terminal to H.323 terminal using fast connect procedure. SIP SIP H.323 H.323 EP Proxy IWF GK EP | | | | | | | | | | | INVITE | | | | |------------>| INVITE | | | | |------------>| ARQ | | | | |------------>| | | | | ACF | | | | |<------------| | | | | Setup(with | | | | | fast start | | | | | and OLC) | | | | |------------>| Setup(with | | | | | fast start | | | | | and OLC) | | | | |------------>| | | | | ARQ | | | | |<------------| Agrawal, et al. [Page 43] Internet Draft SIP-H.323 Interworking July 2001 | | | | ACF | | | | |------------>| | | | |Alerting(with| | | | |fast start) | | | |Alerting(with|<------------| | | |fast start) | | | | 180 Ringing |<------------| | | 180 Ringing |<------------| | | |<------------| | |Connect(with | | | | |fast start | | | | |and OLC) | | | |Connect(with |<------------| | | |fast start | | | | |and OLC) | | | | 200 OK |<------------| | | 200 OK |<------------| | | |<------------| | | | | ACK | | | | |------------>| ACK | | | | |------------>| | | | | RTP | | |<=====================================================>| 11. State Machine This section defines the state machine for a basic call. The state machine for complex calls will be defined in next release of this draft. (This is a draft proposal and will be refined as more analysis will be done for all call scenarios.) This section includes only those RAS messages which are defined for H.323 terminal/gateway in Section 7.7 Table 19/H.225 [12]. This section includes only those Q.931 messages which are defined for a H.323 terminal/gateway in Section 7.1/H.225 [12]. This section includes only a partial list of H.245 messages, which may be required for a basic call. This section includes only a partial list of SIP messages, which may be required for a basic call. This section use the Timers defined in SIP[3], H.225 [12] and Table 9-1/Q.931 [14]. Only messages related to a call are listed as possible messages/events. All other noncall related messages like RRQ, Register will not be handled by the call state machine and these messages will be treated as precall messages. The behavior of the IWF and handling of these messages are explained in Section 10.1 Agrawal, et al. [Page 44] Internet Draft SIP-H.323 Interworking July 2001 11.1 State machine (SIP to H.323) ----------------------------------- +-------------------------+ +---------------->+ Idle +<------------+ | +---+---------------+-----+ | | | | | | | INVITE/ARQ | | | V | | | ARJ +-----------------+ | | +<----------+ WaitForAdm | | INVITE(PreGranted | | +---------+-------+ | ARQ or GK | | | ACF/Setup | not present)/ | | V V Setup | | T303 +-------------------------+ RLC | +<----------------+ WaitForAlerting +------------>+ | +---+--------+------+-----+ | | Call Proc. | ^ | | | | | | | | | | +--+ | | | | | | Connect/ | | | | 180 Ringing | | | | | | Alerting/ | | | | 180 Ringing | | | | V V | | T301 +-------------------------+ RLC | +<----------------+ WaitForH245Complete +------------>+ | +---+--------+------------+ | | | ^ | | | Connect | | | | | +---+ | H245Complete/ | | | 200 OK | | | | | V | | BYE +-------------------------+ RLC | +<----------------+ Connected +------------>+ +-------------------------+ Figure 2: State machine for SIP to H.323 call. 11.2 SIP-H.323 State Machine Behavior For Various Events -------------------------------------------------------- State : Idle Possible Messages Message Category Action Next state ----------------- ---------------- ---------- ---------- RAC Non Triggering Sec.11.2.1 Sec.11.2.1 INVITE Triggering Sec.11.2.2 Sec.11.2.2 Agrawal, et al. [Page 45] Internet Draft SIP-H.323 Interworking July 2001 All unexpected messages in this state will cause an error indication. All other messages will be either Non Triggering or for further study. 11.2.1 RAC If this RAC is for the previous RAI (almostOutOfResources = true) then do not accept new calls. If this RAC is for a previous RAI having almostOutOfResources = false, then accept new calls. The RAI action will be taken by H.323 GK for calls coming from H.323 network. 11.2.2 INVITE 100 Trying SHALL be sent immediately after receiving INVITE. (i) If a INVITE message is received in "Idle" state, then send ARQ to H.323 GK (if it is present in the network, i.e. IWF is registered to a H.323 GK). Next State: WaitForAdm (Waiting For Admission) (ii)If IWF has a preGranted ARQ or if no H.323 GK is present in network (i.e.IWF is not registered with any H.323 GK), then send H.225 Setup message. Setup is sent when the IWF can resolve the IP Address to which the message has to be sent, e.g., when it has pregranted ARQ, or the SIP URI gives the H.323 host name. This MAY involve H.323 LRQ/LCF messages, but does not alter the state of the call. If the H.323 IP address is not known or can not be resolved then IWF sends back 404 Not Found. Next State: WaitForAlerting State : WaitForAdm (Waiting For Admission) Possible Messages Message Category Action Next state ----------------- ---------------- ---------- ---------- ACF Triggering Send Setup, WaitForAlerting ARJ Triggering Send 4xx Idle DRQ Non Triggering Send 4xx,Send DCF Idle RAC Non Triggering See 11.2.1 State : WaitForAlerting (Waiting For Alerting) Possible Messages Message Category Action Next state ----------------- ---------------- ---------- ---------- DRQ Non Triggering Send 4xx,Send DCF, Idle Send RLC. RAC Non Triggering See 11.2.1 SetupAcknowledge Non Triggering Sec.11.2.3 See 11.2.3 CallProceeding Non Triggering Alerting Triggering Send 180 Ringing WaitForH245Complete Connect Triggering Send 180 Ringing Agrawal, et al. [Page 46] Internet Draft SIP-H.323 Interworking July 2001 WaitForH245Complete ReleaseComplete Triggering Send 4xx,Send DRQ Idle T303(first exp.) Non Triggering Send Setup T303(second exp.) Triggering Send4xx,Send RLC Idle TCS See 11.2.4 See 11.2.4 TCS Ack See 11.2.4 See 11.2.4 MSD See 11.2.4 See 11.2.4 MSD Ack See 11.2.4 See 11.2.4 OLC See 11.2.4 See 11.2.4 OLC Ack See 11.2.4 See 11.2.4 UserInputInd See 11.2.4 See 11.2.4 EndSession See 11.2.4 See 11.2.4 INVITE FFS FFS CANCEL Triggering Send 4xx,Send DRQ Idle 11.2.3 If a SetupAcknowledge is received by an IWF from H.323 network after sending Setup message, then additional addressing information should be sent using INFORMATION messages. If the address is incomplete and the canOverlapSend field set to FALSE, the call should be dropped using RELEASE COMPLETE. 11.2.4 If the Setup message contains the fastStart or tunnelled H.245 messages, then all H.245 messages will be handled normally according to H.245 call handling procedures. It MAY be needed to open a H.245 channel between the IWF and the H.323 terminal/Gatekeeper. H245Complete event is initiated when the media channels between the caller and callee are open in both directions. When H.245 is complete, 200 OK SHALL be sent to SIP network. State : WaitForH245Complete (Waiting For H.245 Complete) Possible Messages Message Category Action Next state ----------------- ---------------- ---------- ---------- DRQ Non Triggering Send 4xx,Send DCF Idle Send RLC. RAC Non Triggering See 11.2.1 Connect Non Triggering No action req. ReleaseComplete Triggering Send 4xx,Send DRQ Idle T301 Triggering Send 4xx,Send RLC TCS See 11.2.4 See 11.2.4 TCS Ack See 11.2.4 See 11.2.4 MSD See 11.2.4 See 11.2.4 MSD Ack See 11.2.4 See 11.2.4 OLC See 11.2.4 See 11.2.4 OLC Ack See 11.2.4 See 11.2.4 UserInputInd See 11.2.4 See 11.2.4 EndSession See 11.2.4 See 11.2.4 Agrawal, et al. [Page 47] Internet Draft SIP-H.323 Interworking July 2001 H245 Complete Triggering See 11.2.4 CallConnected INVITE FFS FFS CANCEL Triggering Send 4xx,Send DRQ Idle State : CallConnected (Call Connected) Possible Messages Message Category Action Next state ----------------- ---------------- ---------- ---------- DRQ Non Triggering Send 4xx,Send DCF I