Frank,
Actually, media with PI=8 (inband tones and announcements) is probably a
good thing, and I would expect it.
The intention of "prepared to receive" is because it could receive valid
media before it knows if it's associated with a connect or progress
(PI=8) so it should play it. Indeed, this will often be the case over
real networks, where RTP media is expedited ahead of regular TCP traffic.
The intention is to not clip the media.
The MG, being a "dumb" box should probably be provided with a "trigger"
to stop local ringback on receipt of first media, and/or notify the MGC
of "first media received". The MGC thus provides the logic of when, or
if, to stop the local ringback.
As for the "mediaWaitForConnect", what if there never will be a Connect?
I assume that an announcement server, which sends Progress(PI=8) and
plays media, will send media without sending Connect. The receiving
endpoint should play it. The normal thing would be to establish media in
the backward direction before sending Setup, so media would be played,
and connect the forward media direction on receipt of Connect.
Regards,
Douglas
At 11:42 02/05/2002 +0200, frank.derks(a)PHILIPS.COM wrote:
>>>>
<fontfamily><param>Courier</param>Ernst,</fontfamily>
<fontfamily><param>Courier</param>obviously, conflict situations could
arise if both a Progress indicator #1 or #8, in</fontfamily>
<fontfamily><param>Courier</param>combination with actual media being
transmitted by the called endpoint would occur, </fontfamily>
<fontfamily><param>Courier</param>but this does not seem to be a likely
event. </fontfamily>
<fontfamily><param>Courier</param>The fact the calling endpoint "must be
prepared to receive media" is not the same</fontfamily>
<fontfamily><param>Courier</param>thing as "expecting to receive media".
You have a valid point, though, that at some</fontfamily>
<fontfamily><param>Courier</param>stage a switch-over from locally
provided media to the media provided by the called</fontfamily>
<fontfamily><param>Courier</param>endpoint must occur. When this occurs
is governed by the Progress indicator and the</fontfamily>
<fontfamily><param>Courier</param>mediaWaitForConnect.</fontfamily>
<fontfamily><param>Courier</param>Regards,</fontfamily>
<fontfamily><param>Courier</param>Frank
</fontfamily>
<fontfamily><param>Courier</param>Dear experts,
there seems to be a possible conflict with early media during call
establishment using fast connect. </fontfamily>
<fontfamily><param>Courier</param>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.</fontfamily>
<fontfamily><param>Courier</param>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?</fontfamily>
<fontfamily><param>Courier</param>I would like to hear your opinion or
any experience from implementations. </fontfamily>
<fontfamily><param>Courier</param>Kind Regards,
Ernst Horvath
Siemens AG
</fontfamily>
<<<<<<<<
