Implementer's guide corrections for third-party pause

[Pete Cordell]

Santo (and others),

Just to be clear, the proposed changes are replacements for paragraphs 2 and
3 of the original section.  Paragraphs 1 and 4 are meant to remain and are
unchanged!

Responding to your comments Santo,...

The text you refer to should still be there in the correction (towards the
end).  (I pulled the text from H323V2DL-final-w6.doc.  If this is not the
latest version for V2, then the edits should be made to the newer version.)

As far as the transmit side state in phase B is concerned, the H.245 channel
is established and it's waiting for a TCS from the remote end prior to doing
OLC etc.  This will be the non-empty TCS that unpauses it.  So really the
sequence is - see non-empty TCS, initialise tx state, process non-empty TCS.
(Note that the fourth paragraph of the original text - not included in the
correction - further confirms that an endpoint does not need to send TCS.)

As far as MSD is concerned, your right, it's a bit unclear whether this is a
transmit side, receive side, or both side thing (latter is probably the
closest).  Therefore, the text "...When leaving the paused state an endpoint
shall take part in master/slave determination signalling..." is meant to
mean that it performs MSD.  (I would prefer that MSD was only done if there
were a specific need to do it, - i.e. an MC's involved or bi-directional
channels are being opened - but that's an issue for another day!)  I can now
see that the text can be interpreted as saying, 'if you receive an MSD you
have to respond but otherwise you don't need to do anything with MSD'.   The
intention of the original text is more proactive than this and perhaps it
should have read "...When leaving the TRANSMITTER SIDE paused state an
endpoint shall INITIATE master/slave determination signalling...".

I hope this clears things up for you,

Pete

=============================================
Pete Cordell
pete.cordell at btinternet.com
=============================================

-----Original Message-----
From: Santo Wiryaman <swiryaman at VIDEOSERVER.COM>
To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at MAILBAG.INTEL.COM>
Date: 25 May 1999 16:05
Subject: Re: Implementer's guide corrections for third-party pause


>Hi Pete,
>The changes you proposed seem to clarify the intention of the section and
>fix the defects in the original text. There is one question that I have,
>though.
>
>In the original text, it says in the third paragraph of section 8.4.6 that
>when an EP receives a non-empty TCS in this paused state, it shall reset
its
>H.245 state to the beginning of phase B.  This implies a new exchange of
TCS
>and, more importantly, a new Master-Slave Determination cycle.
>
>A new Master-Slave Determination, I think, can be important for a situation
>where an EP (A) which was connected to another EP (B) was transfered to an
>MCU.  A might have been the master when it was talking to B, but when it is
>transfered to the MCU, the MCU should be the master.  A new MSD cycle can
>facilitate this.
>
>In the new text, what does transmitter side H.245 state in phase B (H.323
>section 8.2) mean?  Can a new MSD cycle happen when Ep receives a non empty
>TCS?
>
>Regards,
>Santo Wiryaman
>
>
>----------------------------------------
>Santo Wiryaman
>VideoServer, Inc.
>Phone:+1.781.505.2348
>  Fax:+1.781.505.2101
>email:swiryaman at videoserver.com
> http://www.videoserver.com
>
>> -----Original Message-----
>> From: Pete Cordell [SMTP:pete.cordell at BTINTERNET.COM]
>> Sent: Tuesday, May 25, 1999 4:33 AM
>> To:   ITU-SG16 at mailbag.cps.intel.com
>> Subject:      Implementer's guide corrections for third-party pause
>>
>> Dear SG16 meeting Rapporteurs and Delegates,
>>
>> As you may know, some discussion took place on the implementer's e-mail
>> list
>> about the third-party initiated pause and re-routing feature.  It emerged
>> that the description of the feature contained a few defects, and could
>> also
>> be made clearer.
>>
>> It would seem appropriate for the results of this discussion to be
>> captured
>> in the implementer's guide.  Being slightly out of the loop on these
>> issues
>> now-a-days it did not occur to me to propose such changes in the normal
>> way.
>> However, as the principle author of the original text I still feel some
>> responsibility for making the text as correct and clear as possible.
>>
>> For this reason I've included a word document below that captures the
>> resultant changes in the hope that someone, perhaps a rapporteur or the
>> implementer's guide editor, can see the changes merged into the
>> implementer's guide.
>>
>> I'm not sure what form such a contribution will take (will it be a
>> separate
>> contribution, or go straight into the proposed text for the implementer's
>> guide?) so I have included raw text without any boiler plate.
>>
>> Many thanks,
>>
>> Pete
>>
>> =============================================
>> Pete Cordell
>> pete.cordell at btinternet.com
>> =============================================
>>  << File: New-third-party-pause.doc >>
>