Questions on H.GCP applied on text telephony
jsegers at LUCENT.COM
Fri Jun 11 09:39:22 EDT 1999
I'm glad you like the idea. My intention was to have some discussion
with you and the H.GCP editor, and then post the outcome of that to the
list(s) to see what people think of it. But I guess we might as well
have our discussions on the list.
Your question was what to do on the IP side: should both streams, text
and voice, be there continuously or should they be switched. My feeling
is that they should both be there all the time. If the DS0 side has a
script attached to perform the switching without intervention of the
MGC, it would be more convenient to have the IP side ready to receive
both streams. Otherwise a change on the DS0 side (V.18 detected) would
have to result in operations on Context and IP side Termination. This
changes the idea that scripts are attached to Terminations, just like
I'd like to have the opinion of people on the MEGACO list as well, hence
the cross post.
Gunnar Hellstrom wrote:
> I like your idea of a script driven termination, and that without the
> script, the MGC gets all events and has to take all decisions.
> Could be the appropriate model rather than the "user driven multiplexor" I
> Do you then see the context on the IP side containing both streams for text
> and voice and that the modem side gets orders of what stream to feed at
> each moment. (Rather than changing the context back and forth to contain
> only the currently active IP-termination.)
> At 05:47 PM 1999-06-10 +0200, John Segers wrote:
> >It took me a while to realize that you were addressing me with your
> >question since the thread moved over from MEGACO to SG 16 list, but I
> >clued in.
> >My idea about transitioning between text and audio was slightly
> >different. I expected it would be driven by modem events. The modem
> >detects a carrier, and in the absence of any scripts, notifies the
> >controller. This then sends a command telling the Termination to change
> >its media to text. A script in the MG could also specify this behavior,
> >allowing us to get rid of the signaling to the MGC.
> >In the H.GCP document, I think there would have to be a description of
> >the text medium as a subtype of data. And in the section explaining the
> >modem parameters, there has to be a reference to V.18.
> >Does this sound reasonable?
> >Thank you for your input,
> >John Segers
> >Gunnar Hellstrom wrote:
> >> The structure you described for bearers, terminations, multiplexors,
> >> contexts etc. described seems reasonable.
> >> For a PSTN termination in text telephone mode of the highest level, where
> >> the PSTN way of alternating between voice and text is supported, I see it
> >> best described as a kind of user-driven multiplexor.
> >> When there is a carrier from the text phone, the multiplexor conveys the
> >> text stream.
> >> When the carrier ceases, the multiplexor conveys the audio stream.
> >> Text arriving from an IP termination may cause the state of the PSTN
> >> multiplexor to change from audio to text and then transmit the text in the
> >> prevailing text telephone mode.
> >> Audio coming from an IP termination while the multiplexor is in the text
> >> mode can not go through. The multiplexor stays in the text mode until the
> >> user makes the alteration. ( usually by lifting the handset and "stealing"
> >> the line from the textphone.)
> >> On the IP side, H.323 Annex G is supposed to support simultaneous audio and
> >> text. There is no need for this kind of user driven multiplexor there.
> >> -------------------------------------------------------------------------
> >> I understand that the requirements behind this description should go into
> >> section 11.2.4 of megaco requirements (D-286 of Santiago). But where in
> >> H.gcp do you want the description of parameters and functions needed in the
> >> gateway components for this functionality?
> >> Gunnar Hellström
John Segers email: jsegers at lucent.com
Lucent Technologies Room HE 306
Dept. Forward Looking Work phone: +31 35 687 4724
P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954
More information about the sg16-avd