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