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@btinternet.com =============================================

-----Original Message----- From: Santo Wiryaman swiryaman@VIDEOSERVER.COM To: ITU-SG16@MAILBAG.INTEL.COM ITU-SG16@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@videoserver.com http://www.videoserver.com

...

-----Original Message----- From: Pete Cordell [SMTP:pete.cordell@BTINTERNET.COM] Sent: Tuesday, May 25, 1999 4:33 AM To: ITU-SG16@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@btinternet.com ============================================= << File: New-third-party-pause.doc >>