<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Saint-Andre wrote:
<blockquote cite="mid43EA6526.3080106@jabber.org" type="cite">
  <pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<a class="moz-txt-link-abbreviated" href="mailto:dirk.griffioen@voipster.com">dirk.griffioen@voipster.com</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Nolan Eakins wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">Other than that, I would shy away from having two VoIP specs. If this
proposal was vastly superior, then it would be good to phase out the
lesser. That's not the case here.

- Nolan

      </pre>
    </blockquote>
    <pre wrap="">Hi Nolan,

Could you maybe elaborate a little on 'that's not the case here'? As is,
it feels like an unargumented qualification (no offense meant :-) ).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I think Nolan's point is that the Zoep document does not make a strong
argument that the Zoep approach is superior to the Jingle approach. So
in the absence of such an argument, it is not obvious that the Zoep
approach is indeed superior.

  </pre>
</blockquote>
The document was not meant to state superiority, it rather points out a
way how to do things without going into questions like these.<br>
<blockquote cite="mid43EA6526.3080106@jabber.org" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">Secondly, other than Peters remark
(<a class="moz-txt-link-freetext" href="http://mail.jabber.org/pipermail/standards-jig/2006-February/009797.html">http://mail.jabber.org/pipermail/standards-jig/2006-February/009797.html</a>):

"2. Require dual-stack clients and simply launch SIP from XMPP",

in my view Zoep is not really a dual stack client.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Well, in a sense it seems to be, because you're just sending full SIP
traffic in an XMPP wrapper, so presumably you have to hand off the SIP
messages to a SIP stack for processing.

  </pre>
</blockquote>
Yes, of course, but, using Jingle would mean handing it over to a
Jingle stack of some sort. Then, what is the difference? <br>
<br>
One good argument would be validating the payload for conformity (as
you state below) and/or security, but SIP is not unstructured or 'raw'
as you put it below: it has  a structure and can be parsed and thus
validated. Either way, doing this would take processing power and
therefore time, so maybe we can cross them out against one another?<br>
<blockquote cite="mid43EA6526.3080106@jabber.org" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">It rather separates SIP and XMPP to do what they do best:
- SIP is concerned with signalling states
- XMPP concerns the transport and routing.

(In SIP terms, I believe, this is called a 'transport' - SIP allows for
multiple transports: TCP, UDP; XMPP is merely the layer on top of which
SIP travels).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I would not say that XMPP is a "transport" in the sense that TCP or UDP
is in the OSI Model.

  </pre>
</blockquote>
Got me there, it's not OSI - but forgive me, otherwise I would have to
read through 250 pages of SIP (or ...) again; what I am advocating here
is that there is really no need for a Jingle state-machine and more; it
just seems like renventing the weel where many rolling roll, but yes a
fancy one it is <span class="moz-smiley-s1"><span> :-) </span></span><br>
<blockquote cite="mid43EA6526.3080106@jabber.org" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">In a way this this is a 2 layered approach where both layers are
transparant to each other. SIP does not care about XMPP and vice versa
(it's 'just a message' to XMPP)..

We use XMPP for all the benefits it has, but we do not bring signalling
state and other issues into the XMPP realm. A clear separation of
concern if you will. It has the added benefit of being compatible with
all existing SIP solutions available out-of-the box and further, there's
no need for a heavy duty gateway: you just remove/add the XMPP layer to
cross borders.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Part of the problem I see is that both XMPP and SIP have addressing
formats, which are different. What is the relationship between a SIP
address and an XMPP address in Zoep? Are they the same? If so, how do
you handle internationalized addresses (which XMPP supports but SIP does
not)?

  </pre>
</blockquote>
For pc2pc calls, all addressing, authentication or internationalization
would be handled by XMPP; only the signalling and subsequent states go
through the SIP stack. For pc2pstn (we call it that) the call would be
to a number, and dealt with by the SIP stack itself (wide open to
questions here).<br>
<blockquote cite="mid43EA6526.3080106@jabber.org" type="cite">
  <pre wrap="">Another issue: authentication. It's optional in SIP, required in XMPP.

Also, validated from addresses. Unsupported in SIP, required in XMPP.

In general we don't like to send raw text over XMPP. One of the reasons
certain organizations like XMPP is that they can validate all the
traffic using the XML schemas for XMPP and its extensions. Sending raw
SIP within XMPP could be seen as an effort to get around that kind of
schema checking. SIP is a wide open texty format and it's hard to know
what is really being sent across the wire.

In general I'd like to see an argument for why SIP-over-XMPP is a great
approach. What are the benefits? What do we gain? Is it more secure?
More scalable? More user-friendly? Easier to implement for developers?
(If so, why? SIP is huge, are you assuming that developers will just
make a call out to a SIP stack rather than writing a SIP implementation
of their own? What's the interaction between the XMPP stack and the SIP
stack? Etc.) Easier to deploy for admins?

  </pre>
</blockquote>
Code reuse, ease of implementation, ease of connection with 'legacy',
as secure as both XMPP and SIP are.<br>
<br>
It is not more user-friendly (the user would not know if signalling
passes gateways or not - maybe it's slower? I believe this was
mentioned at the mailing list), or more scalable (we still would need
hardware).<br>
<br>
Existing SIP stacks can be used, if they have an abstraction for the
transport - one would add an XMPP transport and presto ...<br>
<br>
The admins I don't know about, could you hint?<br>
<br>
Dirk<br>
<blockquote cite="mid43EA6526.3080106@jabber.org" type="cite">
  <pre wrap="">Peter

- --
Peter Saint-Andre
Jabber Software Foundation
<a class="moz-txt-link-freetext" href="http://www.jabber.org/people/stpeter.shtml">http://www.jabber.org/people/stpeter.shtml</a>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - <a class="moz-txt-link-freetext" href="http://enigmail.mozdev.org">http://enigmail.mozdev.org</a>

iD8DBQFD6mUlNF1RSzyt3NURApyhAKDOVNhTlAFwwh2ZwgRu2s6gOpd2WACgsnX0
OEawjFTwrX5dvBry+9g8Adg=
=rsKT
-----END PGP SIGNATURE-----
  </pre>
</blockquote>
<br>
</body>
</html>