[Standards-JIG] Re: VoIP Jabber

[Jean-Louis Seguineau]

Well Peter, I tend to disagree with some part of your statement. I second
entirely anything that would allow re-using existing resources, and gained
experience. But I find stating that TINS is the answer a little far fetched.
TINS is a little more than transporting SDP. It's a trial at translating
SIP. And in its present form falls short in both areas.

1/ It uses an XML representation of SDP that is going nowhere in the
standard bodies. To be efficient and re-use "lots of existing standards
(SDP, RTP) and should be able to use existing libraries for a lot of this,
without having to embed an entire SIP stack in your Jabber client", I would
rather use SDP in its standardized form. That would in my opinion avoid
un-necessary translation in the process (SDP-XML to SDP then feed to the SDP
library, and vice versa)

2/ The vast majority of the SIP headers are only meaningful at the SIP proxy
level or the SIP UA level. They are of no interest to an XMPP client as they
deal with addressing, routing, timeout, redirection issues, and content type
that are only pertinent to a SIP UA.

If we want to tackle the real issue, i.e. signaling for establishing a media
communication session between two or several parties, we need take the
problem from a rational perspective. Let's take a fresh start, and define
the requirements first. After all, it would not be the first time, and I I
recall well, the community had three attempts before coming up with a common
framework for PubSub. Then I have no doubt the community will come up with
an answer for VOIP signaling as well. TINS was very useful to tell us what
NOT to do. 

Amongst the findings, we probably need to redesign the future signaling
support to use another stanza that IQ. The request/response paradigm was
probably another inheritance from SIP. We would certainly be better off
using some kind of notification framework, and message seems to me the best
envelope for it. But we are not yet there...

Best

Jean-Louis


-----Original Message-----

Message: 3
Date: Thu, 10 Feb 2005 10:47:46 -0700
From: Peter Saint-Andre <stpeter at jabber.org>
Subject: [Standards-JIG] Re: VoIP Jabber
To: standards-jig at jabber.org
Message-ID: <stpeter-5DBD86.10474610022005 at sea.gmane.org>

In article <005801c50f8a$b0cd5f80$6600a8c0 at eteach.com>,
 "Richard Dobson" <richard at dobson-i.net> wrote:

> > TINS originally specified the use of <iq/> until it was realized that
> > this would not map well to SIP usage, thus making it more difficult to
> > implement TINS-to-SIP gateways.
> 
> Sure but we can always try to work these kind of things out, using XMPP
for 
> the signaling does seem the logical step to me, no matter what way we go 
> about it, i.e. SDP or whatever. Also if we reuse as many appropriate 
> standards as we can (RTP, SDP etc) it will not be nearly as hard to 
> implement as some are making it out to be (all sorts of existing libraries

> can be used)...

Yes. TINS is basically a way to transport SDP (Session Description 
Protocol) data over XMPP. SIP also transports SDP data, so it should be 
possible to use existing SDP parsers in Jabber-based implementations. It 
should also be fairly straightforward to write a TINS-to-SIP gateway. 
The inclusion of JEP-0033 (Extended Stanza Addressing) and JEP-0131 
(Stanza Headers and Internet Metadata) information also makes it easier 
to map TINS stanzas to the headers of SIP packets. If the end result of 
the TINS negotiation is that you invoke RTP, then you're re-using lots 
of existing standards (SDP, RTP) and should be able to use existing 
libraries for a lot of this, without having to embed an entire SIP stack 
in your Jabber client.

And that seems like a Good Thing [tm].

/psa



------------------------------

_______________________________________________
Standards-JIG mailing list
Standards-JIG at jabber.org
http://mail.jabber.org/mailman/listinfo/standards-jig


End of Standards-JIG Digest, Vol 13, Issue 13
*********************************************