Fast Connect and terminating a call

frank.derks at PHILIPS.COM frank.derks at PHILIPS.COM
Thu May 2 10:19:13 EDT 2002


Ernst,

obviously, conflict situations could arise if both a Progress indicator #1
or #8, in
combination with actual media being transmitted by the called endpoint
would occur,
but this does not seem to be a likely event.

The fact the calling endpoint "must be prepared to receive media" is not
the same
thing as "expecting to receive media". You have a valid point, though,
that at some
stage a switch-over from locally provided media to the media provided by
the called
endpoint must occur. When this occurs is governed by the Progress
indicator and the
mediaWaitForConnect.

Regards,

Frank





Dear experts,
there seems to be a possible conflict with early media during call
establishment using fast connect.
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.
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?
I would like to hear your opinion or any experience from implementations.

Kind Regards,
Ernst Horvath
Siemens AG

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20020502/9c967758/attachment-0001.htm>


More information about the sg16-avd mailing list