[Standards-JIG] Re: VoIP Jabber

[Jean-Louis Seguineau]

Well, now we are getting somewhere...

> Not having to restandardize thousands of man-years of effort on call
> forking, call forwarding, multi-party calls, NAT traversal, etc.

I would be really very interested if you could illustrate call forking, call
forwarding and NAT traversal with flows examples using TINS. I believe
anybody on this thread would greatly benefit to look at real world examples.
I have a little understanding on how SIP does it, but I would like to
understand better a TINS approach.

> If one never has to terminate the other end of the call on the SIP
> network, sure.  However, one of the main requirements I would have for
> any technology in this space is that it is SIP-interoperable.  There
> may be other approaches that would work, and that people could
> implement more easily, but that's not what the customers I've talked
> to want.

Well, we are probably talking to the same peoples. And my perception is even
worth than yours. Those people want SIP. How frustrating what a hype can
do... But it does not mean that we have to be interoperable at any other
point than the edge of the XMPP context. And the way we implement bridges
between the XMPP world and the SIP world is what would make us different.

And it certainly does not mean that what is done inside the XMPP context has
to retain the shear complexity of the SIP syntax. What will make XMPP
successful in the long run is its ease of use and flexibility to create a
huge number of useful applications. On the other side there is more money,
and much more energy deployed to produce hundreds of drafts. Not only the
ratio of these drafts making it to the state of RFC is much lower that what
has been achieved by the XMPP WG, but the produced RFCs leave so much to
interpretation that so called standards varies from implementation to
implementation.  
In the end, this simple procrastination, the complexity of the SIP protocol,
the huge amount of work that is necessary to describe any SIP architecture
does not really make me believe those 'giants' have very broad shoulders :-)

> It's important to note that I'm talking about the SIP *semantics*
> here, not the SIP transport mechanism, or the SIP syntax. TINS gives
> you the benefit of using XMPP for what it's good at, and SIP semantics
> for what they are good at

So let's see what we can do in practice with TINS without recreating SIP,
and without copying the SIP transport or syntax. And believe me, if that
brings us simplicity of usage and speed of deployment, I'll be the first to
agree. 

Call forking, call forwarding and NAT traversal. The whiteboard is all
yours...

Best

Jean-Louis


-----Original Message-----
Joe Hildebrand hildjj at gmail.com 
Fri Feb 11 14:55:20 CST 2005
On Fri, 11 Feb 2005 19:29:16 +0100, Jean-Louis Seguineau
<jean-louis.seguineau at laposte.net> wrote:
> No offense meant, Joe. You are right; I was reading the JEP from my local
> store which is definitively out of date :)

Sorry to get snippy.  None taken.

> Apart from borrowing the SIP semantic (up and including the response code
> and multiple responses) what do we gain from using TINS?. The capability
to
> transport a SIP message on XMPP ? Well, any meaning conveyed by the
headers
> is of low interest to anything but a SIP proxy (and exactly the same that
> received the original message) or a SIP UA. So aren't we onlyt left with
the
> SDP negotiation...

Not having to restandardize thousands of man-years of effort on call
forking, call forwarding, multi-party calls, NAT traversal, etc.

Yes, for simple one-to-one calls, we could use anything to transmit
SDP across Jabber.  By the time we're done adding features, however, I
assert that we will have recreated SIP.

> If the goal is to establish and tear down a binary stream to transport
> multimedia data, then we have a generic framework with JEP-0095 which
state
> "As the Jabber protocols are extended beyond basic messaging and presence,
> the need has arisen for a generic protocol that can be used to negotiate
> content streams between any two entities. Such streams might be in-band,
but
> more likely will be out-of-band, binary streams used in applications such
as
> file transfer, voice chat, and video conferencing. This JEP provides a
> method for negotiating such streams, including meta-information about the
> intended usage of the stream."

Which is why I argued that -95 should just be TINS, but the version of
TINS we had back then was the old SDPNG version, which seemed too
hard.

> Isn't RTP just one of those binary streams used in applications such as
file
> transfer, voice chat, and video conferencing?  And isn't a SI profile
using
> SDP to establish that stream all what is needed?

If one never has to terminate the other end of the call on the SIP
network, sure.  However, one of the main requirements I would have for
any technology in this space is that it is SIP-interoperable.  There
may be other approaches that would work, and that people could
implement more easily, but that's not what the customers I've talked
to want.

aside: I'm not quite sure I understand how I got myself into being the
one arguing *for* SIP.

It's important to note that I'm talking about the SIP *semantics*
here, not the SIP transport mechanism, or the SIP syntax. TINS gives
you the benefit of using XMPP for what it's good at, and SIP semantics
for what they are good at.

> A successful XMPP signaling will need to go back to the multimedia call
> requirements (calling capabilities, multiple line support, caller ID, call
> waiting, call forwarding, call logging, call blocking, multi party
calling,
> call transfer, etc... amongst others) and go beyond a mere copy of SIP, or
> only initiating and negotiating sessions using SDP.

And yet, as I said above, if you use all of these requirements, we'll
just recreate SIP.  Why not stand on the shoulders of giants?

-- 
Joe Hildebrand