Hi,
I think that the preparedness for early media is based on the fact that
the media may arrive before the Connect or Progress to which it relates.
These signalling messages come over a reliable channel (and may contain
the Fast Start) and may be delayed by retransmission requirements, whilst
the media may drop a few packets but still arrive.
Local Ringback should be applied on receipt of Alerting, whilst remote
media should be applied on receipt of an Inband indication (tones,
announcements, silence, ...). These situations are pretty clear, but what
happens in the other cases: media on its own, Alerting with media? I've
often wondered.
It probably depends on your capabilities. Does the MGC know from the MG
that you are receiving media, does it have any power (or is it silence),
can it mix it with local ringback, can it not mix it?
Some of it may have to be left to "Implementation Defined", but
guidelines as to what *should* happen would be nice.
Douglas
At 23:36 27/04/2002 -0400, Paul E. Jones wrote:
>>>>
ArialErnst,
ArialI think the key is "prepared to receive."
The endpoint may be prepared to receive, but it will not necessarily
play the streams.
ArialMy 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
ArialHowever, 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.
ArialWhatever 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.
ArialPaul
----- Original Message -----
From: <Horvath Ernst
To:
<ITU-SG16@echo.jf.INTEL.COM
Sent: Friday, April 26, 2002 7:40 AM
Subject: "Early media" with fast connect
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
<<<<<<<<