[standards-jig] Re:H.323 vs SIP for Jabber

Ulrich Staudinger chicago5 at gmx.de
Fri Jan 24 23:38:55 UTC 2003


Hi,

> Anybody know where we can find industry standardized codecs for voice
> compression?
a good start point:
http://directory.google.com/Top/Computers/Data_Formats/Audio/?il=1

the answer depends on your type of connection, connection parameters, etc.
For different use cases, different codecs serve better. 

For low bandwidth connections propably use of GSM makes sense, for stronger
machines and even higher bandwidth MP3 encoding suites even better. afaik ogg
vorbis librarys exist as well, available as open source, rtp en-/decoding
librarys are available for java from java.sun.com. 

Enigma3 uses no compression at all, but transmits the voice from P2P in
8000hz, mono, 4bit, which  results in 15.6k/sec. For session negotiation the
enigma handshake is used (i can't quote my xml code here, i don't know my prot by
heart ... ;))

However, i think jabber should not try to serve as an session negotiator
through all levels of the communication (as SIP or H323) but should instead just
be used for exchanging elementary aspects of media sessions, like IP's,
ports and so on. 

- Ulrich



> 
> Vapor
> ----- Original Message -----
> From: "Jean-Louis Seguineau/EXC/TEC" <jean-louis.seguineau at antepo.com>
> To: <standards-jig at jabber.org>
> Sent: Friday, January 24, 2003 3:26 PM
> Subject: [standards-jig] Re:H.323 vs SIP for Jabber
> 
> 
> > Hi,
> >
> > Allow me to somehow temper the comparizon you have made between H323 and
> > SIP. They were intended to both be signaling protocols, but H323 has got
> > things a little bit mixed up as it also standardize the transport.


> >
> > The H.323 standard allow transfer of multimedia streams over packet
> > networks. It is a descriptive standard and applies only to multimedia
> > communication, which include voice. It runs over a large number of
> packet
> > infrastructure which include among others IP, Frame Relay or ATM.
> > It was originally developed as an adaptation of H.320, which
> > addresses videoconferencing over ISDN and other circuit switched
> networks
> > and services. Since H.320 was ratified, H.323 has evolved beyond a
> logical
> > and necessary extension of the H.320 standard to include Corporate
> Intranets
> > and packet-switched networks generally. H.323 utilizes the Real-Time
> > Protocol (RTP/RTCP) from the IETF, along with internationally
> standardized
> > codecs. Since version 2, H.323 is also being used for video and other
> > communications, over the Internet.
> >
> > In common with the other ITU multimedia teleconferencing standard, H.323
> > applies to multipoint and point-to-point sessions. H323 is only a
> > description standard that include a large number of other specialized
> > standards, such as
> >
> > H.225.0      Specifies messages for call control including signaling,
> > registration
> > and admissions, and packetization/ synchronization of media streams
> > H.245  Specifies messages for opening and closing channels for media
> > streams,
> > and other commands, requests and indications.
> > H.450.x     Series of Suplimentary service recommendations. Defines
> > signalling and
> > procedures used to provide these telephony-like services
> > H.235     Defines the security framework used to provide authentication,
> > encryption and integrity to H.323 systems
> > H.332     Provides large scale, or loosely-coupled conferencing based
> upon
> > H.323.
> > H.261     Video codec for audiovisual services at P x 64 Kbps.
> > H.263     Specifies a new video codec for video over POTS.
> > G.711     Audio codec, 3.1 KHz at 48, 56, and 64 Kbps (normal
> telephony).
> > G.722     Audio Codec, 7 KHz at 48, 56, and 64 Kbps.
> > G.723     Audio Codec, for 5.3 and 6.3 Kbps modes
> > G.728     Audio Codec, 3.1 KHz at 16 Kbps.
> > G.729     Audio Codec, 8 kbps audio codec.
> >
> > So comming back to your statement
> > > H.323
> > >  Pros:
> > >  Very Generalized And Fexible
> > >  Allows for Voice, Video and many other possible facets
> > >  Specifies Multipoint Control Unit protocols for Bridging or =
> > > Conferencing
> > >  Specifies interfacing with many other carrier methods outside of
> TCP/IP
> > >  Large Industry Support
> >
> > H323 is as you said blotted, not flexible at all, as everybody can plug
> > anything (messy does not mean flexible :) In addition, its
> implementations
> > are often proprietary, and the interconection with different carriers
> > somewhat ectic. The industry support comes from the fact that many
> > manufacturer made the same mistake...
> >
> > On the othe hand, SIP as it names implies was originaly intended to
> > establish communication session between to party. It does not provides
> any
> > transport mechanism for an undelying communication media. It just allow
> the
> > party to agree on a communication. But the actual media transport will
> need
> > to be carried out by a dedicated transport such as RTP, or any streaming
> > media protocol.
> > SIP is only handling the call establishement part in a VOIP call, the
> call
> > itself runs on a separate stream. In short, SIP never transport any VOIP
> by
> > itself but negotiate the establishement of a RTP session to carry VOIP.
> >
> > This is where SIP is better that H323.
> >
> > I would therefore rephrase a little your statement
> > > SIP
> > >  Pros:
> > >  Very Specific in that it was designed to directly address Voice over
> IP
> > >  Maximizes available bandwidth by keeping its messages lean and to the
> =
> > > point
> > >  Smaller System Footprint - More focused allowing for less code
> required
> =
> > > in its libraries
> > >  Light Weight - can process more call ser second than H.323
> > >  extensible
> > >
> > >  Cons:
> > >  Limited by its very nature to only voice communications
> > > =20
> >
> > SIP is flexible as it can address many signaling needs beyond VOIP. It
> is
> > efficient, but it does not transport the voice that need to use another
> > streaming protocol (No VOIP packets are ever transported in SIP packet)
> > It has q wide acceptance in the industry, and there are a large number
> of
> > good qulity libraries around. But once again, there is no free VOIP
> > streaming libraries available.
> >
> > But maybe we could come back to the underlying reason for the
> comparizon.
> It
> > is impossible to actually use Jabber XMPP to transport VOIP, due to
> several
> > performance issues that will arise(network latency, no guaranted quality
> of
> > service, etc...)
> > But it is possible to use XMPP as a way to negotiate a VOIP session
> between
> > two voice enabled client. It would be for example possible to use the
> > jabber:iq:oob with a specific syntax, then the client would have to
> start
> > some streaming protocol between themselves to actually carry the VOIP
> call.
> >
> > Hope it helps clarify the subject
> >
> > --jean-louis
> >
> > ----- Original Message -----
> > > Message: 2
> > > From: "Vapor" <vapor at 66oc.org>
> > > To: <standards-jig at jabber.org>
> > > Date: Thu, 23 Jan 2003 22:19:13 -0600
> > > Subject: [standards-jig] H.323 vs SIP for Jabber
> > > Reply-To: standards-jig at jabber.org
> > >
> > > This is a multi-part message in MIME format.
> > >
> > > ------=_NextPart_000_0059_01C2C32D.75C42A50
> > > Content-Type: text/plain;
> > > charset="iso-8859-1"
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > I have been doing some research on VoIP and as far as I can see, it
> all
> =
> > > seems to come down to H.323 vs SIP.  H.323 I believe has entered
> version
> =
> > > 4 if I am correct and I am not exactly familiar with the differences =
> > > between each version but as far as I can see SIP seems to fit with =
> > > Jabber more that H.323.
> > >
> > > Here is a brief Comparison I have made followed by a link to a pdf
> that
> =
> > > I found very useful in identifying the differences between the two.
> > >
> > > H.323
> > >  Pros:
> > >  Very Generalized And Fexible
> > >  Allows for Voice, Video and many other possible facets
> > >  Specifies Multipoint Control Unit protocols for Bridging or =
> > > Conferencing
> > >  Specifies interfacing with many other carrier methods outside of
> TCP/IP
> > >  Large Industry Support
> > >
> > >  Cons:
> > >  Bloated - Desires to Address Everything, including little obscure =
> > > protocols that may have no Relevance to Jabber
> > >  Noisy - Can cause lots of uncessesary traffic on a network
> > >  Large System Footprint - Because of its extreme generalization, it =
> > > requires rather large libraries to implement it properly.
> > >  Overly Complex
> > >  Requires gatekeepers to manage calls
> > >  Difficult to troubleshoot due to its complexity
> > >
> > >
> > > SIP
> > >  Pros:
> > >  Very Specific in that it was designed to directly address Voice over
> IP
> > >  Maximizes available bandwidth by keeping its messages lean and to the
> =
> > > point
> > >  Smaller System Footprint - More focused allowing for less code
> required
> =
> > > in its libraries
> > >  Light Weight - can process more call ser second than H.323
> > >  extensible
> > >
> > >  Cons:
> > >  Limited by its very nature to only voice communications
> > > =20
> > > http://www.sipcenter.com/files/Wind_River_SIP_H323.pdf
> > >
> > > I am still researching but so far it looks to me that if Jabber were
> to
> =
> > > adopt a single standard for clients to use for VoIP integration that
> SIP
> =
> > > should probably be it.  And with the development of XMPP over SIP,
> this
> =
> > > makes the choice even more logical. =20
> > >
> > > Again, I am not proposing that we should integrate SIP and VoIP into
> the
> =
> > > Jabber server, but if the Jabber Software Foundation were to adopt a =
> > > single VoIP protocol as its recommended standard for implementing
> voice,
> =
> > > that VoIP actually begin to creep its way into more clients than just
> =
> > > Enigma 3.
> > >
> > > I am still looking for some suitable open source implementations of
> SIP
> =
> > > servers to recommend to Jabber server administators that want to offer
> =
> > > SIP and I do thing there may need to be some way for the Jabber server
> =
> > > to inform that client where the SIP server is.  This may just need to
> be
> =
> > > a transport or component of some sort.
> > >
> > > Vapor
> > > ------=_NextPart_000_0059_01C2C32D.75C42A50
> > > Content-Type: text/html;
> > > charset="iso-8859-1"
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> > > <HTML><HEAD>
> > > <META http-equiv=3DContent-Type content=3D"text/html; =
> > > charset=3Diso-8859-1">
> > > <META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR>
> > > <STYLE></STYLE>
> > > </HEAD>
> > > <BODY bgColor=3D#ffffff>
> > > <DIV><FONT face=3DArial size=3D2>I have been doing some research on
> VoIP
> =
> > > and as far=20
> > > as I can see, it all seems to come down to H.323 vs SIP.  H.323 I
> =
> > > believe=20
> > > has entered version 4 if I am correct and I am not exactly familiar
> with
> =
> > > the=20
> > > differences between each version but as far as I can see SIP seems to
> =
> > > fit with=20
> > > Jabber more that H.323.</FONT></DIV>
> > > <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
> > > <DIV><FONT face=3DArial size=3D2>Here is a brief Comparison I have
> made
> =
> > > followed by=20
> > > a link to a pdf that I found very useful in identifying the
> differences
> =
> > > between=20
> > > the two.</FONT></DIV>
> > > <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
> > > <DIV><FONT face=3DArial size=3D2>H.323<BR> Pros:<BR> Very =
> > > Generalized And=20
> > > Fexible<BR> Allows for Voice, Video and many other possible=20
> > > facets<BR> Specifies Multipoint Control Unit protocols for
> Bridging
> =
> > > or=20
> > > Conferencing<BR> Specifies interfacing with many other carrier =
> > > methods=20
> > > outside of TCP/IP<BR> Large Industry Support</FONT></DIV>
> > > <DIV> </DIV>
> > > <DIV><FONT face=3DArial size=3D2> Cons:<BR> Bloated -
> Desires
> =
> > > to Address=20
> > > Everything, including little obscure protocols that may have no =
> > > Relevance to=20
> > > Jabber<BR> Noisy - Can cause lots of uncessesary traffic on a=20
> > > network<BR> Large System Footprint - Because of its extreme =
> > > generalization,=20
> > > it requires rather large libraries to implement it =
> > > properly.<BR> Overly=20
> > > Complex<BR> Requires gatekeepers to manage
> calls<BR> Difficult
> =
> > > to=20
> > > troubleshoot due to its complexity</FONT></DIV>
> > > <DIV> </DIV><FONT face=3DArial size=3D2>
> > > <DIV><BR>SIP</DIV>
> > > <DIV> Pros:<BR> Very Specific in that it was designed to =
> > > directly=20
> > > address Voice over IP<BR> Maximizes available bandwidth by
> keeping
> =
> > > its=20
> > > messages lean and to the point<BR> Smaller System Footprint -
> More
> =
> > > focused=20
> > > allowing for less code required in its libraries<BR> Light Weight
> -
> =
> > > can=20
> > > process more call ser second than H.323<BR> extensible</DIV>
> > > <DIV> </DIV>
> > > <DIV> Cons:<BR> Limited by its very nature to only voice=20
> > > communications<BR> </FONT></DIV>
> > > <DIV><FONT face=3DArial size=3D2><A=20
> > >
> href=3D"http://www.sipcenter.com/files/Wind_River_SIP_H323.pdf">http://ww=
> > > w.sipcenter.com/files/Wind_River_SIP_H323.pdf</A></FONT></DIV>
> > > <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
> > > <DIV><FONT face=3DArial size=3D2>I am still researching but so far it
> =
> > > looks to me=20
> > > that if Jabber were to adopt a single standard for clients to use for
> =
> > > VoIP=20
> > > integration that SIP should probably be it.  And with the =
> > > development of=20
> > > XMPP over SIP, this makes the choice even more logical.  =
> > > </FONT></DIV>
> > > <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
> > > <DIV><FONT face=3DArial size=3D2>Again, I am not proposing that we =
> > > should integrate=20
> > > SIP and VoIP into the Jabber server, but if the Jabber Software =
> > > Foundation were=20
> > > to adopt a single VoIP protocol as its recommended standard for =
> > > implementing=20
> > > voice, that VoIP actually begin to creep its way into more clients
> than
> =
> > > just=20
> > > Enigma 3.</FONT></DIV>
> > > <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
> > > <DIV><FONT face=3DArial size=3D2>I am still looking for some suitable
> =
> > > open source=20
> > > implementations of SIP servers to recommend to Jabber server =
> > > administators that=20
> > > want to offer SIP and I do thing there may need to be some way for the
> =
> > > Jabber=20
> > > server to inform that client where the SIP server is.  This may =
> > > just need=20
> > > to be a transport or component of some sort.</FONT></DIV>
> > > <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
> > > <DIV><FONT face=3DArial size=3D2>Vapor</FONT></DIV></BODY></HTML>
> > >
> > > ------=_NextPart_000_0059_01C2C32D.75C42A50--
> > >
> > >
> > >
> > > --__--__--
> > >
> > > Message: 3
> > > Date: Fri, 24 Jan 2003 08:33:36 +0100
> > > From: Jacek Konieczny <jajcus at bnet.pl>
> > > To: standards-jig at jabber.org
> > > Subject: Re: [standards-jig] H.323 vs SIP for Jabber
> > > Reply-To: standards-jig at jabber.org
> > >
> > > On Thu, Jan 23, 2003 at 10:19:13PM -0600, Vapor wrote:
> > > > SIP
> > > >  Pros:
> > > >  Very Specific in that it was designed to directly address Voice
> over
> IP
> > > >  Maximizes available bandwidth by keeping its messages lean and to
> the
> > point
> > > >  Smaller System Footprint - More focused allowing for less code
> required
> > in its
> > > > libraries
> > > >  Light Weight - can process more call ser second than H.323
> > > >  extensible
> > > >
> > > >  Cons:
> > > >  Limited by its very nature to only voice communications
> > > This is not true. SIP can be used to initialize any session (but
> mostly
> > > multimedia sessions), and even to carry any not-session-related
> messages
> > > (eg. SIMPLE which is IM over SIP). I think SIP is much more generic
> > > then H323. But the most important thing is that SIP is much simpler
> than
> > > H323.
> > >
> > > Greets,
> > > Jacek
> > >
> > >
> > > --__--__--
> > >
> > > _______________________________________________
> > > Standards-JIG mailing list
> > > Standards-JIG at jabber.org
> > > http://mailman.jabber.org/listinfo/standards-jig
> > >
> > >
> > > End of Standards-JIG Digest
> > >
> >
> >
> > _______________________________________________
> > Standards-JIG mailing list
> > Standards-JIG at jabber.org
> > http://mailman.jabber.org/listinfo/standards-jig
> >
> 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 

-- 
Ulrich Staudinger http://www.die-horde.de http://www.igpp.de 
Product Manager @ http://complat.sourceforge.net/jnlp/ 
JID: uls at jabber.org 




More information about the Standards mailing list