<!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>