"Early media" with fast connect
Paul E. Jones
paulej at PACKETIZER.COM
Sat Apr 27 23:36:29 EDT 2002
"Early media" with fast connectErnst,
I think the key is "prepared to receive." The endpoint may be prepared to receive, but it will not necessarily play the streams.
My assumption is that, if the endpoint is playing local ringback, it will do so until either:
1) It is told not to do so any longer
2) RTP streams arrive
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.
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.
----- Original Message -----
From: Horvath Ernst
To: ITU-SG16 at echo.jf.INTEL.COM
Sent: Friday, April 26, 2002 7:40 AM
Subject: "Early media" with fast connect
there seems to be a possible conflict with early media during call establishment using fast connect.
Clause 18.104.22.168 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 22.214.171.124, 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sg16-avd