May 1999 - sg16-avd - lists.packetizer.com

Re: Implementer's guide corrections for third-party pause
by Santo Wiryaman 25 May '99

25 May '99

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(a)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(a)btinternet.com > ============================================= > << File: New-third-party-pause.doc >>

1 0

[Fwd: FW: Invitation to Workshop at ETSI on VoIP QoS]
by Edgar Martinez 25 May '99

25 May '99

fyi -------- Original Message -------- Subject: FW: Invitation to Workshop at ETSI on VoIP QoS Date: Tue, 25 May 1999 10:26:43 +0200 From: Susanna Kooistra <Susanna.Kooistra(a)ETSI.FR> Reply-To: Susanna Kooistra <Susanna.Kooistra(a)ETSI.FR> To: TIPHON(a)LIST.ETSI.FR -----Original Message----- From: Christian Julien Sent: Friday, May 07, 1999 8:51 AM To: 'John Horrocks'; STQ; TIPHON; Klemens Adler; Bob Braden; Scott Bradner; Mike Buckley; Brian Carpenter; Frank Derks; Francois le Faucheur; Kathleen Nichols; Joachim Pomy; Helmut Schink; Peter Scott; Philip Jepsen Subject: RE: Invitation to Workshop at ETSI on VoIP QoS Dear Colleagues, In order to put your documents (presentation, .ppt or .doc) available to everybody before the workshop a directory has been open in the FTP server STQ area at: http://docbox.etsi.org/Tech-Org/STQ/Document/stq/05-9905-SophiaAntipolis/ To provide your documents, you are kindly invited to follow instructions indicated in the "docsubmission" file attached here and to use "template" file (also attached) before downloading your contributions. With my best regards, Christian JULIEN ETSI Technical Officer Standard Making Support Tel: +33 492 94 4323 Fax: +33 493 65 4716 GSM: +33 607 54 2693 christian.julien(a)etsi.fr -----Original Message----- From: John Horrocks [mailto:Horrocks_Technology@compuserve.com] Sent: Monday, April 26, 1999 12:14 AM To: Christian Julien; STQ; TIPHON; Klemens Adler; Bob Braden; Scott Bradner; Mike Buckley; Brian Carpenter; Frank Derks; Francois le Faucheur; Kathleen Nichols; Joachim Pomy; Helmut Schink; Peter Scott; Philip Jepsen Subject: Invitation to Workshop at ETSI on VoIP QoS Dear Colleagues This is to invite you to the ETSI workshop on quality issues for voice over IP telephony arranged for 8-9 June in ETSI headquarters. The aim of theworkshop is to identify and plan the work needed to bridge the gap between routing mechanisms within IP networks and end-end quality levels. by bringing together experts from the ETSI/ITU-T and IETF cultures to exchange information, give tutorials and brainstorm on the issues that remain to be solved. This meeting is open to non-members of ETSI. I attach a copy of the programme and a file on information about accommodation and car hire. Flights are to Nice airport and ETSI is about 30km (20 miles) from the airport. There is also information on: http://www.etsi.org/meetings/ Please inform ChristianJulien (see programme) if you are planning to attend and pass this information on to any colleagues who may be interested. Best wishes John Horrocks +44 1483 797807 ETSI Speech Transmission Quality chairman

1 0

Implementer's guide corrections for third-party pause
by Pete Cordell 25 May '99

25 May '99

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(a)btinternet.com =============================================

1 0

Re: additional requirements for D.286
by Tom-PT Taylor 24 May '99

24 May '99

Looking at the hour you sent this, I can see why you look tired in the meetings. Thanks for your hard work, and thanks also to Mike. > -----Original Message----- > From: Dale L. Skran [SMTP:dskran@ASCEND.COM] > Sent: Monday, May 24, 1999 1:31 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: additional requirements for D.286 > > Tom: > > Here are the additional requirements for your TD as we discussed in the > meeting. > > See attachement. > > Dale << File: skran-comments-on-HGCP-requirments.doc >>

1 0

additional requirements for D.286
by Dale L. Skran 24 May '99

24 May '99

Tom: Here are the additional requirements for your TD as we discussed in the meeting. See attachement. Dale

1 0

for SG16 WG2 Q13/14
by Edgar Martinez 21 May '99

21 May '99

In the ITU meeting in chile information about WAP was asked. Here it is: Main page: http://www.wapforum.org/ For documents: http://www.wapforum.org/docs/technical.htm#Approved Ed

1 0

Megaco requirements
by Gunnar Hellstrom 21 May '99

21 May '99

As requested in the Q14 meeting today, I send you my comments on the Megaco requirements. 1. In Section 11. Under Analogue. Add Multimedia, there is still activity around H.324 . 2. In 11.2.11.r Web based and text based alternatives to IVR functions should be stronger promoted, if not required. This is needed by deaf, hard-of-hearing and people from other language regions. And for all of us who are tired of the tedious IVR systems. Maybe also for fax users and multimedia users. 3. How are Mobile networks connected to the model? They may need to be separately handled. Regards Gunnar Hellström ----------------------------------------------- Gunnar Hellstrom Ericsson Home Communications E-mail gunnar.hellstrom(a)omnitor.se Tel +46 751 100 501 fax +46 8 556 002 06

1 0

Arrangements Under Discussion Re Megaco and H.GCP
by Tom-PT Taylor 21 May '99

21 May '99

The details of the arrangements Scott Bradner and I have been discussing with ITU management about how to coordinate the work of Megaco and H.GCP were revealed before Scott had time to complete his consultations. I felt compelled to give full details to the people in the meeting room (a couple of hours ago), and am now passing them on to you. Scott wishes me to assure you that this will not be imposed from on high -- you can comment and your comments will be listened to. In effect, the arrangements are a non-enforceable contract on both sides, and depend on trust on both sides. Anyway, here are the proposed arrangements: 1) The IETF (Megaco) owns the requirements document, and will publish it as an informational RFC. 2) The ITU owns the protocol document, and will publish it as H.whatever. However, the IETF will also publish it as an Informational RFC to ensure that it is universally available and everyone gets a chance to comment on it. 3) This is the non-enforceable part: both organizations have to agree to the content of both documents. Glen and I will have to wrestle with the details of this -- it's definitely not going to be exactly as simple as I've stated it. Feel free to raise questions and comment. The proceedings of this week and next will be an excellent test of whether the arrangement is workable. Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 736 0961 (ESN 396-1490) FAX: same number by prior arrangement (manual answer).

1 0

Re: caller ID and implementer's guide
by Pete Cordell 20 May '99

20 May '99

Paul, Here is an attempt to generalise your paragraph to allow for multiple gatekeepers and border elements etc. Hardly Shakespeare, but hopefully it will do. "The octet-3 extension bit of calling party number IE in SETUP may be set to 0 or 1, The behavior relating to this bit and octet 3a is defined in Q.931 with the following exceptions. An unregistered EP shall set this bit to 1. A registered EP shall set this bit to 1 if the callModel component of AdmissionConfirm is set to direct or callModel is set to gatekeeperRouted and the GK is v1 or v2. A GK shall set this bit to 1 and remove octet 3a from the corresponding outgoing SETUP if "presentation allowed" is indicated and the entity to which the message is sent to is v1 or v2. A GK shall remove the calling party number IE from the corresponding outgoing SETUP if "presentation restricted" is indicated and the message is sent to a v1 or v2 entity." We will probably have to see what happens in Santiago, but I worry that, although the above approach will work, it is complex and a badly behaved implementation could invoke unexpected behaviour in other entities down the line which will make debugging installations troublesome. Using the new IE approach seems a lot safer to me as it is simpler and I can't see that a bad implementation will cause spurious faults to occur elsewhere. It is fail-safe whereas the above solution is more fail-disaster! I think there also needs to be a clear purpose/policy statement on what the feature is to be used for. Something along the lines of the following might be appropriate: "Implementers should be aware of the limitations inherent in the scheme for calling party address identification and the privacy of this information. By itself, the screening indicator provides no guarantee that the information supplied is correct, and thus needs to be used in conjunction with other mechanisms to establish its authenticity. Likewise, by itself, there is no implicit guarantee that a destination node will honour the 'Presentation Restricted' request in the calling party address field, and thus, depending on the intended use of the feature, may contravene privacy laws in certain legal jurisdictions." Pete ============================================= Pete Cordell pete.cordell(a)btinternet.com ============================================= -----Original Message----- From: Paul Long <Plong(a)SMITHMICRO.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 19 May 1999 00:40 Subject: Re: caller ID and implementer's guide >Pete, > >I like it! We can put something like this in v3: > >"The octet-3 extension bit of calling party number IE in SETUP may be set to 0 >or 1, The behavior relating to this bit and octet 3a is defined in Q.931 with >the following exceptions. An unregistered EP shall set this bit to 1. A >registered EP shall set this bit to 1 if the callModel component of >AdmissionConfirm is set to direct or callModel is set to gatekeeperRouted and >the GK is v1 or v2. A GK shall set this bit to 1 and remove octet 3a if >"presentation allowed" is indicated and the destination EP is v1 or v2. A GK >shall remove the calling party number IE if "presentation restricted" is >indicated and the destination EP is v1 or v2." > >You need to integrate the "next routing entity" stuff, because I haven't been >keeping up with it. > >Mind you, adding a new calling party number IE that allows this bit to be set >to 0, which someone suggested, would allow _all_ entities to interoperate >regardless of version. However, if we absolutely must use the existing IE, >your proposed work-around is a good compromise. > >Paul Long >Smith Micro Software, Inc. > > -----Original Message----- > From: Pete Cordell [SMTP:pete.cordell@BTINTERNET.COM] > Sent: Tuesday, May 18, 1999 4:16 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: caller ID and implementer's guide > > Dear All, > > One solution to the version number paradox might work in the >gatekeeper > routed mode. An endpoint can find out during registration and prior >to > sending SETUP the version number of the gatekeeper . Based on the >version > of the GK, an endpoint can decide whether to send presentation >restricted > information to the GK. If the remote endpoint, or the next 'routing >entity' > is also registered with the GK, it will know its the version. The GK >could > remove the IE based on this information. > > On a wider scale, this also requires such information to be included >in > Annex G. Is it? > > Pete > > ============================================= > Pete Cordell > pete.cordell(a)btinternet.com > ============================================= >

1 0

Re: caller ID and implementer's guide
by Paul Long 18 May '99

18 May '99

Pete, I like it! We can put something like this in v3: "The octet-3 extension bit of calling party number IE in SETUP may be set to 0 or 1, The behavior relating to this bit and octet 3a is defined in Q.931 with the following exceptions. An unregistered EP shall set this bit to 1. A registered EP shall set this bit to 1 if the callModel component of AdmissionConfirm is set to direct or callModel is set to gatekeeperRouted and the GK is v1 or v2. A GK shall set this bit to 1 and remove octet 3a if "presentation allowed" is indicated and the destination EP is v1 or v2. A GK shall remove the calling party number IE if "presentation restricted" is indicated and the destination EP is v1 or v2." You need to integrate the "next routing entity" stuff, because I haven't been keeping up with it. Mind you, adding a new calling party number IE that allows this bit to be set to 0, which someone suggested, would allow _all_ entities to interoperate regardless of version. However, if we absolutely must use the existing IE, your proposed work-around is a good compromise. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Pete Cordell [SMTP:pete.cordell@BTINTERNET.COM] Sent: Tuesday, May 18, 1999 4:16 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: caller ID and implementer's guide Dear All, One solution to the version number paradox might work in the gatekeeper routed mode. An endpoint can find out during registration and prior to sending SETUP the version number of the gatekeeper . Based on the version of the GK, an endpoint can decide whether to send presentation restricted information to the GK. If the remote endpoint, or the next 'routing entity' is also registered with the GK, it will know its the version. The GK could remove the IE based on this information. On a wider scale, this also requires such information to be included in Annex G. Is it? Pete ============================================= Pete Cordell pete.cordell(a)btinternet.com =============================================

1 0