<HTML>
<HEAD>
<TITLE>Re: [Standards-JIG] Jingle vs. Zoep</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>This is quite a long thread so I’m not sure where to jump in but I will expand on my earlier comment regarding how some protocols do it in the signaling path and why they do. I come mainly from an H.323 background with H.320, H.321, SIP thrown in for flavor. I have written both server side and client side code in these environments and have seen valid uses for both sending tones in the signaling path, as well as in the media path. In H.323 I have seen tones, or other data as one post indicates (in my case simple chat) sent in H.245 user input indication messages, or even Q.931 messages for tones.  As others have discussed tones can be also sent via RFC2833, or as in-band tones. There seems to be a little confusion in some posts over this so I’ll touch on it. RFC2833 provides a payload to send tones, other trunk signals in a RTP media stream where an in-band DTMF signal would be a digitized tone sent encoded using the codec. <BR>
<BR>
For H.245 when a connection is established the capability to send user input is confirmed in the terminalCapabilitySet so one end of the connection has an idea of what the other end can do. I have seen this used for a couple of reasons, it is predominately used when the media and the signaling follow different paths, for example signaling through a gatekeeper and media directly to the endpoints. This allows a client to signal the gatekeeper without it needing to route and process the media streams. As some have discussed it also provides a reliable delivery path so that the potential for loss doesn’t need to be mitigated by sending multiple tones, etc.<BR>
<BR>
All gateways I have worked with for H.323, SIP, PSTN understand both RFC2833 and H.245(or Q.931) messages and can bounce between them. I haven’t run into many that do it in-band within H.323 or SIP because of the issues discussed earlier in the thread regarding producing reliable tones with lower bandwidth codecs.<BR>
<BR>
My thought regarding which to support is that it would be good to support a reliable method as well as RFC2833.<BR>
<BR>
- Brian<BR>
<BR>
<BR>
On 2/15/06 6:08 PM, "dirk.griffioen@voipster.com" <dgriffioen@voipster.com> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>Jean-Louis Seguineau wrote: <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'> <BR>
No doubt these are definitively serious concerns. But in all fairness, we<BR>
are here to discuss the merits of two different approaches from a protocol<BR>
stand point. The people on the Zoep's side have been trying to bring<BR>
relevant information to the list to allow us to make an informed decision.<BR>
<BR>
  <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>Apart from this mailing list, is there a way to sum up pros and cons of both approaches?<BR>
<BR>
Should I start a wiki page and put things in a matrix of some sort? <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'> <BR>
IMHO, just stating a list of concerns is not fair, if not considered in<BR>
context, and illustrated with examples. I must be a little stupid, because I<BR>
cannot figure out how some of the 7 points may apply when taken in the<BR>
context of Zoep, sorry. <BR>
  <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>I would agree:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'> <BR>
Peter, your legitimate objections would gain greater weight and<BR>
consideration if you were to give examples of where these concerns apply in<BR>
the context of Zoep. You always advocate examples as very important, andst<BR>
will be last to deny their usefulness. Without examples, this 7 points list<BR>
will only resemble common marketing BS you can read here and there. This is<BR>
not what we want, do we?<BR>
<BR>
And may I also suggest differentiating between the p2p (XMPP only tunnel)<BR>
and the pc-pstn (XMPP/SIP/POTS gateway) context.<BR>
<BR>
P.S. I also believe this same explanation would have to be done for the<BR>
Jingle side. But we already have a framework shaping up to compare the two<BR>
technologies, don't we?<BR>
<BR>
-----Original Message-----<BR>
Message: 2<BR>
Date: Mon, 13 Feb 2006 16:35:30 -0700<BR>
From: Peter Saint-Andre <stpeter@jabber.org> <a href="mailto:stpeter@jabber.org"><mailto:stpeter@jabber.org></a> <BR>
Subject: Re: [Standards-JIG] Jingle vs. Zoep<BR>
To: Jabber protocol discussion list <standards-jig@jabber.org> <a href="mailto:standards-jig@jabber.org"><mailto:standards-jig@jabber.org></a> <BR>
Message-ID: <43F117C2.5070906@jabber.org> <a href="mailto:43F117C2.5070906@jabber.org"><mailto:43F117C2.5070906@jabber.org></a> <BR>
Content-Type: text/plain; charset="iso-8859-1"<BR>
<BR>
-----BEGIN PGP SIGNED MESSAGE-----<BR>
Hash: SHA1<BR>
<BR>
dirk.griffioen@voipster.com wrote:<BR>
<BR>
  <BR>
 <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'> <BR>
as<BR>
secure as both XMPP and SIP are.<BR>
    <BR>
          <BR>
 <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'> <BR>
SIP is secure? Authentication is OPTIONAL. From addresses are not<BR>
validated and checked. Interdomain communications ("federation") is<BR>
still a mess. Sure you can use sips: URIs (forcing TCP and TLS) but most<BR>
implementations out there will still use the old sip: URIs (UDP, no<BR>
TLS). It's like Jabber in the jabberd 1.0 days (1999-2000) when we<BR>
didn't have dialback.<BR>
<BR>
  <BR>
    <BR>
 <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'> <BR>
Does jabber then validate 'from' - in a way more than syntactically<BR>
checking if things are ok? Maybe I am missing the point, but why is this<BR>
so important? <BR>
      <BR>
 <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'> <BR>
<BR>
Makes it relatively to do the following:<BR>
<BR>
1. Send unsolicited communications.<BR>
<BR>
2. Launch deregistration attacks.<BR>
<BR>
3. Perform call flooding.<BR>
<BR>
4. Terminate calls from a third party.<BR>
<BR>
5. Hijack sessions.<BR>
<BR>
6. Perform unauthorized call transfers.<BR>
<BR>
7. Register unauthorized devices.<BR>
<BR>
And yes I consider those fairly serious.<BR>
<BR>
Peter<BR>
<BR>
<BR>
<BR>
  <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
</SPAN></FONT>
</BODY>
</HTML>