Interworking Between SIP/SDP and H.323 Kundan Singh and Henning Schulzrinne IRT Lab, Dept. of Computer Science Columbia University New York, USA hgs@cs.columbia.edu

SIP vs H.323 Both use RTP/RTCP over UDP/IP Text-based (HTTP-like) request response SDP (media types and media transport address) Server roles: registrar, proxy, redirect Binary ASN.1 PER encoding Sub-protocols: H.245, H.225 (Q.931, RAS, RTP/RTCP), H.332, H.450.x... H.323 Gatekeeper Both use RTP/RTCP over UDP/IP

Interworking Problems Call setup translation H.323 SIP Q.931 SETUP INVITE Destination address Q.931 CONNECT 200 OK Terminal Capabilities Media capabilities Terminal Capabilities ACK Open Logical Channel Media transport address Open Logical Channel Problems in call setup translation: Three pieces of information needed for call setup : Destination signaling address Self and remote media capabilities Self and remote media transport address SIP carries these in INVITE and its response. H.323 spreads them across different stages. Mapping multistage dialing in H.323 to single stage in SIP is not trivial. H.323 v2 Fast-Start supports single stage dialing, but it is optional.. Multi-stage dialing H.323v2 Fast-start is optional

Interworking Problems User Registration SIP H.323 ? H.323 Gatekeeper SIP registrar H.323 terminal SIP user agent Problems in user registration: User may be registered in either H.323 or SIP network, and should be callable from either H.323 or SIP endsystems. Location independent user identifier ? Use information from both networks

Interworking Problems Media Description H.323/H.245 Supports inter-media constraints { [G.711 Mu law, G.711 A law][H.261 video]} { [G.723.1] [no video] } SIP/SDP List of alternative set of algorithms. audio G.711 µ-law, G.723.1, G.728 video H.261 H.245 can represent media constraints as shown in the example. SDP is very simple and can not specify such constraints. How do we translate H.245 capabilities to SDP ? One approach is to use multiple SDP in SIP message. Our approach of “maximal intersection” does not need such things. Other problem, how to allow selection of audio/video algorithms by the endsystems, instead of by the signaling gateway. Translation in both directions Algorithm selection by end-systems

Interworking Problems Advanced Services H.323 conferencing: centralized signaling control, MC (Multi-point Controller) Supplementary services: H.450.x SIP conferencing: centralized bridged + full mesh + multicast New headers : Also, Requested-By, Replaces H.323 has centralized control for conferencing. SIP supports both centralized and distributed conferencing. H.323 invents new protocols (H.450.2 for call transfer, H.450.3 for call diversion, H.450.4 for call hold) and so on. In SIP, crucial pieces are identified (e.g., Also, Requested-By, Replaces headers) and additional services are built upon them.

User registration Registration info to foreign network Three ways: SGW + GK, SGW + proxy/registrar, SGW REGISTER hgs@columbia.edu Contact:sgw SIP registrar server H.323 Gatekeeper + SGW sgw.columbia.edu INVITE hgs@columbia.edu RRQ hgs@columbia.edu Contact:128.59.19.200 3xx Moved Contact:sgw SIP user agent H.323 terminal 128.59.19.200 To solve the user registration problem: registration information should be transported to the foreign network. This allows for three different architectures: Signaling gateway co-located with H.323 gatekeeper Signaling gateway co-located with SIP registrar/proxy Independent signaling gateway. The first scenario is shown in an example. H.323 terminal’s registration information is transported to SIP network. Now any SIP entity can also reach the H.323 terminal. In the second architecture, SIP registration information is transported to H.323 gatekeepers, which can then resolve the SIP addresses also. If the signaling gateway is independent of the registration servers, it can use SIP OPTIONS and/or H.323 Location Request (LRQ) to check the validity of the address in SIP and H.323 networks respectively. Independent SGW preferable - use SIP OPTIONS and H.323 LRQ

Call Setup with H.323v2 Fast Start One-to-one mapping between SIP and H.323 messages. H323 SIP Setup/FastStart INVITE Connect/FastStart 200 OK ACK With H.323 fast start, there is a one-to-one mapping between the SIP and H.323 messages, as the media description is also carried in H.323 Setup and Connect messages. Translation is simple. RTP/RTCP Reverse direction is similar

Call Setup without Fast Start, SIP to H.323 Setup/Q931 INVITE Signaling Gateway Connect/Q931 Capabilities/H245 Capabilities/H245. Media Transport Address 200 OK. Open Logical Channel/ H245 Without Fast start, translation is simple in SIP to H.323 direction, because all three pieces of information needed for call setup are available in SIP INVITE message. This can be split across multiple messages of H.323. Once the media transport addresses of H.323 endpoint is known in OpenLogicalChannelAck, a confirmation can be sent to SIP endpoint. RTP and RTCP are carried directly between endsystems, since both endsystems know about the media transport address of the other. Acknowledgement Open Logical Channel / H245 ACK Acknowledgement RTP/RTCP

Call Setup without Fast Start, H.323 to SIP Setup/Q931 INVITE Signaling Gateway Connect/Q931 200 OK Capability Exchange ACK Media Transport Address Open Logical Channel Re-INVITE/SIP+SDP Without Fast start in H.323 to SIP direction: The signaling gateway forwards INVITE to SIP on receipt of Setup from H.323. This INVITE contains dummy SDP. Once the confirmation is received from SIP endpoint, Connect is sent on H.323. Since the INVITE response from SIP contains the SDP of SIP side, it can be used to send and acknowledge H.323 capability negotiation and logical channel messages. Once the acknowledgements for all the logical channel messages in SIP to H.323 direction, are received, the signaling gateway knows the media transport address of H.323 endpoint and it can send re-INVITE with new SDP to SIP endpoint. RTP and RTCP are carried directly between endsystems, since both endsystems know about the media transport address of the other. Acknowledgement Open Logical Channel Acknowledgement RTP/RTCP

Capability set in each direction Maximal intersection and current operating modes Re-INVITE or change in H.323 mode or logical channels, whenever it changes Example: C1 = { [PCMU, PCMA, G.723.1] [H.261] } C2 = { [PCMU, PCMA, G.729] [H.261] } C1  C2= {[PCMU, PCMA] [H.261]} operating modes = [audio=PCMU,video=H.261] The signaling gateway maintains capability sets of both SIP and H.323 endpoints in each direction. These capability sets are used to calculate maximal intersection of capability sets in each direction. Then an operating mode is derived for each direction (for each media type) by selecting one algorithm from the alternative set in the maximal intersection. The H.323 logical channnels and SIP SDP are formatted using these operating modes. Whenever there is a change in operating modes, SIP reINVITE and/or H.323 ModeRequest/Open and CloseLogicalChannel are sent as appropriate.

SIP-centered or H.323-centered conferencing Conclusion and Future Work Ad-hoc conferencing SIP-centered or H.323-centered conferencing Basic call setup  other supplementary services Initial implementation: openh323+Columbia stack for basic audio call efforts in IETF (SIP WG task force), ITU and ETSI TIPHON Convergence between SIP and H.323 in newer versions (fastStart, UDP) Because of the different nature of conferencing (distributed and centralized in SIP and centralized on H.323) ad-hoc conferencing is difficult. Various assumptions can simplify the design: 1) Use SIP centered conferencing, where the H.323 entities take part in the conference through the signaling gateway. 2) Use H.323 centered conferencing, managed by a multipoint controller (MC) Other supplementary services can be translated fairly easily once the basic call establishment translation is specified. ----- Our system: audio only, PCMU, between netmeeting and ephone, on WinNT and Solaris. H.323 has picked up a number of features from SIP, such as Fast Start or, more recently, UDP based signaling. The problem can be made tractable by keeping an SGW aware of all call state changes.