Take Care of Vicious Virus!

[Sakae OKUBO]

John,

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
described.

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.)


Regards
Gunnar

At 05:47 PM 1999-06-10 +0200, John Segers wrote:
>Gunnar,
>
>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
>>
>> At 10:09 AM 1999-06-10 +0200, John Segers wrote:
>> >Hao,
>> >
>> >In the current MEGACO model as described in draft-01, a Termination
>> >describes the media and in-band signaling for one user, and how they are
>> >transported etc.  A Context associates all Terminations in a session and
>> >implies audio mixing if there are more than two.
>> >
>> >This idea is retained in the Santiago work.  Going to multiple media, a
>> >Termination still describes the media and in-band signaling for one
>> >user.  A Context still associates all Terminations in a session.  For
>> >multimedia sessions, the mixing/switching can no longer be implied, but
>> >will be described by means of Context properties.  If there is only
>> >audio, nothing changes in the Context.
>> >
>> >In order to allow H.320 and H.324 where multiple media are multiplexed
>> >on one or more bearers, there needs to be a distinction between
>> >TerminationID and BearerID in order to retain the concept that a
>> >Termination describes the media, in-band signaling and transport.
>> >
>> >You see, the goal was to stay close to the basic monomedia connection
>> >model for multimedia, always keeping in mind that there should be as
>> >little overhead as possible for controlling voice calls (setup,
>> >teardown, ...).  The places where you see overhead occurring in the
>> >Santiago proposal are indeed when dealing with multiple bearers for
>> >multimedia, and, as Brian Rosen pointed out, in Audits.  It seems to me
>> >that this is acceptable because these operations will occur much less
>> >frequently than the voice/fax/NAS setups.
>> >
>> >Regards,
>> >
>> >John Segers
>> >
>> >HaoHou wrote:
>> >>
>> >> Jonh,
>> >>
>> >> Thanks for your reply,
>> >>
>> >> Please see comments below.
>> >>
>> >> >
>> >> > Second, the use of Add/Subtract/Modify commands.  You are proposing to
>> >> > use Add/Subtract to add media streams to a session or delete them from
>> >> > it.  This changes the semantics of the commands drastically.  They are
>> >> > intended to perform operations on Contexts (add or remove
>> >> > Terminations).  In the Santiago proposal this semantics is maintained.
>> >> > Operations to change Termination parameters are performed using the
>> >> > Modify command.
>> >> >
>> >> > Regards,
>> >> >
>> >> > John Segers
>> >> >
>> >>
>> >> That’s why the Santiago proposal makes the Modify command awkward. ?
>> >> Suppose we have 3 bearer channels already in a Termination.
>> >> In order to release one bearer channel, we have to list both the
other two
>> >> bearer channels in the MODIFY command.
>> >> In order to add one more bearer channel, we have to list the new
>> >> bearer channel and all the existed bearer channels in the MODIFY
>> >> command.
>> >>
>> >> I don’t think the change of semantics will affect the protocol and the
>> >> implementation  too much. Instead, it will make the protocol easier to
>> >> be understood:
>> >> As long as you want to add some entities into the context or
>> termination, you
>> >> use ADD. As long as you want to sbustract some entities from the context
>> >> or termination, you use Subtract. It is a more natural way to express
the
>> >> intention
>> >> of the commands.
>> >>
>> >> Could you tell me why Santiago proposal wants to keep the old semantics
>> >> unchanged,
>> >> after the big change of the Context and Termination concept? What does
>> it gain?
>> >>
>> >> I’d rather change the semantics to meet the change of the concept.
>> >>
>> >> Best Regards,
>> >>
>> >> Hao
>> >
>> >--
>> >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
>> >
>> >
>> -------------------------------------
>> Gunnar Hellström
>>
>> Ericsson Home Systems
>>
>> Tel +46 751 100 501
>> Fax +46 8 556 002 06
>>
>> e-mail gunnar.hellstrom at omnitor.se
>> Video +46 8 556 002 05
>> -------------------------------------
>
>--
>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
>
>
-------------------------------------
Gunnar Hellström

Ericsson Home Systems

Tel +46 751 100 501
Fax +46 8 556 002 06

e-mail gunnar.hellstrom at omnitor.se
Video +46 8 556 002 05
-------------------------------------