1. SIP & H.323 Interworking
Name: Amir Zmora
Title: PM
Date: Feb

2. Agenda The Need for Interworking SIP – H.323 Interworking
Types of Implementations
Optional Co-Locations
Summary
References
The Need – How much as how long?
Levels of Interworking – Pre-call, basic calls, advanced call services.
Implementations – Softswitch, SG in ITSP/Enterprise. SG co-located GK, Proxy or stand alone.
Open Issues – What needs to resolve what can’t be.
Summary ..

3. The Need for Interworking

4. A Bilingual VoIP World H.323 SIP
Large installation base
H.323 is still being developed and deployed
Enterprises are currently staying with H.323
SIP
On carriers’ roadmap in addition to H.323
Softswitches mostly support SIP
3GPP has adopted SIP
Enhanced features (Presence, Instant Messaging)
The future of VoIP
SIP and H.323 will coexist for years to come therefore Interworking function (IWF) is required!
Enterprise – Stay with H.323 (IP PBX H.323)
Carriers – Goes SIP (softswitch mostly SIP)
IWF is a need!
Over the past several years, H.323 has been very widely deployed, particularly as the standard has evolved
and interoperability has increased between H.323 vendors.
Currently, over 90% of worldwide voice-over-IP (VoIP) traffic is running on the H.323 protocol.
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
they think to provide services to satisfy their customers' needs.

5. Situational Analysis: VoIP Developers’ Protocol Support
Plans to Add Support
H %
SIP - 77%
MGCP - 36%
MEGACO - 53%
Miercom Survey - 96 VoIP vendors responded worldwide (8/2001)

6. SIP – H.323 Interworking

7. Open Issues Synchronize with each protocol upgrade
Resolve unmapped message scenarios
Advanced call control handling
Overlap sending
Multiparty conferencing
Media switching
Handling SIP-H.323 security services
QoS exchange between protocols– OSP ?
Scalability– address resolution
Multiparty conf. Several optional architectures – will see later.
Advanced call control – partially mapped 1:1
Security – different systems an IWF for security needs to be build into the IWF.
Auth, … - Can be based on H.323 concept (more mature)
Billing - Can be based on H.323 concept (more mature)

8. The VoIP Protocols H.323 SIP TCP/UDP IP IP Layer
VoIP Protocols Provide: Signaling, Media Control and Media Streaming
Many similar components, but…
IP Layer
TCP/UDP IP
TPKT
Q.931
H.245
RAS
RTCP
RTP
Application Layer
Codecs
SIP
SDP
H.323
SIP
Same color. (Same IP layering ) Similar vs, exactly the same.
When we are looking on the protocol stacks we see similar functions:
Both operate over IP and uses RTP. Same Media transport functionalities: RTP,RTCP, Codecs
The difference in signaling.
The key differences:
Signaling (Q.931 and RAS vs. SIP
H.245 vs. SDP

9. Main Mapped Functions Registration Address Resolution Call Control
Call establishment and teardown
Supplementary Services
Out of band signaling (e.g. DTMF)
Media Control
Capabilities exchange
Multimedia channel handling
Multipoint conferencing
Media Streams Transport
Other Add-On Services
Presence, IM, etc.
These are the service types that should be mapped between the protocols.
There is a message mapping model defined in the IETF draft.
A message can be translated to one or more messages in the other protocol.
Some messages can not be mapped (protocol difference regarding with services).
E.g. call control and call services are quite different.
Registration is optional and include alias/name mapping to address, service authorization, etc.

10. Interworking issues Call establishment Address mapping
Getting more complex when H.323 is not using Fast Start
Address mapping
H.323 – Multiple addresses in alias list
Single address
Session description mapping
SDP Vs H.245
More information on this can be found at end of presentation

11. Basic Call Scenario H.323 to SIP
INVITE
Ringing
Alerting OK
Connect
IWF
H.323 Endpoint
SIP User Agent
H.245
May be included in Fast Start
SDP
Included in the INVITE
Fix - SDP in INVITW to H.245
The Gatekeeper, what its role is, in the network architecture, ..
The architecture of the GK toolkit
Functionality review of previous version ..
What’s new in Version 4
RTP/RTCP
Common protocol

12. Basic Call Scenario SIP to H.323
INVITE
Alerting
Ringing
Connect
IWF OK
H.323 Endpoint
SIP User Agent
H.245
May be included in Fast Start
SDP
Included in the INVITE
The Gatekeeper, what its role is, in the network architecture, ..
The architecture of the GK toolkit
Functionality review of previous version ..
What’s new in Version 4
RTP/RTCP
Common protocol

13. Class 5 Features Mapping
H.323 and SIP address supplementary services differently
H.323 defines each feature specifically
SIP provides building blocks and call flows
H.323
Call Transfer
Call Diversion/Forwarding
Call Hold
Call Park and Pickup
Call Waiting
Message Waiting
Name Identification
Call Completion on Busy
Call Offer
Call Intrusion
SIP
Call Transfer
Call Forwarding
Third-Party call control
Call Hold, Music on Hold
Single line extension
Incoming Call Screening
Outgoing Call Screening
Find-Me
Call Park & Pickup
Automatic Redial
H.323 and SIP uses different set of supplementary services with some common base.
Call Transfer and Forwarding are similar.
SIP uses a different concept to enable various sup. services.
Call forwarding and Park and Pick-up have some similarity.
SIP to H.323 feasible map.
H.323 to SIP – harder/impossible (e.g. Call intrusion and call offer are not supported in SIP and need special protocol extensions)
Most of these services are not widely deployed and used in relatively small ratio of call scenarios.

14. Multiparty Conferencing
H.323
Terminal
SIP
Terminal
SGW
SIP
Terminal
SIP
Terminal
MCU
H.323
Terminal
SIP
Terminal
H.323
Terminal
H.323
Cloud
SIP
Cloud
Both SIP and H.323 support Ad-hoc conferencing.
In SIP conference topology can be full meshed. (Every EP has signaling with other EP).
In H.323 it may be managed by a central device (MCU star topology) or be decentralized.
The mapping is still an open issue in means of standardization, but it is feasible in most cases.
SGW
SIP
Terminal
SGW
H.323
Terminal
H.323 Centralized/ Decentralized Conferences
SIP Full Meshed Conference

15. Types of Implementations

16. Gateway Types Softswitch at the ITSP Edge
Signaling Gateway at the ITSP Edge
Signaling Gateway at the Enterprise Network Edge
SDP – Session description protocol. H.245 include folow control, chair control (who master the control)
H.245 call control. H.245 is much advanced than SDP and hence :
SDP to H.245 – easy
H.245 to SDP – complicated / impossible.
Example : Not mapped example.

17. Softswitch at the ITSP Edge
Enterprise
Enterprise
Proxy Server
Gatekeeper
Softswitch
H.323
SIP
ITSP
IP Network
That is a typical network architecture of both networks with a signaling gateway in between.
NETCENTREX.NET Call Control Server - Softswitch H.323, SIP, and MGCP
COMGATES.com CVPM Multiprotocol switch
PointOne.com A VoIP SP ramped to 4 million minutes VoIP per day.
iBasis.com ?
Continuant Softswitch SIP, H.323, MGCP
Gateway
SCN
Gateway

18. Softswitch at the ITSP Edge
At the network edge
Focuses on bridging IP and PSTN
Delivers mostly add-on services
Very complex
Must be carrier-grade
High capacity
Highly redundant
Expensive!
From NGN Ventures 2001 Apr-2001!
Next-generation switches must support voice services - not only for IP- and ATM-based networks but also for the time-division multiplexer (TDM)-based PSTN. In addition to call control and resource management, there are other requirements of softswitches and next-generation switches:
??Media independence - Softswitches must be agnostic in regards to the network (such as ATM, IP and TDM).
??Interoperability - Softswitches must work with other softswitches and media gateways from multiple vendors.
??Reliability - Softswitches must be reliable to carrier standards.
??Support for multiple signaling and control protocols - Softswitches must support emerging and established standards.
??Scalability - Softswitches must meet carrier network requirements, supporting thousands of call attempts, also known as Busy Hour Call Attempts and simultaneous calls.
??Open application interfaces - Softswitches must support third-party software applications and services.
Softswitch architecture provides two major advantages over current PSTN switch technologies. The first is openness between subelements of a next-generation switch. This openness promotes the ability to mix best-of-breed components, which gives service providers greater flexibility and a clear growth path. A service provider can buy a media gateway from Vendor A, a softswitch/media gateway controller from Vendor B, a signaling gateway from Vendor C and an application server from Vendor D.
The second major advantage of softswitches is that they give service providers added flexibility in providing new services. A service provider could develop telephony services that could be implemented on the application server. They do not have to depend solely on a switch provider for a critical service, as is the case with traditional PSTN switches.
Kafel is vice president of marketing at Telica. He can be reached at telica.com.

19. Signaling Gateway at the ITSP Edge
IP Network
Enterprise
H.323
Gatekeeper
Softswitch
Gateway
SIP
SIP Proxy
Signaling Gateway
That is a typical network architecture of both networks with a signaling gateway in between.
SCN

20. Signaling Gateway on the ITSP Edge
On the network edge
Focuses on “simple” H.323-SIP bridging
No add-on services
Simple functionality
Must be carrier-grade
High capacity
Highly redundant
Relatively inexpensive
From NGN Ventures 2001 Apr-2001!
Next-generation switches must support voice services - not only for IP- and ATM-based networks but also for the time-division multiplexer (TDM)-based PSTN. In addition to call control and resource management, there are other requirements of softswitches and next-generation switches:
??Media independence - Softswitches must be agnostic in regards to the network (such as ATM, IP and TDM).
??Interoperability - Softswitches must work with other softswitches and media gateways from multiple vendors.
??Reliability - Softswitches must be reliable to carrier standards.
??Support for multiple signaling and control protocols - Softswitches must support emerging and established standards.
??Scalability - Softswitches must meet carrier network requirements, supporting thousands of call attempts, also known as Busy Hour Call Attempts and simultaneous calls.
??Open application interfaces - Softswitches must support third-party software applications and services.
Softswitch architecture provides two major advantages over current PSTN switch technologies. The first is openness between subelements of a next-generation switch. This openness promotes the ability to mix best-of-breed components, which gives service providers greater flexibility and a clear growth path. A service provider can buy a media gateway from Vendor A, a softswitch/media gateway controller from Vendor B, a signaling gateway from Vendor C and an application server from Vendor D.
The second major advantage of softswitches is that they give service providers added flexibility in providing new services. A service provider could develop telephony services that could be implemented on the application server. They do not have to depend solely on a switch provider for a critical service, as is the case with traditional PSTN switches.
Kafel is vice president of marketing at Telica. He can be reached at telica.com.

21. Signaling Gateway on the Enterprise Network Edge
SIP Proxy
Gatekeeper
SIP
Signaling Gateway
H.323
Enterprise
SIP
Proxy
SIP
Gateway
Softswitch
That is a typical network architecture of both networks with a signaling gateway in between.
SIP
Gateway
ITSP
IP Network
SCN
Gateway

22. Signaling Gateway at the Enterprise Network Edge
At the network edge
Focus on “simple” H.323-SIP bridging
No add-on services
Simple functionality
Does not need to be carrier grade
Inexpensive
From NGN Ventures 2001 Apr-2001!
Next-generation switches must support voice services - not only for IP- and ATM-based networks but also for the time-division multiplexer (TDM)-based PSTN. In addition to call control and resource management, there are other requirements of softswitches and next-generation switches:
??Media independence - Softswitches must be agnostic in regards to the network (such as ATM, IP and TDM).
??Interoperability - Softswitches must work with other softswitches and media gateways from multiple vendors.
??Reliability - Softswitches must be reliable to carrier standards.
??Support for multiple signaling and control protocols - Softswitches must support emerging and established standards.
??Scalability - Softswitches must meet carrier network requirements, supporting thousands of call attempts, also known as Busy Hour Call Attempts and simultaneous calls.
??Open application interfaces - Softswitches must support third-party software applications and services.
Softswitch architecture provides two major advantages over current PSTN switch technologies. The first is openness between subelements of a next-generation switch. This openness promotes the ability to mix best-of-breed components, which gives service providers greater flexibility and a clear growth path. A service provider can buy a media gateway from Vendor A, a softswitch/media gateway controller from Vendor B, a signaling gateway from Vendor C and an application server from Vendor D.
The second major advantage of softswitches is that they give service providers added flexibility in providing new services. A service provider could develop telephony services that could be implemented on the application server. They do not have to depend solely on a switch provider for a critical service, as is the case with traditional PSTN switches.
Kafel is vice president of marketing at Telica. He can be reached at telica.com.

23. Optional Co-Locations
Address Resolution
Optional Co-Locations

24. Within SIP Proxy SIP Calls H.323 Calls Register with SIP Proxy
SIP - H.323
Signaling Gateway
REG
SIP Proxy/ Registrar
SIP UA
H.323 Terminal
Gatekeeper
RRQ
LRQ
SIP Calls
Register with SIP Proxy
SIP Proxy forwards UA Registrations to Gatekeeper via SG
H.323 Calls
Regular RAS scenario
Drawbacks: H.323 GKs needs to be registered with all SIP entities.
SIP Proxy vendors choice

25. Within Gatekeeper SIP Calls H.323 Calls Similar to regular SIP Calls
SIP - H.323
Signaling Gateway
REG
Gatekeeper
SIP UA
H.323 Terminal
RRQ
SIP Proxy/ Registrar
SIP Calls
Similar to regular SIP Calls
H.323 Calls
RAS
Forward to proper
SIP Registrar/Proxy
Drawbacks: SIP Proxy register all addresses.- efficiency
Plus: Can operate where part of GKs does not have IWF.
H.323 vendors choice.

26. As An Independent Entity
REG
SIP Proxy/ Registrar
RRQ
H.323 Terminal
SIP UA
Gatekeeper
RRQ
REG
SIP - H.323
Signaling Gateway
SIP Calls
Register with SIP Proxy
When call reaches the signaling gateway it queries the H.323
network
H.323 Calls
Register with Gatekeeper
When call reaches the signaling gateway it
queries the SIP network
The SGW is responsible for location queries in the other network when a call is reaching to it.
It should support direct signaling between EPs.
Drawbacks:
Plus:
Each network is responsible for registration process.
Useful for interconnect H.323 and SIP “pure” environments.

27. All-In-One SIP Calls H.323 Calls Signaling Gateway
REG
SIP Proxy/ Registrar
RRQ
H.323 Terminal
SIP UA
Gatekeeper
SIP - H.323
Signaling Gateway
SIP Calls
Register with SIP Proxy
H.323 Calls
Register with Gatekeeper
The SGW is responsible for location queries in the other network when a call is reaching to it.
It should support direct signaling between EPs.
Drawbacks:
Plus:
Each network is responsible for registration process.
Useful for interconnect H.323 and SIP “pure” environments.
Signaling Gateway
Use both for address resolution

28. Conclusion

29. Summary
We are in a multi-protocol world therefore both SIP and H.323 should be supported
Increased complexity of H.323 and SIP create interworking and interoperability challenges
Advanced call services – complex/open issue
Several Logos of VoIP coexisting Vendors
They all got the stacks…
Our benefit : Best Toolkits for both protocols.

30. References

31. References of Interworking Standards
IETF SIP-H.323 Interworking draft “draft-agrawal-sip-h323-interworking-reqs-03.txt”
Links:
My mail:
The draft address many interworking issues and in is an advanced one upgrading
An older one.
This draft was one of the main input for the presentation.

32. Interworking Issues

33. Call Establishment SIP INVITE / H.323 Fast Start Regular H.323 Setup
Signaling Destination Address
Local and Remote Media Capabilities
Local and Remote Media Addresses
Regular H.323 Setup
Stage-1: Signaling Destination Address
Stage-2: Local and Remote Media Capabilities
Stage-3: Local and Remote Media Addresses
SIP INVITE is similar to fast start regarding with message content.
Hence mapping SIP INVIVE with H.323 fast start is simpler than
Mapping between Regular H.323 V1 setup and SIP.

34. Address Mapping Issues - 1
H.323 uses several ASN.1 fields while SIP uses URI only
SIP URI to H.323 address is simple
H.323 address to SIP might be complicated
Address Translation Example SIP To H.323
Mapped in H.323 to->H.323 Address: {
e = " ",
h323-ID =
url-ID =
-ID= }
H.323 holds the address as several ASN.1 fields while SIP puts it all
In ascii delimited.
In the common format types the translation is simple.
e.g.
SIP to H.323:
SIP – URL where user=phone or all digits will mapped to E.164
SIP (“mailto:…) - the same
Transport id – the same
H.323 to SIP:
E.164 to URL with user=phone
H.323Id of to
Id : to
URLId to
With H.323 only formats, there should be some work around.

35. Address Mapping Issues - 2
H.323 to SIP Address Translation Example
H.323 E164: “ ” 
H.323 H323Id: 
SIP and H.323 ENUM Support
Phone#  URL “ e164.arpa”
H.323 holds the address as several ASN.1 fields while SIP puts it all
In ascii delimited.
In the common format types the translation is simple.
e.g.
SIP to H.323:
SIP – URL where user=phone or all digits will mapped to E.164
SIP (“mailto:…) - the same
Transport id – the same
H.323 to SIP:
E.164 to URL with user=phone
H.323Id of to
Id : to
URLId to
With H.323 only formats, there should be some work around.

36. Session Description Mapping - 1
H.245
Very comprehensive protocol
Covers many control issues (e.g. Chair Control)
SDP
Is a media description language
Relatively limited
Lack of cross-media, inter-media constraints
SDP – Session description protocol. H.245 include folow control, chair control (who master the control)
H.245 call control. H.245 is much advanced than SDP and hence :
SDP to H.245 – easy
H.245 to SDP – complicated / impossible.
Example : Not mapped example.

37. Session Description Mapping - 2
SDP to H.245
SDP message can easily be mapped to H.245
Straightforward
H.245 to SDP
H.245 message to one or more SDP messages
Can be complicated or impossible under certain circumstances
SDP – Session description protocol. H.245 include folow control, chair control (who master the control)
H.245 call control. H.245 is much advanced than SDP and hence :
SDP to H.245 – easy
H.245 to SDP – complicated / impossible.
Example : Not mapped example.

38. Thank You