[Standards-JIG] Re: VoIP Jabber

[Peter Saint-Andre]

For some reason, messages from Jean-Louis are not delivered to Gmane 
(though all other list messages are), so I'll reply to Joe's mail.

In article <82777bea050211090654807f93 at mail.gmail.com>,
 Joe Hildebrand <hildjj at gmail.com> wrote:

> On Fri, 11 Feb 2005 12:14:29 +0100, Jean-Louis Seguineau
> <jean-louis.seguineau at laposte.net> wrote:
> > 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.

One could equally well say that SIP is little more than transporting 
SDP, no?

> > 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)

As is obvious from http://www.jabber.org/jeps/jep-0111.html#revs and to 
anyone who has followed the mailing list all these years (see 
http://mail.jabber.org/pipermail/standards-jig/2004-March/005078.html),  
the use of SNPng was removed 11 months ago, on 2004-03-16 (Version 0.4 
of JEP-0111). Since that time the JEP has specified the use of SDP, not 
the more experimental SDPng (XML) format. This change was based on some 
implementation experience with TINS.

> > 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.

The point of including the SIP headers on the XMPP side is to translate 
appropriate parameters into a format that is usable by a SIP UA on the 
other side of a TINS-to-SIP gateway. Naturally they are less useful, or 
even unnecessary, for an XMPP client. When communications occur between 
two XMPP clients, inclusion of such headers would be unnecessary, and 
that needs to be specified more carefully in the JEP. However, when 
communicating with a SIP UA through a gateway, it might be quite useful 
to include such information for the sake of interoperability. And we all 
know that interoperability is a Good Thing [tm], right? ;-)

> > 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. 

I don't quite see anything irrational about JEP-0111.

> > 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. 

Proposals are always welcome.

> > TINS was very useful to tell us what
> > NOT to do.

Other than the use of SNPng and <iq/> (both of which were changed based 
on implementation experience), what does TINS tell us not to do? AFAICS, 
it's a little early to talk about TINS in the past tense. Naturally, 
something better might be proposed, or we might come to consensus (as we 
did with pubsub) that one of the existing proposals needs to be 
augmented.

> > Amongst the findings, we probably need to redesign the future signaling
> > support to use another stanza that IQ. 

Yes, the use of <iq/> was discovered to be problematic during 
implementation of TINS by several parties, which is why the JEP was 
changed on 2004-04-05 (Version 0.5) to use <message/>. Again, please see 
http://www.jabber.org/jeps/jep-0111.html#revs for details.

> > The request/response paradigm was
> > probably another inheritance from SIP. 

Actually, as noted, SIP semantics do not map to <iq/>, which is why 
JEP-0111 was changed to use <message/>.

> > 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...

By notification framework do you mean somethinbg like pubsub? That seems 
more than is necessary for call negotiation, setup, and teardown. I 
would say that <message/> is enough.

Peter

> > 
> > 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
> >