- sg16-avd - lists.packetizer.com

SG16 Q13
by Edgar Martinez [1] 28 May '99

28 May '99

Dear SG16 Q13, I am sending this out for comments. On a proposed response to SG11. -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 TIPHON & Other Stds -- http://www.cig.mot.com/~martinze/

1 0

subscribe
by Lars Balle Andersen 28 May '99

28 May '99

1 0

Assessing the Results Of Santiago
by Tom-PT Taylor 28 May '99

28 May '99

If the partnership between Megaco and Study Group 16 is to work, I need to provide you with a detailed and honest description of the implications of the Santiago results, so you can decide for yourselves whether we are moving in the right direction. The latest H.GCP draft records three changes from the current Megaco draft. One is the idea of what I will describe as the multiplane context. Another is the idea of multiplex termination classes, on the packet as well as the circuit side. The third is a list of most of the currently-known termination attributes, grouped on a per-termination, per-plane, and per-directed-media-flow basis as applicable. In addition, the idea of a syntax for termination descriptors which expresses them as a termination class (or template) ID plus a set of delta values was not recorded, but is very interesting for the way it supports either SDP or H.245 signalling between MGCs. I will explain each of these proposals in technical detail below, followed by an assessment of their implications. First, an explanation of the multiplane (AKA multimedia) context. The first part of the idea is that a single context is used to express all of the media flow connections between a given set of terminations within the same MG. Conceptually this context is equivalent to a stacked set of monomedia contexts, but frees us from the need to represent the same termination in multiple contexts and simplifies expression of lip-synch and other inter-plane relationships. Conceptually also, the context provides one bridge/mixer for each plane it contains, and the mode of bridge operation/mixing has to be specified for each plane. The planeID can be an optional parameter, and can certainly be omitted in the simple audio case. Similarly the mixing type can be omitted in the simple audio case, as it is in the current Megaco draft. For each termination in a multiplane context, the following has to be specified in the most general case: * the base termination attributes (which are by definition independent of the media flows that termination currently supports) * attributes which are needed to describe it in each plane in which it participates, but which are common to both directions of media flow * attributes which are unique to a particular direction of media flow within a given plane. In the simple audio case this degenerates into the current organization of common attributes (TerminalState) plus per-flow-direction attributes (LTDescriptor and RTDescriptor). The positive aspect of the multiplane context is that this offers a marvellously flexible tool for expressing pretty well anything we need to, regarding multipoint, multimedia conferencing within a single MG. It has benefits even if we are talking only about audio: I could describe to you how to apply it to support a main conference plus side-conferences between subsets of participants, all within a single context. The negative aspect of this proposal is that it forces, even in the audio case, at least a minor rearrangement of termination attributes. In particular, for multiplane contexts to be effective, the send-receive aspect has to be extracted from the current Mode parameter and stated on a per-plane rather than a per-termination basis. Moreover, the current breakout of terminal descriptors in our commands into terminal state, LTDescriptor, and RTDescriptor parts has to be augmented (for conciseness) by a planeDescriptor part. This is not essential: the planeDescriptor could also be distributed into both the LTDescriptor and the RTDescriptor parts. Next, the idea of multiplex termination classes has already been described in previous discussions of H.320 operation. The basic idea as developed in Santiago is that the termination descriptor includes a multiplex type attribute. For a circuit-side multiplex, the common terminal parameter set includes a list of the individual circuits included in the multiplex. The idea of packet-side multiplexes was introduced for two reasons: to provide a simple and implicit way to indicate synchronization requirements between media flows relating to the same user, and to accommodate the need for control channel interworking in the H.320-to-H.323 case. The syntax for relating individual packet streams to the multiplex of which they are a part is natural and implicit in the listing of per-directed-media-flow components of the multiplex termination description. With the control channels comes the need for unique event packages to support them. As already stated, the idea of multiplex termination classes on both the packet and the circuit side solves the H.320/H.324 multilink problem. It also allows all media flows relating to a given user session to be grouped in a natural way so that relationships such as lip-synch can be easily expressed. further, it provides a way to relate an H.245 control channel terminating in the MG (because of interworking with H.320/H.324) to the video flows for which that channel will carry commands and indications. The negative side of this must be the need to extend our repertoire of termination classes and attributes -- not, I believe, a significant consideration in our decision to adopt the idea, since support of the mechanism is not required for simple audio operation. The tabulation of individual termination attributes and their grouping on a per-termination, per-plane, and per-directed-media-flow basis is the scariest part of the whole exercise. I will provide that tabulation in a separate message. The positive aspects of this work are that it detaches the discussion of termination attribute syntax from the H.245/SDP debate, and it allows a careful analysis of how we have to organize the content of our protocol. It also provides a starting point for rapid development of the detailed description of termination classes, to the extent that the descriptions in the current Megaco draft need to be fleshed out. The negative aspect is that it puts the current description of command parameters into jeopardy and potentially sets back any parser development which has been carried out based on the "unreviewed" portion of the current Megaco draft. We also have to resist the impression that the list of attributes is now closed; it should remain extensible to accommodate the definition of new termination classes, even if the basic logical organization remains unchanged. Finally, there is the idea of using thermination classIDs to carry major amounts of information. The basic concept is that our termination classes would be and their associated classIDs would be standardized and registered. Each termination class would imply a list of attributes, ranges of values for those attributes, a list of supported event packages, and a set of default attribute values (which could include a list of which event packages are active upon instantiation of a member of the class). Because the classes are standardized, the classID by itself can carry a lot of information between the MG and MGC. The idea of transmitting termination descriptors as the combination of a classID (which connotes a predefined attribute list and a bunch of preset default values) and a delta list of attribute values has several benefits. The most obvious is more compact expression of termination descriptors in the most common cases. Secondly, it is a means to make MG-MGC signalling independent of MGC-MGC signalling: the MGC can carry pre-coded templates in its favourite language, to which it can add the delta attribute values before sending the whole thing off to the other end. Even more radically, MGC-MGC signalling could itself carry the classIDs and deltas, but that is a topic for another discussion. The negatives of this proposal are the evident impact on command syntax in the current draft, plus the need to have a way to provide unique identification of every attribute which could appear in a delta list (including an indication of which plane and which flow direction it applies to, as applicable). Well, that's the story. Now we need a political debate on whether the relationship with SG 16 is workable based on the fruits of the meeting just concluding, and a technical debate on the merits of each of the proposals I have outlined. I'm sure you are aware that the two debates are inter-related, in that SG 16 will feel let down if we reject their proposals for grounds other than technical inadequacy (e.g. because some of us are already committed to parsers based on the current Megaco draft). I've stated the situation honestly, I hope, and I also hope that you find that good things were done in Santiago. Let the discussion begin. 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

Plea for no macros in Annex G
by Pete Cordell 27 May '99

27 May '99

Dear SG16ers, This is probably a bit late, but I was reading through Annex G and noted that there were a few macros used (principally for CryptoH323Token). These make it much harder to write a compiler. If it is still an intention to have Annex G widely accepted by making the message encoding easier, then removing the macros would help greatly to this end. I can't find a recent copy of H.235, but if memory serves me right, I feel that CryptoH323Token could be written out long hand with no loss of functionality, although the definition wouldn't be so brief. For signing messages I would propose allowing a message to contain more than one separately encoded ASN.1 chunk. The main bit would be the message, either raw or encrypted. The other optional bit would be a security definition, including signatures, and possibly key ids etc. There may also be a need for a third un-signed or plain text ASN.1 chunk to allow gatekeepers and other entities to modify message contents without invalidating any signatures. Be latedly yours, Pete ============================================= Pete Cordell pete.cordell(a)btinternet.com =============================================

1 0

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

25 May '99

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(a)btinternet.com ============================================= -----Original Message----- From: Santo Wiryaman <swiryaman(a)VIDEOSERVER.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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(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

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 20 May '99

20 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 20 May '99

20 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

cryptoH323Tokens
by Tyrone Floryanzia 18 May '99

18 May '99

Hi, Several of the RAS messages contain an optional field 'cryptotokens' which is a sequence of CryptoH323Token. My question is: since this can be a sequence of tokens and you can have several tokens of the same type, how do you distinguish between them? For instance if I had several cryptoEPPwdHash tokens in a sequence, how would I tell them apart? Or would the authenticating endpoint have to check each one? Thanks, Tyrone -- Tyrone Floryanzia | | | tfloryan(a)cisco.com | :|: :|: 7025 Kit Creek Road, P.O. Box 14987 | :|||||: :|||||: Research Triangle Park, NC 27709 | .:|||||||:.:|||||||:. 919-472-3841 fax: 919-472-2177 | c i s c o S y s t e m s

1 0

RE: Multipoint Cascading Issue!
by gmakkar＠hss.hns.com 18 May '99

18 May '99

Hi Roni, But what about H.323 MC? I wanted to understand the reason/intention for the same as it seems to be a very *intentional* decision and does not appear that something was overlooked! Thanks for the response! Regards, Gaurav Makkar Senior Technical Leader Hughes Software Systems Roni Even <Roni_e(a)ACCORD.CO.IL> on 05/18/99 11:20:23 AM Please respond to Roni Even <Roni_e(a)ACCORD.CO.IL> To: Gaurav Makkar/HSS@HSS, h323implementors(a)imtc.org, ITU-SG16(a)mailbag.cps.intel.com cc: Subject: RE: Multipoint Cascading Issue! Gaurav, I think that it is a good question. In H.320 that was the initial cascaded mode supported. In recent a version the MIH BAS code was added and a process describing multi hierarchy was defined in a tree structure similar to T.120. Roni Even ********************************************** Roni Even VP Product Marketing Accord Video Telecommunication Email: roni_e(a)accord.co.il Tel: +972-3-9251412 Fax: +972-3-9211571 *************************************************** > -----Original Message----- > From: gmakkar(a)hss.hns.com [SMTP:gmakkar@hss.hns.com] > Sent: Monday, May 17, 1999 8:57 PM > To: h323implementors(a)imtc.org; ITU-SG16(a)mailbag.cps.intel.com > Subject: Multipoint Cascading Issue! > > > > > Please refer to H.323 recommendation, clause 8.4.5, "There shall > only be > one master MC in a conference. A slave MC shall only be cascaded to a > master MC. > Slave MCs shall not be cascaded to other slave MCs. This allows only > dumb-bell > or star cascaded configurations.". > > My query is: why the above restriction? If one can have a > multi-level tree > structure in a T.120 conference, why should the above restriction be > applied to > an H.323 conference? Also, using the above, a conference (using a > single MC) can > have only 256 participants (terminal label is 8-bits). Cascading would > be > required to increase the size of the conference - again limited to > 65536 > participants (that ofcourse is large-enough for a planned conference, > if not > adopt H.332) and that too in a "wierd" star configuration. Point is > why have the > Master MCU and its network subnet be overloaded with information from > all slave > MCs - why not permit a configuration in which an MC can act as a slave > to one MC > and a master to another. That way a tree configuration for the > conference could > be built. > > Am I missing something?? I would be greatful if someone could > give some > direction on this account. > > Thanks! > > Regards, > > Gaurav Makkar > Senior Technical Leader, > Hughes Software Systems > > > ---------------------------------------------------------------------- > --- > for list subscription instructions, > send email to h323implementors-request(a)imtc.org with text "info" ------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info" ------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info"

1 0

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

18 May '99

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 ============================================= -----Original Message----- From: Paul Long <Plong(a)SMITHMICRO.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 14 May 1999 17:12 Subject: Re: caller ID and implementer's guide >Randy, > >I agree, it has gone on too long, but... :-) > >Exactly, you've made my point for me! > >1. One cannot send SETUP to a v1 or v2 EP with the octet-3 extension bit >of calling party number set to 0, because H.225.0 v1 and v2 says that it shall >be set to 1. > >2. An H.323 entity cannot know (through in-band means) the version of the >destination EP before it sends SETUP. > >3. Therefore, an entity can never send SETUP to an EP with the extension >bit set to 0 and octet 3a present. > >I don't know how to make it any clearer. Either nobody understands what I'm >saying, or they do but really really REALLY want to use octet 3a "the way God >intended it to be used" :-) regardless of whether it violates some revisions >of H.225.0 and risks breaking compliant implementations. I believe the latter >is the case, but nobody wants to admit it. > >Paul Long >Smith Micro Software, Inc. > > -----Original Message----- > From: Wuerfel, Randy P [SMTP:Randy.P.Wuerfel@ICN.SIEMENS.COM] > Sent: Friday, May 14, 1999 10:18 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: caller ID and implementer's guide > > Perhaps this discussion has gone on too long, however I just wanted to >point > out that when Paul uses the phrase "an EP cannot send a SETUP message >to a > v1 or v2 EP ...", the phrase has no meaning (at least to me). We >support > users (people!) on our H.323 system that register with a GK. The >users are > mobile, and can thus register from any EP. Thus, when I initiate a >call, my > ARQ indicates a destinationInfo alias address of a user that may at >that > moment be using any type of an EP. Since my EP doesn't attempt to >match a > transport address with an EP type (which would be a triviality >anyway), I > have no idea of the EP type (v1, v2 or in the future v3) when I send >the > Setup message. > > Don't I need an H.225.0 message returned from the destination EP >before I > can determine its type? > > Please consider the proposals that Karl Klaghofer has made to resolve >this > issue in Santiago. > > ========================================================== > Randy Wuerfel > IP/Data Networks Development > Unisphere Solutions, Inc. E-mail: > Randy.P.Wuerfel(a)icn.siemens.com > 4900 Old Ironsides Drive Fax: (408) 492-4666 > M/S 200 Tel: (408) 492-4375 > P.O. Box 58075 > Santa Clara, CA 95052-8075 > >

1 0

Re: Multipoint Cascading Issue!
by Roni Even 18 May '99

18 May '99

Gaurav, I think that it is a good question. In H.320 that was the initial cascaded mode supported. In recent a version the MIH BAS code was added and a process describing multi hierarchy was defined in a tree structure similar to T.120. Roni Even ********************************************** Roni Even VP Product Marketing Accord Video Telecommunication Email: roni_e(a)accord.co.il Tel: +972-3-9251412 Fax: +972-3-9211571 *************************************************** > -----Original Message----- > From: gmakkar(a)hss.hns.com [SMTP:gmakkar@hss.hns.com] > Sent: Monday, May 17, 1999 8:57 PM > To: h323implementors(a)imtc.org; ITU-SG16(a)mailbag.cps.intel.com > Subject: Multipoint Cascading Issue! > > > > > Please refer to H.323 recommendation, clause 8.4.5, "There shall > only be > one master MC in a conference. A slave MC shall only be cascaded to a > master MC. > Slave MCs shall not be cascaded to other slave MCs. This allows only > dumb-bell > or star cascaded configurations.". > > My query is: why the above restriction? If one can have a > multi-level tree > structure in a T.120 conference, why should the above restriction be > applied to > an H.323 conference? Also, using the above, a conference (using a > single MC) can > have only 256 participants (terminal label is 8-bits). Cascading would > be > required to increase the size of the conference - again limited to > 65536 > participants (that ofcourse is large-enough for a planned conference, > if not > adopt H.332) and that too in a "wierd" star configuration. Point is > why have the > Master MCU and its network subnet be overloaded with information from > all slave > MCs - why not permit a configuration in which an MC can act as a slave > to one MC > and a master to another. That way a tree configuration for the > conference could > be built. > > Am I missing something?? I would be greatful if someone could > give some > direction on this account. > > Thanks! > > Regards, > > Gaurav Makkar > Senior Technical Leader, > Hughes Software Systems > > > ---------------------------------------------------------------------- > --- > for list subscription instructions, > send email to h323implementors-request(a)imtc.org with text "info"

1 0

Multipoint Cascading Issue!
by Gaurav Makkar 17 May '99

17 May '99

Please refer to H.323 recommendation, clause 8.4.5, "There shall only be one master MC in a conference. A slave MC shall only be cascaded to a master MC. Slave MCs shall not be cascaded to other slave MCs. This allows only dumb-bell or star cascaded configurations.". My query is: why the above restriction? If one can have a multi-level tree structure in a T.120 conference, why should the above restriction be applied to an H.323 conference? Also, using the above, a conference (using a single MC) can have only 256 participants (terminal label is 8-bits). Cascading would be required to increase the size of the conference - again limited to 65536 participants (that ofcourse is large-enough for a planned conference, if not adopt H.332) and that too in a "wierd" star configuration. Point is why have the Master MCU and its network subnet be overloaded with information from all slave MCs - why not permit a configuration in which an MC can act as a slave to one MC and a master to another. That way a tree configuration for the conference could be built. Am I missing something?? I would be greatful if someone could give some direction on this account. Thanks! Regards, Gaurav Makkar Senior Technical Leader, Hughes Software Systems

1 0

Re: caller ID and implementer's guide
by Chris Purvis 17 May '99

17 May '99

Randy, Can one get hold of Karl's proposal without going to Santiago? I haven't seen it yet, and am keen to see what he has in mind. Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis(a)madge.com > -----Original Message----- > From: Wuerfel, Randy P [mailto:Randy.P.Wuerfel@ICN.SIEMENS.COM] > Sent: 14 May 1999 4:18 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: caller ID and implementer's guide > > > Perhaps this discussion has gone on too long, however I just > wanted to point > out that when Paul uses the phrase "an EP cannot send a SETUP > message to a > v1 or v2 EP ...", the phrase has no meaning (at least to me). > We support > users (people!) on our H.323 system that register with a GK. > The users are > mobile, and can thus register from any EP. Thus, when I > initiate a call, my > ARQ indicates a destinationInfo alias address of a user that > may at that > moment be using any type of an EP. Since my EP doesn't > attempt to match a > transport address with an EP type (which would be a > triviality anyway), I > have no idea of the EP type (v1, v2 or in the future v3) when > I send the > Setup message. > > Don't I need an H.225.0 message returned from the destination > EP before I > can determine its type? > > Please consider the proposals that Karl Klaghofer has made to > resolve this > issue in Santiago. > > ========================================================== > Randy Wuerfel > IP/Data Networks Development > Unisphere Solutions, Inc. E-mail: > Randy.P.Wuerfel(a)icn.siemens.com > 4900 Old Ironsides Drive Fax: (408) 492-4666 > M/S 200 Tel: (408) 492-4375 > P.O. Box 58075 > Santa Clara, CA 95052-8075 > > > -----Original Message----- > From: Paul Long [mailto:Plong@SMITHMICRO.COM] > Sent: Thursday, May 13, 1999 3:26 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: caller ID and implementer's guide > > Chip, > > Funny you should ask. In my first response to Glen, I said > that we clear the > call, but just a few minutes ago I took another look at the > code and found > that we completely ignore the calling party number IE in > SETUP. Skip right > over the sucker. I must have been looking at how we handle the octet-3 > extension bit for another IE, e.g., bearer capability (even > Q.931 requires > it > to always be 1). > > While it turns out that we accept a call regardless of > whether the extension > bit under discussion is set, I still stand by my assertion > that an EP cannot > send a SETUP message to a v1 or v2 EP with the extension bit > of octet 3 set > to > 0 and octet 3a present. I happen to know what my > implementation does, and > the > impact is minimal, but there are bound to be implementations out there > that--through no fault of their own--will in effect become > "broken" if we > decide that this bit can be set to 0 and this octet can be > present after > all. > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@CISCO.COM] > Sent: Thursday, May 13, 1999 3:49 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: caller ID and implementer's guide > > What does your implementation do if it receives a "0" in the > Extension > field of Octet 3? > > Chip >

1 0

Re: The Case for Multi-media Contexts
by John Segers 16 May '99

16 May '99

Brian, I read the document you posted on the megaco list and I think I have a better understanding of your approach now. This does not mean I agree with it, though. I put my comments in the word document and reformatted it to html to make sure that everybody can read it. If I didn't screw up, my comments are typeset in blue. Regards, John Segers Brian Rosen wrote: > > I was requested to write a paper in support of single media > contexts to counter the multi-media context proposals that are > around. It will be input to the SG16 meeting in Santiago next week. The > paper is attached for your interest. > > Brian > > ------------------------------------------------------------------------ > Name: The Case for Mono.doc > The Case for Mono.doc Type: Microsoft Word Document (application/msword) > Encoding: base64 -- John Segers email: jsegers(a)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

1 0

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

14 May '99

Randy, I agree, it has gone on too long, but... :-) Exactly, you've made my point for me! 1. One cannot send SETUP to a v1 or v2 EP with the octet-3 extension bit of calling party number set to 0, because H.225.0 v1 and v2 says that it shall be set to 1. 2. An H.323 entity cannot know (through in-band means) the version of the destination EP before it sends SETUP. 3. Therefore, an entity can never send SETUP to an EP with the extension bit set to 0 and octet 3a present. I don't know how to make it any clearer. Either nobody understands what I'm saying, or they do but really really REALLY want to use octet 3a "the way God intended it to be used" :-) regardless of whether it violates some revisions of H.225.0 and risks breaking compliant implementations. I believe the latter is the case, but nobody wants to admit it. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Wuerfel, Randy P [SMTP:Randy.P.Wuerfel@ICN.SIEMENS.COM] Sent: Friday, May 14, 1999 10:18 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: caller ID and implementer's guide Perhaps this discussion has gone on too long, however I just wanted to point out that when Paul uses the phrase "an EP cannot send a SETUP message to a v1 or v2 EP ...", the phrase has no meaning (at least to me). We support users (people!) on our H.323 system that register with a GK. The users are mobile, and can thus register from any EP. Thus, when I initiate a call, my ARQ indicates a destinationInfo alias address of a user that may at that moment be using any type of an EP. Since my EP doesn't attempt to match a transport address with an EP type (which would be a triviality anyway), I have no idea of the EP type (v1, v2 or in the future v3) when I send the Setup message. Don't I need an H.225.0 message returned from the destination EP before I can determine its type? Please consider the proposals that Karl Klaghofer has made to resolve this issue in Santiago. ========================================================== Randy Wuerfel IP/Data Networks Development Unisphere Solutions, Inc. E-mail: Randy.P.Wuerfel(a)icn.siemens.com 4900 Old Ironsides Drive Fax: (408) 492-4666 M/S 200 Tel: (408) 492-4375 P.O. Box 58075 Santa Clara, CA 95052-8075

2 1

Re: caller ID and implementer's guide
by Wuerfel, Randy P 14 May '99

14 May '99

Perhaps this discussion has gone on too long, however I just wanted to point out that when Paul uses the phrase "an EP cannot send a SETUP message to a v1 or v2 EP ...", the phrase has no meaning (at least to me). We support users (people!) on our H.323 system that register with a GK. The users are mobile, and can thus register from any EP. Thus, when I initiate a call, my ARQ indicates a destinationInfo alias address of a user that may at that moment be using any type of an EP. Since my EP doesn't attempt to match a transport address with an EP type (which would be a triviality anyway), I have no idea of the EP type (v1, v2 or in the future v3) when I send the Setup message. Don't I need an H.225.0 message returned from the destination EP before I can determine its type? Please consider the proposals that Karl Klaghofer has made to resolve this issue in Santiago. ========================================================== Randy Wuerfel IP/Data Networks Development Unisphere Solutions, Inc. E-mail: Randy.P.Wuerfel(a)icn.siemens.com 4900 Old Ironsides Drive Fax: (408) 492-4666 M/S 200 Tel: (408) 492-4375 P.O. Box 58075 Santa Clara, CA 95052-8075 -----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: Thursday, May 13, 1999 3:26 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: caller ID and implementer's guide Chip, Funny you should ask. In my first response to Glen, I said that we clear the call, but just a few minutes ago I took another look at the code and found that we completely ignore the calling party number IE in SETUP. Skip right over the sucker. I must have been looking at how we handle the octet-3 extension bit for another IE, e.g., bearer capability (even Q.931 requires it to always be 1). While it turns out that we accept a call regardless of whether the extension bit under discussion is set, I still stand by my assertion that an EP cannot send a SETUP message to a v1 or v2 EP with the extension bit of octet 3 set to 0 and octet 3a present. I happen to know what my implementation does, and the impact is minimal, but there are bound to be implementations out there that--through no fault of their own--will in effect become "broken" if we decide that this bit can be set to 0 and this octet can be present after all. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Chip Sharp [SMTP:chsharp@CISCO.COM] Sent: Thursday, May 13, 1999 3:49 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: caller ID and implementer's guide What does your implementation do if it receives a "0" in the Extension field of Octet 3? Chip

1 0

more documents for Chile
by Glen Freundlich 14 May '99

14 May '99

Dear Q.12-14/16 experts, I've placed these files in the Incoming directory of the pictel ftp site: H341wht8.zip - H.341 with diff-marked changes from white draft td_341_changes.doc - description of the changes to H.341 hgcptd.zip - draft H.gcp (this replaces HGCP.ZIP/doc also found there) Regards, Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0