<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: SIP beats H323?</TITLE>

<META content="MSHTML 6.00.2800.1106" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=076034120-31102003><FONT face=Arial color=#0000ff size=2>1. 
Yes, I was thinking slow start, but the generic capability</FONT></SPAN></DIV>
<DIV><SPAN class=076034120-31102003><FONT face=Arial color=#0000ff 
size=2>applies to Fast Connect too.  In Setup you typically 
propose</FONT></SPAN></DIV>
<DIV><SPAN class=076034120-31102003><FONT face=Arial color=#0000ff size=2>many 
OLCs for the receiver to choose from, eg. G729AB</FONT></SPAN></DIV>
<DIV><SPAN class=076034120-31102003><FONT face=Arial color=#0000ff size=2>and 
G729A.  Similary G711+CN and G711.  For G711+CN</FONT></SPAN></DIV>
<DIV><SPAN class=076034120-31102003><FONT face=Arial color=#0000ff size=2>you 
encode a MultiplePayloadStreamCapability in the OLC.</FONT></SPAN></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV>
<DIV><SPAN class=076034120-31102003><FONT face=Arial color=#0000ff size=2>2. 
 I disagree with your view that <FONT face="Times New Roman" 
color=#000000>it won't make any difference to</FONT><FONT color=#000000><FONT 
face="Times New Roman"><FONT size=3> <BR></FONT><FONT size=2>the performance of 
the system<SPAN class=076034120-31102003><FONT face=Arial color=#0000ff 
size=2>.  There are reasons to send 
CN.</FONT></SPAN></FONT></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=076034120-31102003><FONT size=2><FONT><FONT face=Arial 
color=#0000ff size=2><SPAN class=076034120-31102003>The ITU is taking the 
trouble to standardize it for older 
codecs.</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=076034120-31102003><FONT size=2><FONT><FONT face=Arial 
color=#0000ff size=2><SPAN class=076034120-31102003>Not 
</SPAN></FONT></FONT></FONT></SPAN><SPAN class=076034120-31102003><FONT 
size=2><FONT><FONT face=Arial color=#0000ff size=2><SPAN 
class=076034120-31102003>sending packets can cause noticeably lower voice 
quality,</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=076034120-31102003><FONT size=2><FONT><FONT face=Arial 
color=#0000ff size=2><SPAN class=076034120-31102003>depending on the 
receiver.  Sending CN and having it 
ignored</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=076034120-31102003><FONT size=2><FONT><FONT face=Arial 
color=#0000ff size=2><SPAN class=076034120-31102003>is like not sending 
packets.  It may be better to send 
audio</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=076034120-31102003><FONT size=2><FONT><FONT face=Arial 
color=#0000ff size=2><SPAN class=076034120-31102003>continuously without silence 
detection.  That's why the</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=076034120-31102003><FONT size=2><FONT><FONT face=Arial 
color=#0000ff size=2><SPAN class=076034120-31102003>transmitter wants to know 
the receiver's capability.</SPAN></FONT></FONT></FONT></SPAN></DIV>
<P><FONT face=Arial color=#000080 size=2>- tlyons@sonusnet.com +1 732 625-3003 
x212</FONT> </P>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Francois Audet 
[mailto:audet@nortelnetworks.com]<BR><B>Sent:</B> Friday, October 31, 2003 3:27 
PM<BR><B>To:</B> 'Lyons, Terry'; 
'itu-sg16@external.cisco.com'<BR><B>Subject:</B> RE: SIP beats 
H323?<BR><BR></FONT></DIV><BR>
<P><FONT size=2>> There is a more fundamental problem: the silenceSuppression 
</FONT><BR><FONT size=2>> flag in H225LogicalChannelParameters is an option 
set by the </FONT><BR><FONT size=2>> transmitter. What we need -- what H.323 
normally provides, </FONT><BR><FONT size=2>> what SIP now provides by its 
declaration of CN in SDP -- is a </FONT><BR><FONT size=2>> receiver 
CAPABILITY.</FONT> <BR><FONT size=2>></FONT> <BR><FONT size=2>> The 
decision taken in Paris 9/2003 will do just fine: add a </FONT><BR><FONT 
size=2>> new generic capability to H.245 as soon as possible.  A 
</FONT><BR><FONT size=2>> receiver can then say it supports CN; a transmitter 
can take </FONT><BR><FONT size=2>> advantage of it.</FONT> </P>
<P><FONT size=2>Ah... You are talking slowStart, and was was thinking 
fastStart.</FONT> </P>
<P><FONT size=2>Regardless, I think this is the core of the disagreement. What 
Paul </FONT><BR><FONT size=2>and I are saying is that it doesn't matter. Any 
receiver will </FONT><BR><FONT size=2>ignore the silence packet if it doesn't 
understand it</FONT> <BR><FONT size=2>and will process it properly if it does. 
So we can already</FONT> <BR><FONT size=2>take advantage of it today. And the 
silenceSuppression flag</FONT> <BR><FONT size=2>will tell the far end that it 
will send CN, in case it needs to</FONT> <BR><FONT size=2>know.</FONT> </P>
<P><FONT size=2>I'm just very sceptical people will bother using the new</FONT> 
<BR><FONT size=2>generic capability since it won't make any difference to</FONT> 
<BR><FONT size=2>the performance of the system.</FONT> </P>
<P><FONT size=2>> BTW there is a related misuse of 
H225LogicalChannelParameters </FONT><BR><FONT size=2>> for 
dynamicRTPPayloadType.  SIP gets it right, having a </FONT><BR><FONT 
size=2>> receiver declare its capability to receive specified dynamic 
</FONT><BR><FONT size=2>> payload types in the SDP it sends.  H323 
mistakenly lets the </FONT><BR><FONT size=2>> transmitter choose the dynamic 
payload type it will send.  </FONT><BR><FONT size=2>> The two don't 
interwork.</FONT> </P>
<P><FONT size=2>Correct.</FONT> </P>
<P><FONT size=2>I remember stumbling into this when I wrote the RFC2833</FONT> 
<BR><FONT size=2>additions for H.323 (which also uses dynamic payload 
types).</FONT> <BR><FONT size=2>For that particular case, we just simply only 
allowed in the</FONT> <BR><FONT size=2>procedures to negotiate the dynamic 
payload type for receiving.</FONT> <BR><FONT size=2>So dynamic payload types for 
RFC2833 should interwork.</FONT> </P>
<P><FONT size=2>Not sure how to fix it for dynamic payload types for voice 
codecs</FONT> <BR><FONT size=2>however.</FONT> </P></BODY></HTML>