<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>"Early media" with fast connect</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2715.400" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial>Ernst,</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>I think the key is "prepared to receive."  The 
endpoint may be prepared to receive, but it will not necessarily play the 
streams.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>My assumption is that, if the endpoint is playing local 
ringback, it will do so until either:</FONT></DIV>
<DIV><FONT face=Arial>  1) It is told not to do so any longer</FONT></DIV>
<DIV><FONT face=Arial>  2) RTP streams arrive</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>However, playing RTP streams before receiving CONNECT may 
have some implications.  Perhaps some endpoints send RTP data that contains 
no real content... thus inadvertently killing the local ringback.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Whatever the resolution, I think we need to ensure that 
local ringback happens as long as is necessary, but that we terminate once 
"real" media arrives-- we do not want to clip audio.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Paul</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=ernst.horvath@SIEMENS.COM 
  href="mailto:ernst.horvath@SIEMENS.COM">Horvath Ernst</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=ITU-SG16@echo.jf.INTEL.COM 
  href="mailto:ITU-SG16@echo.jf.INTEL.COM">ITU-SG16@echo.jf.INTEL.COM</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Friday, April 26, 2002 7:40 
AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> "Early media" with fast 
  connect</DIV>
  <DIV><BR></DIV>
  <P><FONT size=2>Dear experts,</FONT> </P>
  <P><FONT size=2>there seems to be a possible conflict with early media during 
  call establishment using fast connect. </FONT></P>
  <P><FONT size=2>Clause 8.1.7.1 of H.323 clearly says that the calling endpoint 
  must be prepared to receive media right away on the ports it indicated in 
  fastStart, and that the called endpoint may start transmitting media as soon 
  as it accepts a fastStart proposal (unless, of course, the calling endpoint 
  indicated also "mediaWaitForConnect"). This is independent of any Progress 
  indicator.</FONT></P>
  <P><FONT size=2>Clause 8.1.7.4, on the other hand, requires that the calling 
  endpoint provides tones like ringback locally if it did not receive a Progress 
  indicator #1 or #8. So the calling endpoint is obliged to interrupt/ignore 
  possible media streams from the called endpoint and replace them with its own 
  tones. Isn't this a conflict situation?</FONT></P>
  <P><FONT size=2>I would like to hear your opinion or any experience from 
  implementations. </FONT></P><BR>
  <P><FONT size=2>Kind Regards,</FONT> </P>
  <P><FONT size=2>Ernst Horvath</FONT> <BR><FONT size=2>Siemens AG</FONT> 
</P></BLOCKQUOTE></BODY></HTML>