The deployment of interworking devices will depend on

Transcription

1 SIP and H.323 interworking VoIP networks A Stephens and P J Cordell H.323 is currently the industry s predominant standard for offering multi services over IP networks, although the session initiation protocol (SIP) continues to generate significant interest in the market-place for rendezvous-based real-time applications. With its greater maturity, H.323-based equipment continues to be deployed in operational networks. However, with the advent of SIP-based third generation mobile networks and the continued development of voice over cable TV networks based upon SIP, significant deployments of SIP-based networks are on the horizon. Interworking between SIP and H.323- based equipment is of significant importance to BT and its Joint Venture partners. This paper highlights some of the issues surrounding protocol interworking between the H.323 and SIP protocol sets. It can be shown that, while possible, interworking inevitably results in sub-optimal operation and a loss of features. Thus, as interworking is inevitably going to be required for a long time to come, and the result is less than perfect, the standards bodies should be encouraged to develop service-enabling extensions to their protocols that are compatible between both protocol suites wherever possible. 1. Introduction H.323 [1] is currently the industry s predominant standard for multi services over IP networks; but the session initiation protocol (SIP) [2], in conjunction with the session description protocol (SDP) [3], continues to generate significant interest in the market-place, especially with its designation as the preferred protocol for third generation mobile networks, and its adoption by the Packet Cable initiative [4] for packet voice communications over cable television infrastructures. The two protocols address similar requirements but use different methods of addressing, locating end-points, call establishment and negotiation. With its greater maturity, H.323-based equipment continues to be deployed in operational networks, but a number of significant SIP networks are likely to be deployed soon. However, even if SIP does become widely deployed, different service providers may choose to maintain existing network deployments in order to serve the needs of existing customers and applications. Furthermore, it may be found that some applications are better suited to H.323 while others are better implemented with SIP. Also, some service providers may not want to change over to a new protocol because it does not offer the features that their existing protocol does. For these reasons it is unlikely that one protocol will be completely dominant at a global level, and thus the mix of protocols used across administrative s is likely to require interworking solutions well into the future. Hence there has been much interest within the standards community on being able to interwork these new technologies with existing H.323 deployments. In particular, the IETF and ETSI s project TIPHON [5] have been active in this area defining interworking requirements and architectures. This paper highlights some of the issues surrounding protocol interworking and the production of devices to interwork the H.323 and SIP protocol sets. 2. Architectures for interworking The deployment of interworking devices will depend on the architecture of the network into which they are placed. An interworking solution should be chosen, where possible, that allows the existing procedures of H.323 and SIP to remain unchanged within their respective environments. In order to achieve this goal the interworking function (IWF) should participate in the procedures of H.323 and SIP as though it were a native end-point within these respective s. However, existing protocols and procedures may need to be modified, or new ones defined, to allow negotiation of protocol interworking services/capabilities between administrative s. An interworking function will typically bridge two administrative s. In this document an administrative is a logical collection of entities, including back-end 119

2 service entities, under the control of a single administration. An administrative may contain one or more s, and a single administrative body (i.e. service provider) may control multiple administrative s. Each administrative may contain back-end services () and one or more s. instances where customers continue using a given protocol because it offers features that the other protocol does not. The provide network services, including location, security and billing functions. layers may share endpoint and service information directly via inter- protocols. SIP H A consists of entities that communicate using the same call and control protocols (e.g. SIP or H.323). The s comprise the lower layers of gatekeepers (GKs) and SIP proxies as well as H.323 terminals, gateways (GWs) and SIP user agents. There may be one (or more) (s) in an administrative. Both the administrative and s can also contain sub-s arranged hierarchically. In this paper it is assumed that the top-level s are an aggregate of the sub-s they contain and can be treated as single s. The architecture affects the interaction between networks at the call/session control layers and back-end service layers. Consequently, the interworking function may have manifestations at both the call/session- layer, and the layer. Thus there are two parts of an interworking function which must be considered. The protocol interworking function () that interworks protocol sets at the call/session control layer, and the interworking function (BIWF) that interworks protocol sets at the layer. Interworking architectures fall into two broad categories. Intra- interworking In the first, interworking is required within an administrative (termed intra- interworking scenarios), an example of which is shown in Fig 1. These scenarios are less likely to occur as it is easier to maintain and support a network that utilises a single call control protocol. The main goal of interworking in these scenarios will be to ease migration from one protocol to another; migration is expected to be rapid in these scenarios. However, if migration is desired, it is more likely that an administrative body will deploy a new product offering in the form of a new administrative. Users would then be migrated to the new, eventually rendering the old obsolete. There may be Fig 1 Inter- interworking Example of intra- interworking. The second architectural category is where interworking is required between administrative s (termed inter- interworking scenarios), as shown in Fig 2. This type of architecture is likely to be more common. SIP BT network Fig 2 BT network BIWF H.323 OLOs Example of inter- interworking. Where an interworking architecture is selected for a given deployment this may have an impact on the procedures used to convey information between entities during call establishment, requiring modifications to equipment already deployed in the network. The cost of updating network equipment to be interworking compatible may be prohibitively expensive for large networks. The preference should be to select an architecture that minimises the impact on the established call procedures and the deployed network infrastructure in both the SIP and H.323 s. In the two previous architectures, at least one of the administrative s participating in an inter () call will need to have protocol interworking capability. In a third scenario a third party provides the interworking capability (e.g. a clearing house). Figure 3

3 shows a situation where BT or Concert could provide clearing house services for calls between OLOs. In this case it may be necessary for interworking to be handled transparently, i.e. the originating and terminating s would not be aware that interworking was taking place. CH 3.1 Signalling s and address scope As mentioned previously, for administrative convenience and because of ownership, the networks may be partitioned into administrative s. The address scope may depend on administrative bounds even if two s use the same protocols. In these situations communication between administrative s may be used to resolve addresses. Alternatively, bilateral agreements between administrative s may exist with links to GW devices connecting, and controlling the flow of, between the two s. 3.2 Cross- Fig 3 SIP OLO1 BT clearing house+ H.323 OLO2 Inter- interworking using clearing house services When an end-point wishes to establish a call it must be determined where the recipient end-point resides and whether the call will proceed intra-administrative, inter-administrative, or go across s. Where the call goes inter- the location service must locate an appropriate device for converting between the messages and procedures of each (a ). If only one supports the protocol interworking capability, it will be the responsibility of that to provide the protocol interworking resources for any calls which cross- s. The interworking-aware can determine these situations when it originates a call or when a call arrives and needs to be terminated. In situations where both s have protocol interworking capability, it will need to be determined which s resources are used, i.e. which is used, where it is located, and who controls it. This may be determined via inter- negotiation (between layers) or via bilateral agreements. 3. Call routeing for interworking Before a call can undergo interworking, it must first be routed to an interworking function. The routeing information required for routeing inter- call segments will be provided by the back-end service layer within the respective s. This information may be contained locally or may require communication between back-end service layers in different administrative s. This process may occur in conjunction with a third party (clearing house) that provides address-translation and service-negotiation features, and perhaps also provides the interworking devices making protocol interworking transparent to both the originating and terminating s. The fundamental requirement of the layer, to support inter- calls, is to provide two pieces of information: the transport address of a, the transport address for the onward routeing of the call after interworking has been performed. However, this information does not have to be resolved in a single operation, and the latter can actually be determined on the egress side of the interworking function. 3.3 Interworking across layers The protocols used to communicate across s must allow address resolution, and may allow access authorisation and usage reporting between administrative s. An administrative may expose itself to other administrative s through a logical element known in H.323 terminology as a border element (BE) which may be considered as part of the layer. A border element may be collocated with any other entity (for example, with a gateway but typically as part of a gatekeeper). In the context of protocol interworking the layers may be used to determine the transport address of the controller (GK or SIP proxy) or an end-point (or proxy device) within the terminating. The protocols 121

4 used for inter communication may also advertise/ negotiate protocol interworking as a network service and determine which physical devices will be involved during a cross- call. IWF control layer Clearing-house services may be used to acquire address translations, negotiate interworking services, and provide the physical s as part of these services. H Interworking function The protocol interworking function itself (Fig 4) comprises a engine and an optional. The engine handles the translation of protocol messages received at reference points A and B, and maintains call states between SIP and H.323 end-points. Fig 4 A X engine Protocol interworking function internal architecture. The provides event notifications (e.g. mode es) which are communicated to the engine via reference point G. Media arriving at reference points X and Y may be transcoded, if required, by the. Ideally, es should, however, be avoided as their presence will increase the processing requirements and hence cost of interworking devices. A will also typically result in sub-optimal routeing and a loss of voice quality as the packets have to go first to the interworking function and then on to their destination. If es are required, transcoding should be avoided as this adds additional delay to perform codec operations, and may add significant distortion. However, if such an arrangement is required, it can be made to scale by associating multiple blocks with each engine (Fig 5). This architecture is similar to that defined for the decomposed GW architecture where a gateway controller (MGC) communicates with a number of gateways (MGs) [6]. G B Y Fig 5 Scaling the by using multiple es. 4.1 Protocol interworking H.323 has evolved through four versions since Version 2 is considered by many as the core version of the H.323 protocol suite although this may be supplanted by the new version 4. The H.323 protocol is extended by the inclusion of annexes that describe both core and peripheral protocol features. These extensions add to the base ASN.1 syntax or define profiles/procedures for protocol feature usage. H.323 is described in greater detail in a companion paper [7]. Each version of H.323 adds additional features and procedures that may not be supported when connecting with devices of an earlier version. In these situations it is usually possible for the more recent version to detect these situations either by checking protocol discriminators, the absence of fields or an expected response and may decide to drop back to a basic call. As each version of H.323 is intended to be backward compatible with earlier versions, then there should not be any interoperability issues for basic call handling, and consequently there should be no impact on interworking between H.323 and SIP where only basic call handling is considered. SIP, as a standard, is not stable and will take some time to reach the same level of maturity as H.323. Procedurally, SIP is relatively simple with information exchanges being carried out mostly by the overloaded INVITE, 200 OK and ACK transactions. The complexity of SIP is contained within the headers and message body contained within each SIP method. Additional procedures, used to extend the existing capabilities of SIP, are handled using new SIP methods (e.g. INFO and REFER methods), new headers, and the ability to carry additional information within the message body of a method request/response. A MIME type describes the information contained within a message body, e.g. the

5 MIME type for SDP is application/sdp. A fuller description of SIP and SDP is given in a companion paper [8]. SIP user agents (UAs) that do not understand more recently defined, or future, SIP methods would respond with the 501 Not Implemented status code. In the context of H.323/SIP interworking this may or may not cause the call to be failed back to the H.323, depending on the nature of the method and how critical the information conveyed in the method was for the call to proceed (or continue if already established). Any unknown headers within a given message may be discarded by SIP UAs or forwarded through SIP proxies. The features that these unknown headers represent would not be usable during that call session. Any Require headers indicating capabilities required within the SIP UA, that are not supported, will cause the call to fail. The SIP UA would respond by sending status code 420 Bad Extension including those options it does not support, using Unsupported headers within the final response. Additionally, a new version of SDP, called SDPng, is being developed by the IETF. This will probably require different parameter mappings to be performed by the interworking function, but the basic message sequences should remain the same. 4.2 Feature loss and parameter defaulting Some features may have no parallel when mapping from one protocol set to another. In these instances these features are lost, leading to a reduced level of capability during the session. For basic call handling this is not an issue. If extra features are required in addition to basic call handling that cannot be interworked, the call will have to be failed. Some message parameters may not have the granularity required to sufficiently describe parameter mappings from other protocols. This may also lead to a reduced ability to negotiate features during the session and may, in addition, have other unforeseen side effects. H.323 is much richer in describing call attributes than SIP. Consequently, in mapping parameters from H.323 to SIP there is a greater opportunity for feature loss. The impact of this feature loss on the call depends on whether the features described are mandatory or optional. The interworking function will need to determine if a call may proceed under these circumstances. There will be occasions where there is no appropriate placeholder for a SIP header within an H.323 message parameter. Again, the will need to determine if an alternate means of conveyance can be used and, if not, whether a call may proceed under these conditions. Typically it would be expected that many H or H.245 parameters would need to be set to default values when mapping from SIP to H.323. Standard profiles may be required to assist in this parameter defaulting process. 5. End-to-end negotiation of RTP channels are used to convey between two or more end-points in a session. Associated with an RTP channel are two RTCP channels, each of which conveys RTP control information, in both the forward and the reverse directions, between end-points. H.245 is used to negotiate and select modes while SDP is used primarily to advertise modes and receive ports. Both protocols convey similar information but there are subtle differences. H.245 provides a more complete bearer control function than is available with SDP and is more explicit in the way information is conveyed between end-points. Typically the H.245 procedures comprise request/ response exchanges between end-points. These H.245 messages may be handled by the in a number of ways when interworking to SIP/SDP: map into INVITE, 200 OK, ACK transactions with a modified session description and any relevant SIP headers (e.g. OLC/OLC ACK), always reject (e.g. mode requests), always accept (e.g. round-trip delay). Due to the evolution of H.323 aimed at improving call set-up time, there are four modes in which H.245 can be used (these modes are explained further in the ITU Recommendation [9]): nominal H.245 (or slow start), early H.245, Fast Connect (or fast start), tunnelling (or encapsulation). SDP is simpler than H.245 in that, in conjunction with SIP, it attempts to convey the same information in a single round trip. Consequently, SDP is not as flexible in being able to describe sets of codecs or indicating how they are to be used in a session. An SDP description may contain multiple modes for a given channel and the SIP UA is free to select 123

6 124 any valid combination and later between them without explicitly this to the remote UA. This differs from H.245, which explicitly signals which modes are going to be used. All SDP message bodies are conveyed via SIP messages. Each time a session description needs to be updated this requires INVITE, 200 OK and ACK transactions to occur. In the SIP/SDP to H.245 direction, the session description and any related SIP headers must be analysed to determine the meaning of the overloaded SIP INVITE message. 5.1 Call-flow scenarios Each call-flow scenario will depend on the direction of the call (e.g. H.323 to SIP or SIP to H.323), which H.245 procedural mode is used (e.g. Fast Connect), and when session information becomes available. Even though both H.323 and SIP are attempting to solve the same problem space (that of establishing sessions on IP networks), there are subtle differences that make interworking awkward. One of the main issues to contend with is the mismatch that occurs when information is available within each protocol, at each stage of the call-establishment process. In order to construct a session description, to send to the SIP UA, the modes, and associated receive RTP/RTCP [10, 11] port information, that are offered by the H.323 endpoint, are required at the. This information arrives at different points in the H.323 call-establishment process depending on which H.245 procedural mode of operation is used. Within SIP, the session description describes and ports to be used to receive the RTP streams. As there is only a single port described within the description, this information must describe not only the RTP port, but also the RTCP channel receive port. In SDP the relationship between the ports (RTP) and control ports (RTCP) is fixed. An associated RTCP port is chosen as the RTP port number plus one, i.e. RTP/RTCP ports are paired together. Within H.323 the RTP and RTCP information is conveyed in the OLC/OLC ACK message exchange. If the H.323 receive RTP and RTCP ports do not have the relationship RTCP port equals RTP port plus one, most likely will only be received in one direction as the RTCP information would be sent to the wrong port. A could be used to provide interworking of these ports by providing an appropriate mapping from one side to the other. A response containing a session description (responding to the initial Invite) can only be sent to a SIP UA when the H.323 end-point s capabilities are known (when the terminal capability set arrives at the ). Even at this stage the H.323 receive RTP/RTCP port information is not known, requiring each mode to be paused in the session description sent to the SIP UA; this is carried out by setting the connection address in the SDP to As channels are opened on the H.323 side of the, the session description can be updated to include the RTP/ RTCP address and port information. For the Fast Connect procedures, the offered transmit and receive modes and associated RTP/RTCP port information are available within the Fast Connect element of the SETUP message allowing a session description to be sent in the subsequent INVITE message. Irrespective of the H.245 procedural mode used, a further issue is that SIP does not have the equivalent logical channel procedures of H.323. A SIP UA selects to transmit from the receive capabilities contained within the received session description. Even for Fast Connect there is no way for the to determine which receive options, derived from a session description, should be included within the Fast Connect element to be signalled back to the H.323 end-point. An example call flow using the nominal H.245 procedures is shown in Fig 6. In order for the H.323 endpoint to receive from the SIP UA, the must make channel choices on behalf of the SIP UA. A selection scheme based on symmetry may be used. As the H.323 end-point opens towards the SIP UA, the enables reception of the same mode within the session description, for transmission from the SIP UA, to the H.323 end-point. Such a modified session description is sent to the SIP UA in a re-invite. By limiting the receive capabilities described for each channel in the session description sent to the SIP UA the modes that may be transmitted towards the H.323 end-point are restricted to those that have been opened by the H.323 end-point. 5.2 Impact of SIP mode selection and ing If it is deemed desirable to allow the SIP UA more influence in the decision of which type to use, a, capable of events to the control layer of the, can be used. As the SIP UA transmits, the can notify the control layer of the, which in turn carries out the logical channel procedures to open the channel from the SIP UA to the H.323 end-point. SIP mode ing can also be handled easily using this mechanism. When mode ing occurs this can be detected by the and signalled up to the control functions of the. This can be carried out using a gateway control protocol [6] or via a private (proprietary) interface.

7 H.323 EP IWF SIP UA Fig 6 setup proceeding alerting connect TCS TCS OLC OLC ACK OLC OLC ACK OLC OLC ACK OLC OLC ACK invite(-) 100 trying 180 ringing 200 OK (SDP) ACK(SDP) invite(sdp ) 200 OK ACK invite(sdp ) 200 OK ACK Example call flow using nominal H.245 procedures. Once these events are signalled to the control functions of the, they can be mapped into the appropriate H.245 logical channel procedures. The may also be required when interworking RTP/RTCP port parameters as H.245 allows greater flexibility over the actual port values that are chosen compared to SDP. 5.3 Mapping session descriptions and terminal capability sets In order that SIP user agents and H.323 end-points can establish sessions with each other, the must be able to convert between session descriptions and terminal capability sets, and vice versa. For the purposes of conversion between session descriptions and terminal capability sets, SDP essentially specifies a number of port pairs. Along with the specification of each port pair is a description of the alternative types of that can be received on that port pair (see Fig 7). A port pair shall only be able to receive a single type of, e.g. audio, video or perhaps data. Fig 7... m=audio <port 1> RTP/AVP a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:15 G728/8000 m=video <port 2> RTP/AVP 31 a=rtpmap:31 H261/90000 m=video <port 3> RTP/AVP 32 a=rtpmap:32 H263/90000 Media description and attribute lines within a session description. A terminal capability set (see Tables 1 and 2) describes a number of simultaneous capabilities, each of which has the expressiveness to describe a single SDP session description. Each simultaneous capability contains multiple sets of alternative capabilities. The expressiveness of an alternative capability set is equivalent to that of SDP s description of a single port pair. As such, each alternative capability set specifies a number of types, only one of which can be used at a time. As a result, the production of a terminal capability set from a session description is essentially a straightforward one-to-one process of generating a terminal capability set that contains a single simultaneous capability, which contains one or more alternative capability sets, each of which expresses the capabilities specified for each port pair. Table 2 Table 1 TCS capability table. Capability number Direction Capability 1 Rx G.711 ULAW64 2 Rx GSM 3 Rx G Rx H Rx H.263 Simultaneous capability set TCS simultaneous capability table. Alternate simultaneous capabilities 1 {1, 2, 3}, {4}, {5} For example, the SDP description in Fig 7 can be expressed by the single simultaneous capability set shown in Table 2. This contains three alternative capability sets, each corresponding to the section starting with m= in the SDP description. The codecs contained in each alternative capability set are expressed in terms of numbers. These are enumerated elsewhere in the terminal capability set in a form similar to that shown in Table 1. Consequently it can be seen that the first alternative capability set corresponds to G.711-µ Law, GSM and G.728, as does the first m= line in the SDP description (Fig 7). Producing a session description from a terminal capability set is not such a direct process. In principle, the process could be achieved by selecting one of the simultaneous capabilities within the terminal capability set and mapping that into a session description in a mechanical way. 125

8 126 Thus the key to a good terminal-capability-set-tosession description mapping is in the selection of the relevant simultaneous capability to convert. The basis for choosing the appropriate simultaneous capability set depends on whether or not a session description from the SIP user agent server (UAS) is available. If such a session description is available, it is desirable to select the simultaneous capability set that realises the most functionality when interworking with the session description of the SIP UAS. There is no single correct answer for how such a decision can be made. If no session description is available, the simultaneous capability set chosen should be the H.323 end-point s most preferred one, i.e. the simultaneous capability set with the lowest capabilitydescriptornumber. In summary, although information will be lost in the mapping process, and as a result interworking may take place using a sub-optimal set of modes, conversion between session descriptions and terminal capability sets is practical with minimal effort. When SDPng is developed for use with SIP, it may be possible to use more of the expressiveness contained in a terminal capability set. However, in both cases it should be pointed out that the interworking function needs knowledge of the various codec types available, and how these can be mapped from one to another. Consequently, an interworking function may limit the types of that can be used between two endpoints if it is not aware of the types, even if the two end-points support the codecs. 6. Conclusions With hindsight, the competition between the multi protocols developed by the ITU and the IETF has preordained that no single protocol will dominate the multi-over-ip space for a long time to come. This is unfortunate for a technology that is still in its formative years. Not only does it complicate investment decisions in this area, leading to more conservative deployment strategies, but it also undermines the end-to-end principles that have made the Internet so successful. The effect is that services offered to the customer will be fragmented and confusing, which may ultimately cause the customer to look elsewhere for the services that multi over IP could offer. Interworking between the protocols can go some way to bridging the gap, but there is inevitably some loss of functionality across such a border. Interworking functions are also core infrastructure components, which typically have a slower development curve than edge devices. As exciting services are deployed in each of the s, the interworking functions will effectively slip further and further behind, widening the disparity between the networks. This is regrettable, as the true benefit of multi over IP is not simply cheaper voice calls, but the exciting services that a combination of voice and data can offer. With the realisation that interworking is no panacea, there is scope for collaboration between the ITU and the IETF in agreeing on a common way of augmenting their respective protocol sets. This would allow interworking functions to treat protocol extensions generically, and provide a lossless conversion without requiring detailed knowledge of all features. While technically feasible, the hearts and minds of the interested parties within the various standards bodies are currently far from this view. It is only with co-operation between the ITU and the IETF that multi over IP will move beyond a technological curiosity to reach commercial fruition. References 1 ITU-T Recommendation H.323, V4: Packet based multi communication systems, (November 2000). 2 Handley M et al: SIP: session initiation protocol, IETF RFC 2543 (March 1999). 3 Handley M and Jacobson V: SDP: session description protocol, IETF RFC 2327 (April 1998). 4 PacketCable: Packet voice communications over cable television infrastructures, 5 Wang D: ETSI ETR Telecommunications and Internet protocol harmonisation over networks (TIPHON); requirements definition study; SIP and H.323 Interworking, (2000). 6 Rosen B: VoIP gateways and the Megaco architecture, BT Technol J, 19, No 2, pp (April 2001). 7 Cordell P J, Potter J M M and Wilmot C D: H.323 a key to the multi future, BT Technol J, 19, No 2, pp (April 2001). 8 Wisely D R: SIP and conversational Internet applications, BT Technol J, 19, No 2, pp (April 2001). 9 ITU-T Recommendation H.245, V5: Control protocol for multi communication, (June 1999). 10 Schulzrinne H, Casner S, Frederick R and Jacobson V: RTP: a transport protocol for real-time applications, IETF RFC 1889 (January 1996). 11 Schulzrinne H: RTP profile for audio and video conferences with minimal control, IETF RFC 1890 (January 1996).

9 Tony Stephens joined BT as an apprentice in 1988 and after graduating from Sheffield University in 1995 returned to BT to work on the VC8000/DVS100 videoconferencing product, adding Internet and remote LAN access capabilities. In 1997 he joined the multi applications unit working on H.323 and the VISITA project. In 1999 he joined the middleware and applications unit continuing his work on VISITA looking at scalable IP call control node, architectures using H.323, and their interconnection to intelligent network platforms. This work involved contributing and presenting papers to both the ITU-T SG16 and ETSI TIPHON standards bodies. Pete Cordell joined BT in 1982 after graduating from Sussex University with a first in electronics. He worked on slow scan TV systems for two years before taking a full time PhD in image coding at Heriot Watt University. On return to BT he was involved in the design of the VC8000 PC conferencing card, and then moved on to H.323 standardisation work in late He has been a key contributor to the H.323 standard, being responsible for a number of key features, and has been involved in the development of SIP. He has implemented versions of both standards, and advises others in the area of VoIP. He is now an independent contractor specialising in VoIP consultancy. 127