Welcome to SSUET PROJECTS
Final year project 2003-project # 71

H.323 versus SIP: A Comparison

Friday January 04, 1980

• Home
• About Project
• Intoduction to Vpn
•More Vpn (comming soon)
• IP Telephony
• Introduction to  VOIP-Voice Over IP
• H.323
• SIP Protocol
• More SIP
• H.323 vs SIP
• More VOIP
•  Configuration of VPN on Linux, Win 98/2000/XP Operating Systems
• Vocal server
• More Vocal Server

• FAQ's on Vpn

• FAQ's on Voip
• Tutorials & Downloads
 
H.323 versus SIP: A Comparison

This is, frankly, the best comparison of H.323 and SIP available anywhere. Virtually all of the others are misleading, out-of-date, and just plain wrong. To compound the problem--to further propagate the error, as it were--we have also seen several papers written by naive students and rank-and-file engineers that blindly parrot what they have read in these comparisons. Furthermore, many, many people have formed their opinions of H.323 and SIP based not on each protocol's merits but solely on the misinformation provided by these comparisons and through other information provided by largely the same sources.

To counter this misinformation, we decided to put together this thorough, up-to-date comparison. As with ours, please consider the financial interests of the source of any information on this subject, be it an author, speaker, institution, forum, company, web site, or conference. Are the people providing information on this issue involved in both of these--and other--protocols and have nothing besides perhaps an honest academic interest in one or the other protocol, or have they otherwise "hitched their wagon" to one?

Like everything else on the web, this is a living document which we will be updating as the standards evolve. In fact, there is much work in progress for both H.323 and SIP, but, in order to compare apples to apples and make this comparison meaningful, we have chosen to focus on what is currently defined rather than on what might be defined in the future. Also, note that commentary that is not vital to the main comparison text appears in a smaller font immediately below it.

  H.323 SIP
Philosophy H.323 was designed with a good understanding of the requirements for multimedia communication over IP networks, including audio, video, and data conferencing. It defines an entire, unified system for performing these functions, leveraging the strengths of the IETF and ITU-T protocols.

Only those features that are necessary for a particular application need to be supported. For example, a VoIP application of course does not need to support the rich video features of H.323.

SIP was designed to setup a "session" between two points. It has a loose concept of a call (that being a "session" with media streams), has no support for multimedia conferencing, and the integration of sometimes disparate standards is largely left up to each vendor.

Although SIP loosely supports conferencing via re-INVITE, it lacks all the capabilities for performing conference control, such as the ability to eject users from a conference. In addition, there are no standard tools for data collaboration (electronic whiteboard, application sharing, etc.). RFC 2543 states that "SIP is not tied to any particular conference control protocol." Read another way, SIP has no standard conference control at all.

Reliability H.323 has defined a number of features to handle failure of intermediate network entities.

For example, if a gatekeeper fails, the protocol is designed to utilize an alternate gatekeeper. If a call that is being routed through intermediate signaling entities fails, H.323 has the wherewithal to re-route the call to an operational entity so that the call is not disrupted.

SIP has not defined procedures for handling device failure.

If a SIP user agent fails, there is no means for the proxy to detect that failure except by having the proxy send INVITE messages to the device and waiting for them to timeout. Moreover, if a SIP proxy fails, the SIP user agent has no means of detecting that failure.

In addition to pre-call failure problems, there are no mechanisms within SIP to recover a call that is in progress. Of course, since SIP is the Session Initiation Protocol, this stands to reason. Nonetheless, service providers and customers alike would be very unhappy to simply lose their active calls.

Message Definition ASN.1, a standardized, extremely precise, easy-to-understand structural notation that is used by many other systems.

The message codec, or encoder and decoder, can be automatically generated directly from the original, as-published ASN.1 specification using a commercial or free ASN.1 compiler.

Whenever the specification changes, one only has to rerun the compiler to generate a new codec.

One could also implement the codec by hand.

ABNF, or Augmented Backus-Naur Form, a syntactical notation. SIP uses "an ABNF" of its own design and not a standardized ABNF such as that defined in RFC 2234.

The message codec cannot be automatically generated directly from the original, as-published ABNF specification. One must manually translate the specification to one or more grammars, such as that used by yacc/lex or antlr, (unlike most programming languages, for example, SIP does not use a context-free grammar) interspersed with user-provided code and then run the corresponding parser generator to generate the decoder. But this only works for the decoder--one must always implement the encoder by hand.

When the original ABNF specification changes, one must (again) modify the encoder by hand, manually translate the specification modifications to corresponding grammar modifications, and then run the parser generator to generate a new decoder. This is an error-prone process, and one can never be sure that the original specification has been correctly translated to the parser-generator's grammar.

As with H.323, one could also implement the codec completely by hand.

Message Encoding H.323 encodes messages in a compact binary format that is suitable for narrowband and broadband connections.

Most Internet protocols are binary, and for those that are text, there are or have been efforts to provide a binary form, e.g., HTTP and XML, so there is a concern even within these communities that text is not always appropriate.

Moreover, consider where these encodings are used. The textual encoding of control information--signalling--makes sense for protocols whose main purpose is the transmission of truly human-readable textual content, such as email or web pages, but not for pure signalling applications, such as a control protocol for voice communication, where the encoding will rarely be encountered by humans.

SIP messages are encoded in ASCII text format, suitable for humans to read. As a consequence, the messages are large and less suitable for networks where bandwidth and processing are a concern.

Some argue that message size is not so important because bandwidth is increasing. However, it is a problem because some SIP messages are getting so large that they are reaching the MTU (maximum transmission unit) of the network, risking router fragmentation. Proposals have been considered in 3GPP to perform some type of compression on the messages. While this might work, it demonstrates that there are problems with using ASCII text for high-performance communication systems.

Media Transport RTP/RTCP RTP/RTCP
Extensibility -
Vendor Specific		 H.323 is extended with non-standard features in such a way as to avoid conflicts between vendors. SIP is extended by adding new header lines that may be used by different vendors to serve different purposes, thus risking interoperability problems.

The risk is small, but this problem has already been seen in the real world with similar extension schemes.

Extensibility -
Standard		 H.323 is extended by the standards community to add new features to H.323 in such a way as to not impact existing features. However, new revisions of H.323 are published periodically, which introduce new functionality that is mandatory, yet done in such a way as to preserve backward compatibility. SIP is extended by the standards community to add new features to SIP in such a way as to not impact existing features. However, new revisions of SIP are potentially not backward compatible. In addition, several extensions are "mandatory" in some implementations, which cause interoperability problems.
Scalability -
Load Balancing		 H.323 has the ability to load balance endpoints across a number of alternate gatekeepers in order to scale a local point of presence. In addition, endpoints report their available and total capacity so that calls going to a set of gateways, for example, may be best distributed across those gateways. SIP has no notion of load balancing.

SIP currently relies mostly on DNS SRV for this. In the future, it may rely on HTTP load balancing, presumably modified to recognize SIP headers. However, when trying to build a large service-provider network, an immediate issue that arises is one wherein the ports on the gateway reach 100% utilization. With SIP, there is no way of detecting this problem. As a result, calls will simply fail.

Scalability -
Call Signaling		 When an H.323 gatekeeper is used, it may simply provide address resolution through one RAS message exchange, or it may route all call signaling traffic. In large networks, the direct call model may be used so that endpoints connect directly to one another. When using a SIP proxy to, for example, perform address resolution for the SIP device, the proxy is required to handle at least 3 full message exchanges for every call.
Scalability -
Statelessness		 An H.323 gatekeeper can be stateless using the direct call model. A SIP proxy can be stateless if it does not fork, use TCP, or use multicast.
Scalability -
Address Resolution		 H.323 defines an interface between the endpoint and the gatekeeper for address resolution. The gatekeeper may use any number of protocols to discover the destination address of the callee, including LRQs to other gatekeepers, Annex G/H.225.0, TRIP, ENUM, or DNS. The endpoint does not have to be concerned with the mechanics of this process, and the processing requirements placed on the gatekeeper from H.323 are for just a single message exchange.

Just like SIP, however, an H.323 endpoint may perform its own address resolution and then provide the resolved address to the gatekeeper as an "alias".

SIP user agents have no defined procedure for address resolution and are forced to send their INVITE message to the SIP proxy for resolution. The SIP proxy may use any number of protocols to discover the destination address of the callee, including TRIP, ENUM, or DNS. The endpoint does not have to be concerned with the mechanics of this process. Unfortunately, the processing requirements placed on the SIP proxy are higher than with H.323 because at least 3 message exchanges must take place between the SIP device, SIP proxy, and the next hop.
Addressing Flexible addressing mechanisms, including URLs and E.164 numbers.

H.323 supports these aliases:

  • E.164 dialed digits
  • generic H.323 ID
  • URL
  • transport address
  • email address
  • party number
  • mobile UIM

...as well as overlap sending.

SIP only understands URL-style addresses.
Billing Even with H.323's direct call model, the ability to successfully bill for the call is not lost because the endpoint reports to the gatekeeper the beginning and end time of the call via the RAS protocol. If the SIP proxy wants to collect billing information, it has no choice but to stay in the call signaling path for the entire duration of the call so that it can detect when the call completes. Even then, the statistics are skewed because the call signaling may have been delayed.
Call Setup A call can be established in as few as 1.5 round trips.

Setup ->
<- Connect
Ack ->

However, here is the typical message exchange with intermediate response and pre-call audio cut-through. Cut-through is accomplished in 1 round trip and call setup requires 5 messages.

Setup(mediaWaitForConnect=FALSE) ->
<- Call Proceeding
<= audio cut-through
Ack ->
...
<- Connect
Ack ->

Originally, H.323 required several messages for call setup and the use of a reliable channel, e.g., TCP. As a result, call setup took much longer than the scenarios described here. Virtually all implementations now use the Fast Connect method introduced in H.323v2, which greatly reduces the call setup delay, but few use H.323 Annex E, which allows the use of an unreliable channel, e.g., UDP, which reduces call setup to the scenarios described here.

A call can be established in as few as 1.5 round trips.

INVITE ->
<- 200 OK
Ack ->

However, here is the typical message exchange with intermediate response and pre-call audio cut-through. Cut-through is accomplished in 2 round trips and call setup requires 6 messages.

INVITE ->
<- 183 Proceeding
PRACK ->
<= audio cut-through
<- 200 PRACK
...
<- 200 OK
Ack ->

Capability Negotiation H.323 entities may exchange capabilities and negotiate which channels to open, including audio, video, and data channels. Individual channels may be opened and closed during the call without disrupting the other channels. SIP entities have no means of exchanging capabilities--they can only propose media channels, and the other entity is limited to that proposed set of channels.

It has been proposed that SIP entities could simply use re-INVITE procedures to negotiate capabilities. However, there are a number of problems with this including the potential to lose continuity of speech and the potential that the newly proposed capabilities are not supported at the other end. Most importantly, this does not allow the two ends to inform one another of their capabilities. It is a hit-or-miss procedure that leads to suboptimal performance (extended call setup time) and operation between the two entities.

Call Clearing An H.323 call is terminated in a well-defined manner. There is no question as to why the call terminated and how long the call lasted. A SIP call is terminated with a BYE message; however, the BYE message is optional so a SIP proxy or user agent may not get a clear indication of the end of the call. While this is not an issue for simple point-to-point calls which are not billable, when service providers expect to bill for those calls, this becomes much more serious.

RFC 2543 states in section 4.2.4, "A party to a call SHOULD issue a BYE request before releasing a call ("hanging up")." So an endpoint is not required to send a BYE message. This of course should be expected from a Session Initiation Protocol.

Call Forking H.323 gatekeeper can control the call signaling and may fork the call to any number of devices simultaneously. SIP proxies can control the call signaling and may fork the call to any number of devices simultaneously.
PSTN Interworking H.323 borrows from traditional PSTN protocols, e.g., Q.931, and is therefore well suited for PSTN integration. However, H.323 does not employ the PSTN's circuit-switched technology--like SIP, H.323 is completely packet-switched. How Media Gateway Controllers fit into the overall H.323 architecture is well-defined within the standard. SIP has no commonality with the PSTN and such signaling must be "shoe-horned" into SIP. SIP has no architecture that describes the decomposition of the gateway into the Media Gateway Controller and the Media Gateways.
Services Services may be provided to the endpoint through a web-browser interface using HTTP or a feature server using Megaco/H.248. In addition, services may be provided to an endpoint as it places a call, as a call arrives, or during the middle of a call by a gatekeeper or other entity that routes the call signaling. As a result, H.323 is better suited to providing new services. SIP devices can only receive service from a SIP proxy as the endpoint places a call, as a call arrives, or during the middle of a call. There is no defined way within SIP of providing services via a web browser or a feature server.

Although, as with H.323, one may provide ad-hoc services through other means, such as XML, SOAP, or CPL.

Video and Data Conferencing H.323 fully supports video and data conferencing. Procedures are in place to provide control for the conference as well as lip synchronization of audio and video streams. SIP has limited support for video and no support for data conferencing protocols like T.120. SIP has no protocol to control the conference and there is no mechanism within SIP for lip synchronization.
Administrative Requirements H.323 does not require a gatekeeper. A call can be made directly between two endpoints. SIP does not require a proxy. A call can be made directly between two user agents.
Codecs H.323 supports any codec, standardized or proprietary, not just ITU-T codecs. There have been codepoints for MPEG and GSM, which are not ITU-T codecs, in H.323 for a long time; many vendors support proprietary codecs through ASN.1 NonStandardParameters, which is equivalent to SIP's "privately-named codec by mutual agreement"; and any codec can be signaled via the GenericCapability feature that was added in H.323v3. Payload types can be specified statically or dynamically. SIP supports any IANA-registered codec (as a legacy feature) or other codec whose name is mutually agreed upon. Payload types can be specified statically or dynamically.
Firewall support Provided by H.323 proxy, an H.323/H.323 signaling gateway. Provided by SIP proxy.
Transport protocol Reliable or unreliable, e.g., TCP or UDP. Most H.323 entities use a reliable transport for signaling. Reliable or unreliable, e.g., TCP or UDP. Most SIP entities use an unreliable transport for signaling.
Loop Detection Yes, routing gatekeepers can detect loops by looking at the CallIdentifier and destinationAddress fields in call-processing messages. If the combination of these matches an existing call, it is a loop. Yes, the SIP message Via headers facilitate this.
Multicast Signaling Yes, location requests (LRQ) and auto gatekeeper discovery (GRQ). Yes, e.g., through group INVITEs.
Third-party Call Control Yes, through third-party pause and re-routing which is defined within H.323. More sophisticated control is defined by the related H.450.x series of standards. Yes, through SIP as described in separate Internet Drafts.
Minimum Ports for VoIP Call 3 (Call signaling, RTP, and RTCP.) 3 (SIP, RTP, and RTCP.)
Conferencing Entity Yes, an MC is required for this, but it could be co-located in a participating endpoint, or all endpoints could contain an MC.

What distinguishes H.323 is not that it requires yet another onerous physical entity for conferencing (it does not) but that it just has a name for this functionality, an "MC," and that it provides a flexible means of implementing that functionality.

No; however, SIP user agents perform conferencing themselves.
Original Title "VISUAL TELEPHONE SYSTEMS AND EQUIPMENT FOR LOCAL AREA NETWORKS WHICH PROVIDE A NON-GUARANTEED QUALITY OF SERVICE"

It is now, "Packet-based multimedia communications systems."

Despite the word, "VISUAL," in the original title, H.323 has never described just a videoconferencing solution--support for video and data has always been optional. And the reference to LANs may be misleading because H.323 was intended from the start to support simple and "complex topologies" and not just single-segment networks, which "LOCAL AREA NETWORKS" may imply.

"Application-level protocol for inviting users to multimedia conferences [emphasis ours]"

It is now, "SIP: Session Initiation Protocol."

Note that the "multimedia conferences" referred to in the original title are loosely coupled multicast conferences, ΰ la MBone. This is because SIP was intended to be just a point-to-point version of SAP and not the "carrier-class solution addressing a wide area" that many would have you believe.

Lineage H.323 is based on H.324, not H.320. However, H.324 was designed to be a better H.320.
  • 1990 - H.320 approved.
  • 1995 - H.324 approved.
  • 1995 - H.323 working draft circulated.
  • 1996 - H.323 approved.
  • 2000 - H.323v4 approved.

As you can see, H.323 is no more a "legacy" protocol than SIP. Both are very modern protocols.

SIP is frequently allied with the Internet and the World Wide Web by way of HTTP.
  • 1990 - WWW and HTTP described and implemented.
  • 1996 - SIP Internet Draft circulated.
  • 1999 - SIP approved.
Open-source projects Yes, e.g., OpenH323. Yes, e.g., Vovida.org.
Media Topology Unicast, multicast, star, and centralized. Unicast, multicast, star, and centralized.
Authentication Yes, via H.235. Yes, via HTTP (Digest and Basic), SSL, PGP, S/MIME, or various other means.
Encryption Yes, via H.235.

H.323, via H.235, can also use SSL for transport-layer security.

Yes, via SSL, PGP, S/MIME, or various other means.
DTMF Carriage Three ways, with the alphanumeric choice of the H.245 UserInputIndication message being the baseline carriage common to all H.323 endpoints. Three ways. There is no baseline carriage, which presents issues of interoperability.
Standards Documents for Ostensibly Equivalent Functionality

Standards that are common to both H.323 and SIP, e.g., RFC 1889, are not shown.

Core

Approved ITU-T Recommendations.

  1. Packet-based Multimedia Communications Systems (H.323)
  2. Implementers Guide for the ITU-T H.323, H.225.0, H.245, H.246, H.235, and H.450 Series Recommendations - Packet-Based Multimedia Communication Systems
  3. Call signalling protocols and media stream packetization for packet-based multimedia communication systems (H.225.0)
  4. Control Protocol for Multimedia Communication (H.245)
  5. Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN User-Network Interface Layer 3 Specification for Basic Call Control (Q.931)
  6. Usage of Cause and Location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN Part (Q.850)
  7. Information technology - ASN.1 encoding rules - Specification of Packed Encoding Rules (PER) (X.691)
  8. Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation (X.680)

Optional

Approved ITU-T Recommendations.

  1. Security and Encryption for H Series (H.323 and other H.245 based) multimedia terminals (H.235)
  2. H.323/PSTN Interworking (H.246)
  3. Supplementary Services (H.450.x)
    1. Framework
    2. Call Transfer
    3. Call Diversion
    4. Call Hold
    5. Call Park and Pickup
    6. Call Waiting
    7. Message Waiting Indication
    8. Name Identification
    9. Call Completion
    10. Call Offer
    11. Call Intrusion
    12. Common Information Additional Network Feature for H.323
  4. Guidelines for the Use of the Generic Extensibility Framework (H.460.1)
  5. Number Portability Interworking between H.323 and SCN networks (H.460.2)

Core

Approved IETF RFCs.

  1. SIP: Session Initiation Protocol (RFC 2543)
  2. SDP: session description protocol (RFC 2327)
  3. Hypertext transfer protocol -- HTTP/1.1 (RFC 2068)
  4. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies (RFC 2045)
  5. The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields (RFC 2396)
  6. Uniform Resource Locators (URL) (RFC 1738)
  7. UTF-8, a transformation format of ISO 10646 (RFC 2279)
  8. Augmented BNF for Syntax Specifications: ABNF (RFC 2234)
  9. Standard for the format of ARPA internet text messages (RFC STD 11)

Optional

Approved IETF RFCs, papers, current and elapsed IETF IDs, and other works in progress.

We know, we know! We shouldn't list all of these documents because it may look unfair to SIP, but this is actually a problem with SIP--how does one know which documents are merely interesting, required, optional, or even very important yet not quite normative?

  1. URLs for Telephone Calls (RFC 2806)
  2. Communicating Presentation Information in Internet Messages: The Content-Disposition Header (RFC 1806)
  3. HTTP authentication: Basic and digest access authentication (Work in progress)
  4. SAP: Session announcement protocol (Work in progress)
  5. The PINT Service Protocol (RFC 2848)
  6. SIP Forked Media
  7. A SIP Extension: Informational Responses to the REFER method
  8. Models for Multi Party Conferencing in SIP
  9. SIP Requirements for support of Multimedia and Video
  10. Third Party Call Control for Resource Management
  11. Using SIP for Peer-to-Peer Third-Party Call Control
  12. SIP Telephony Service Examples
  13. SIP Extensions for supporting Distributed Call State
  14. SIP Record-Route/Route Hiding
  15. Diversion Indication in SIP
  16. SIP extension for tracking locations attempted
  17. SIP for the establishment of xcast-based multiparty conferences
  18. SIP Enabled Services to Support the Hearing Impaired
  19. SCTP as a Transport for SIP
  20. Guidelines for Authors of SIP Extensions
  21. Framework for SIP Call Control Extensions
  22. Third party call control with SDP preconditions
  23. Third Party Call Control in SIP
  24. Mandating SIP Extension Support by Servers
  25. Control of Service Context using SIP Request-URI (RFC 3087)
  26. SIP Telephony Call Flow Examples
  27. Management Information Base for Session Invitation Protocol
  28. SIP Call Control: Transfer
  29. SIP 183 Session Progress Message
  30. Distributed Multipoint Conferences using SIP
  31. Reliability of Provisional Responses in SIP
  32. Providing for Multiple-Proxy Authentication of a SIP Request
  33. SIP Session Timer
  34. The SIP PROPOSE Method
  35. Transporting User Control Information in SIP REGISTER Payloads
  36. Protocol Complications with the IP Network Address Translator (NAT) (includes sections on SIP and H.323)
  37. Requirements for SIP Servers and User Agents
  38. DHCP Option for SIP Servers
  39. Finding a SIP Server With SLP
  40. SIP Caller Preferences and Callee Capabilities
  41. RFC 2976: The SIP INFO Method
  42. Mapping of ISUP Overlap Signalling to SIP
  43. Signaled Digits in SIP
  44. Mapping of ISUP parameters to SIP headers in SIP-T
  45. Providing Emergency Call Services for SIP-based Internet Telephony
  46. E.164 Resolution in SIP
  47. SIP-IN Interworking Protocol Architecture and Procedures
  48. SIP enabled IN Services - an implementation report
  49. Accessing IN services from SIP networks
  50. Ringback tones in SIP-Based Telephony
  51. SIP T.38 Call Flow Examples And Best Current Practice
  52. SIP for Telephones (SIP-T): Context and Architectures
  53. MIME media types for ISUP and QSIG Objects
  54. Interworking between SIP and INAP
  55. SIP/IN Interworking
  56. SIP INFO Method for Event Reporting
  57. ISUP to SIP Mapping
  58. Sample Uses of SIP INFO with Varying Reliability Needs
  59. ISUP parameters expected in SIP messages
  60. SIP Best Current Practice for Telephony Interworking (replaces "SIP+")
  61. Best Current Practice for ISUP to SIP mapping
  62. The SIP QSIG/MIME type
  63. Accessing IN services from SIP networks
  64. SIP PSTN Interworking Umbrella 'Require:' Header
  65. Provisional SIP Responses with Media
  66. A Functional Description of a SIP-PSTN Gateway (RFC 3050)
  67. A Proposal for Internet Call Waiting Service using SIP: An Implementation Report
  68. SDP Extensions for Fax over IP Using T.38
  69. OSP Authorization Token Header for SIP
  70. QoS and AAA Usage with SIP Based IP Communications
  71. AAA Usage for IP Telephony with QoS
  72. SIP Precedence mapping to MLPP Interworking
  73. Interdomain IP Communications with QoS, Authorization and Usage Reporting
  74. Integration of Resource Management and SIP for IP Telephony
  75. Use of SIP for the Reservation of QoS guaranteed Paths
  76. DIAMETER: Policy and Accounting Extension for SIP
  77. Framework Draft for Networked Appliances Using the Session Initiation Protocol
  78. SIP Extensions for Message Waiting Indication
  79. SIP Extensions for Presence
  80. SIP Extensions for Instant Messaging
  81. SIP Extensions for Presence Authorization
  82. A Data Format for Presence Using XML
  83. A Lightweight Presence Information Format (LPIDF)
  84. An XML Based Format for Watcher Information
  85. An XML Format for Presence Buddy Lists
  86. Event Notification in SIP
  87. Automatic Call Back Service in SIP
  88. Common Gateway Interface for SIP (RFC 3050)
  89. SIP Servlet API Extensions (ID)
  90. Root SIP Servlet (ID)
  91. SIP Servlet Delivery (ID)
  92. SIP and SOAP (ID)
  93. Java enhanced SIP (JES) (ID)
  94. The SIP Servlet API (ID)
  95. Java SIP Servlet API Specification (paper)
  96. CPL: A Language for User Control of Internet Telephony Services (ID)
  97. Transporting User Control Information in {SIP} {REGISTER} Payloads (ID)
  98. Call Processing Language Framework and Requirements (ID)
  99. 3GPP IP Multimedia CN Subsystem - Session establishment flows
  100. 3GPP IP Multimedia CN Subsystem - Registration flows
  101. Pico SIP
  102. Supporting Mobility for Multimedia with SIP
  103. Supporting Mobility for TCP with SIP
  104. Supporting Service Mobility with SIP
  105. SIP Registration
  106. Mobility Management in a SIP Environment: Requirements, Functions and Issues
  107. PHONECTL Protocol
  108. SIP Traversal through Residential and Enterprise NATs and Firewalls
  109. SIP Through NAT Enabled Firewall Call Flows
  110. Application-layer Policy Enforcement at SIP Firewalls
  111. SIP Firewall Solution
  112. Getting SIP through Firewalls and NATs
  113. A SIP Application Level Gateway for Network Address Translation
  114. DCS draft
  115. Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms
  116. SIP proxy-to-proxy extensions for supporting Distributed Call State
  117. SIP Extensions for supporting Distributed Call State
  118. SIP Extensions for Caller Privacy
  119. Integration of Call Authorization and Call Signaling for IP Telephony
  120. Integration of Resource Management and Call Signaling for IP Telephony
  121. SIP Extensions for Caller Identity and Privacy
  122. Session setup with media authorization
  123. SIP Extensions for Media Authorization
  124. Digest Authentication in SIP using RADIUS
  125. SIP Authentication using CHAP-Password

 

Contact | Jobs| Web Master | Partner sites  | Links


Copyright ©2002, 2003 ssuet projects.itgo.com All rights reserved.