- sg16-avd - lists.packetizer.com

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

11 May '99

Karl, H.225.0 is the _referencing_ Recommendation for Q.931. Therefore, H.225.0 can--and quite often does--modify aspects of Q.931. One of the many ways that H.225.0 modifies Q.931 is by requiring that the octet 3 extension bit in the calling party number IE be set to 1, which precludes the presence of octet 3a. It does not say that it _should_ or _may_ be set to 1; it says that it "_shall_ be set to '1'." Therefore, discussion of what a receiving EP shall do when the extension bit is set to 0 is kind of moot, because this bit is always set to 1 for communication between compliant EPs starting with version 1. However, we can discuss the behavior of a compliant EP in communication with a non-compliant EP which sends a SETUP with the octet 3 extension bit in the calling party number IE set to 0. Upon further consideration of your previous post, I have to agree with you that an EP shall ignore the IE and optionally send STATUS and that it clearly shall not clear the call or accept the IE but ignore octet 3a. Here's the only completely safe solution I can think of that fulfills everyone's needs, if not wants. 1) State in the Implementers Guide that the calling party number IE is only included if presentation is allowed. We don't need to say anything about not encoding octet 3a because this is already precluded. 2) Extend the H323-UU-PDU type in v3 with the following component and allow the calling party number to be placed in there. Border entities move the value between the real IE on the SCN side and this IE proxy on the H.323 side. callingPartyNumberIE OCTET STRING SIZE(2..131) OPTIONAL If present, the calling party number can be placed in either location but not both, so on the H.323 side a v3+ EP could always place the calling party number in the IE proxy or place it in the real IE if presentation is allowed. How about this solution? It's straightforward, easy to implement, maintains the integrity of H.323, doesn't set a bad precedent, and maintains interoperability among all shipping and future products. It's admittedly inelegant, but the only elegant solution is to go back in time a few years and rewrite H.225.0v1. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Karl.Klaghofer(a)ICN.SIEMENS.DE [SMTP:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: Tuesday, May 11, 1999 5:49 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: AW: caller ID and implementer's guide Paul, Chris, Glen, 1) I have to agree with Chris, the nonStandard field is not suitable to carry standardized information, due to the mentioned reasons. 2) I have thought about the alternative Chris proposed: I think to put the presentation indicator bits in a new standardized H.225.0/Setup-UUIE field to control the handling of the presentation of Calling Party Number IE contents is not "save" either, since an endpoint (not yet supporting this additional coding) would display the Calling party Number contents although the intention of the calling party was probably NOT to display it at the destination (in case of "presentation restriction" being set). 3) I did not hear any opinion on the expected error procedures in H.225.0 upon receiving optional information elements having a content error ? Again, if I follow Q.931, section 5.8.7.2 - which should be the source for H.225.0 - then a receiving endpoint not knowing the proposed "new" octet 3a in Calling Party Number IE, would find octet3/bit8 set to "0" and would (acc. to Q.931) treat this as an information element contents error of an optional information element and therefore ignore the IE but process the message. This has the advantage that no unintended display of a restricted number would take place. It has the disadvantage that if 3a is set to "presentation allowed", the number would not be displayed either. Solution: In the Implementors Guide we can say that octet 3a in H.225.0v2 shall only be set with "presentation restriction". If the presentation shall be allowed, NO octet 3a shall be sent (no octet 3a means "presentation allowed" per default). Regards, Karl

1 0

Re: Input from ATMF
by Tom-PT Taylor 11 May '99

11 May '99

This material now appears as COM16-D305. > -----Original Message----- > From: Sakae OKUBO [SMTP:okubo@GITI.OR.JP] > Sent: Monday, May 10, 1999 10:11 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Input from ATMF > > Dear Q.12-14/16 experts, > > A possible input to the SG16 meeting from ATMF > > "Gateway for H.323 Media Transport Over ATM" AF-SAA-0124.000, Final > Ballot, > May, 1999 > > has been placed at the ftp site: > > ftp://standard.pictel.com/avc-site/9905_San/af-saa-0124.000.zip > or > http://standard.pictel.com/ftp/avc-site/9905_San/af-saa-0124.000.zip > > Please note that its type of the document (liaison, Nortel Delayed > Contribution, TD, ...) is not known yet. > > Best regards, > > Sakae OKUBO (Mr.) > *********************************************************** > Waseda Research Center > Telecommunications Advancement Organization of Japan (TAO) > 5th Floor, Nishi-Waseda Bldg. > 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo > 169-0051 Japan > Tel: +81 3 5286 3830 > Fax: +81 3 5287 7287 > e-mail: okubo(a)giti.or.jp > ***********************************************************

1 0

Input from ATMF
by Sakae OKUBO 10 May '99

10 May '99

Dear Q.12-14/16 experts, A possible input to the SG16 meeting from ATMF "Gateway for H.323 Media Transport Over ATM" AF-SAA-0124.000, Final Ballot, May, 1999 has been placed at the ftp site: ftp://standard.pictel.com/avc-site/9905_San/af-saa-0124.000.zip or http://standard.pictel.com/ftp/avc-site/9905_San/af-saa-0124.000.zip Please note that its type of the document (liaison, Nortel Delayed Contribution, TD, ...) is not known yet. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

SDP and H.245 Data Structures
by Tom-PT Taylor 10 May '99

10 May '99

This message is to aid discussion of the structure of the LocalTerminationDescriptor and RemoteTerminationDescriptor components of the Add, Modify, and Move commands. In our protocol draft, the local and remote termination descriptors actually represent two directions of transmission, inwards to the MG and outwards from the MG respectively. Each requires its own media description. The two proposals for media description are to use structures modelled on the media description components of SDP (RFC 2327), or to use structures modelled on the H.245 OpenLogicalChannel (OLC) and OpenLogicalChannelAck commands. This note shows details of each structure. I start with the SDP structure. The complete set of headers in the media description is described in RFC 2327 as follows. Asterisks denote optional elements. Media description m=<media> <port> <transport> <fmt list> i=* (media title) c=* (connection information - optional if included at session-level) b=* (bandwidth information) k=* (encryption key) a=* (zero or more media attribute lines) Here is an example of an SDP media description: m=video 49232 RTP/AVP 98 i=Pictures at an exhibition c=IN IP4 134.134.157.81 a=rtpmap:98 L16/16000/2 Now here is the structure of a media description which would be consistent with the H.245 OLC and OLCAck structures. I say "consistent with" because it is structured like the OLC and OLCAck, but contains only the information which would result from their exchange. Indentation is used to show data structures within data structures. The tags used are the names of the various components in their ASN.1 description. The comments following the "--" show the mapping to SDP. H245_channel_descriptor= logicalChannelNumber= <value in range 1...65535> -- unique to H.245 dataType= <medium (implicit tag)> <codec description> -- m= and a= headers h2250LogicalChannelParameters= <non-standardized parameters> -- SDP X- extensions <RTP or T.120 sessionID> -- not settable by SDP <associated sessionID> -- (for lip synch) -- not settable by SDP <mediaChannel> -- transport address -- c= header <mediaGuaranteedDelivery> -- TRUE for TCP transport -- m= header <mediaControlChannel> -- RTCP address/port (optional) -- implicit in SDP <mediaControlGuaranteedDelivery> -- TRUE for TCP transport -- not in SDP <silenceSuppression> -- not in SDP -- part of RTP profile? <destination> -- designates final destination if connection is to MCU but stream is intended for a particular terminal -- not in SDP <RTP payload type> -- m= header, possibly augmented by a= header(s) <transportCapability> -- RSVP or ATM QOS parameters -- not in SDP -- lower-layer transport -- c= header <redundancy encoding specification> -- m= header <source> -- designates originating terminal if working through MCU -- not in SDP <logicalChannelDependency> -- which channel this one depends on if hierarchical encoding used -- implicit in SDP by order of port numbers in m= header separateStack= -- address for setting up ATM connection -- c= header -- alternatively, information for joining T.120 conference -- a= header? encryptionSynch= -- key for media encoding -- k= header One small step in the discussion ... 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: AW: caller ID and implementer's guide
by Chip Sharp 10 May '99

10 May '99

At 10:43 AM 5/7/99 +0200, Karl.Klaghofer(a)ICN.SIEMENS.DE wrote: >Glen and others, > >It was a mistake to exclude the octet 3a in H.225.0 (v1 and v2) Calling >party number IE. It has led to interoperability problems with the SCN in >the past (where octet 3a is used) ! I agree. I might be okay in an enterprise environment, but in a Service Provider environment the lack of Octet 3a makes it impossible to support the CLIP/CLIR service as defined in Q.951 in an standard manner. >Now, it is time to fix this error as discussed in the Monterey Rapporteuts >meeting in February (i.e. for H.225.0v3 but also for H.225.0v2 via >Implementors Guide !). There may be procucts already planning on that >announced correction. > >An endpoint B - not supporting octet 3a of Calling Party Number Information >element - should treat this situation as a "non-mandatory information >element content error". The reaction to such an type of error shall be: >* Take actions on the SETUP received and on all the information >elements that are recognized and have valid contents; i.e. ignore only the >Calling party Number IE >* A STATUS may optionally be returned with Cause #100. > >Refer also to Q.931 clause 5.8.7.2 (which should applicable also to H.225.0, >since H.225.0 is so much based on the Q.931). > >So, if such an endpoint B receives an octet 3a in Calling party Number set >to "presentation allowed", all that happens is that the Number would not be >displayed at B. The only problem I see is the optional STATUS message. Implementations using the STATUS message option will generate unnecessary traffic. In a low-volume environment, this shouldn't be too bad. >But for the really critical case where the octet 3a is received by such an >endpoint B being set to "presentation restrictet", we have even the behavier >we intend, namely NOT to display the number to the endpoint B (since the >whole IE should be ignored anyway). In the case of interoperating with a v1/v2 implementation that doesn't recognize Octet 3a, the receiver will drop the Information Element and, worst case, send a STATUS message. Thus, worst case is that the Calling Party Number will not be available to the receiving endpoint. This seems to be a sufficient failsafe to me. Since the SCN Gateway must implement policy anyway, it could also have a policy to act on Octet 3a differently (e.g., drop the Calling Party Number if "presentation restricted" is encoded or the digits aren't available and pass it on without Octet 3a otherwise.). >A miscoded optional Information element should never lead to a clearing of >the call ! > >Regards, >Karl >------------------------------------------------ >Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1 >Hofmannstr. 51, D-81359 Munich, Germany >Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 >e-mail: karl.klaghofer(a)icn.siemens.de > > >> -----Ursprüngliche Nachricht----- >> Von: Glen Freundlich [SMTP:ggf@lucent.com] >> Gesendet am: Donnerstag, 6. Mai 1999 22:11 >> An: ITU-SG16(a)mailbag.cps.intel.com >> Betreff: caller ID and implementer's guide >> >> At the Monterey meeting we discussed the possibility of an addition to >> the Implementer's Guide to support caller ID features (APC-1527). >> H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party >> Number IE (and also specifies that the octet 3 extension bit shall be >> set to 1). The proposal calls for removing the restriction through the >> Implementer's Guide. (See also the meeting report in APC-1554b.) >> >> Fixing this brings up the possibility of interoperability problems with >> existing products. Please respond if you think this change will be a >> problem. You can respond to me individually, rather than to the entire >> list, if you prefer. >> >> Thanks, >> 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 -------------------------------------------------- Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Consulting Eng. - Telco Reality - Love it or Leave it. --------------------------------------------------

2 1

H.GCP / Megacop capabilities desctriptors issue
by H323MAIL 10 May '99

10 May '99

Dear GCPers/MEGACOPers There has been some discussion lately on the suitability of standard SDP for expressing the capabilities of MGs. At the TIPHON meeting in Bangkok (some of us <are> having fun) we held an informal meeting with participants from Telcordia, VocalTec, Siemens, Ascend, Motorola, Dialogic and Lucent (forgive me if I forgot someone). There was general agreement (by which I do NOT mean consensus...) that the use of SDP in Megacop as it currently stands is a problem: 1. SDP cannot express inartistic hardware limitations, such as mutually exclusive sets of capabilities (e.g. "I can do 24 x GSM and 24 x 723 but not at the same time"). 2. This has two implications: * either the MG cannot express these limitations, which means that it will reject many commands from the MGC, as the MGC is unaware of the limitations (we called it "reject floods"). * or the MG will have to be designed (with extra DSP/memory for example) to not have any limitations that cannot be expressed using SDP. If you build hardware, this is immediately obvious. 3. Interoperability between decomposed GWs and simple 323 endpoints will be effected, as many calls will fail due to capabilities (and current resource use implications) not being correctly represented to the call signalling layer. 4. That the current method of expressing capabilities (regardless of SDP) is "by Value" and should be "by Reference", where: * a master-set of capabilites is represented at the root level, and references to it are used when issueing commands; * leaf-nodes only contain logical references: (e.g. "I am a T1 line, I can do 24 x Cap-1 OR 22 x Cap-2") 5. That the discussion of "SDP Vs. H.245" is inherently flawed, as: * SDP is only capabilities descriptors, and H.245 is also multiple sets of procedures (master/slave, caps-exchange, OLCs, conferencing control). * The issue is whether we should be using H.245 CAPABILITIES DESCRIPTORS irrelevant of packetizarion, not the actual procedures of H.245. * that talking about H.245 does not immediately mean ASN.1 PER. 6. That the internal model is not consistent (this may have been corrected in the latest draft from Brian) - by this I mean that * The MGC knows what the state of it's MG is because it is the only entity that can change it (one-to-one relationship); and * if the state of the MG changed NOT DUE TO A COMMAND FROM THE MGC, the MG must report this to the MGC. * This handles failures (where some trunk-group went out of service) and when the resources of multiple logical MGs are an expression of on physical MG. I am suggesting that: * We acknowledge the limitation of SDP and find a solution that works, this is where people will write contributions. Whatever we choose is in any-case no longer compliant SDP. * we change the capabilities descriptors (that we choose based on the previous point...) to be "by reference". * that we clarify the internal consistency model.

2 1

REMINDER:Megaco/H.gcp call May 11th
by Nancy-M Greene 10 May '99

10 May '99

We agreed to hold another conference call Tuesday May 11th at 10am ET. Proposed agenda: 1) mono vs multi media contexts 2) use of SDP or H.245 for describing media in the local/remote termination descriptors. - we really mean extending SDP vs using a subset of H.245 - allow both? some MGs will understand one way, others the other way, and it would be a property of a termination class? - still need to see call flows/proposals for both methods. 3) naming of terminations 4) Tom's test case Call details: Date: Tuesday May 11/99 Time: 10am-12pm ET phone: 1-613-765-3171 (different number from last time) passcode: 131313# (same passcode as last time) ***Problems getting on the call? Call 1-613-765-CONF, and ask for the conference chaired by Nancy Greene ***Minutes from the call will be posted by the end of the day to both the Megaco and the SG16 mailing lists Nancy Greene Brian Hill ngreene(a)nortelnetworks.com bhill(a)videoserver.com -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

Fwd: H.GCP / Megacop capabilities desctriptors issue
by Massimo Lucchina 10 May '99

10 May '99

Just to close this off (comments inline) Tiphon is not expressing any position on this stuff, the meeting happened to be during the ETSI session but has nothing to do with it. What was agreed was correctly expressed by Gur (extracted from the very bottom of previous posting) and Matt is right, we made some progress >I am suggesting that: > > * We acknowledge the limitation of SDP and find a solution that works, > this is where people will write contributions. Whatever we choose is > in any-case no longer compliant SDP. > > * we change the capabilities descriptors (that we choose based on the > previous point...) to be "by reference". > > * that we clarify the internal consistency model. The below point 1, 3, 5 were discussed and nothing was decided on how to solve the issues: actually it was not mentioned whether SDP is flawed or not, simply it was noted that MEGACO gateways need to interoperate with existing legacy H.323 gateway and endpoints and there is a need to make this working. Capabilities By Reference vs By Value was also mentioned and a more general consensus will be searched. Point 2 and 6: these seems more a proposal for addressing some issues; these are not an output of that conversation >From: H323MAIL <H323MAIL(a)VOCALTEC.COM> >Subject: H.GCP / Megacop capabilities desctriptors issue >Comments: To: ITU-SG16(a)mailbag.cps.intel.com, > MEGACO(a)STANDARDS.NORTELNETWORKS.COM >To: ITU-SG16(a)mailbag.cps.intel.com > >Dear GCPers/MEGACOPers > >There has been some discussion lately on the suitability >of standard SDP for expressing the capabilities of MGs. At the >TIPHON meeting in Bangkok (some of us <are> having fun) we held an >informal meeting with participants from Telcordia, VocalTec, Siemens, >Ascend, Motorola, Dialogic and Lucent (forgive me if I forgot someone). > >There was general agreement (by which I do NOT mean consensus...) that >the use of SDP in Megacop as it currently stands is a problem: > >1. SDP cannot express inartistic hardware limitations, such as mutually > exclusive sets of capabilities (e.g. "I can do 24 x GSM and 24 x 723 but > not at the same time"). > >2. This has two implications: > > * either the MG cannot express these limitations, which means that it > will reject many commands from the MGC, as the MGC is unaware of the > limitations (we called it "reject floods"). > > * or the MG will have to be designed (with extra DSP/memory for example) > to not have any limitations that cannot be expressed using SDP. > > If you build hardware, this is immediately obvious. > >3. Interoperability between decomposed GWs and simple 323 endpoints will > be effected, as many calls will fail due to capabilities (and current > resource use implications) not being correctly represented to the call > signalling layer. > >4. That the current method of expressing capabilities (regardless of SDP) > is "by Value" and should be "by Reference", where: > > * a master-set of capabilites is represented at the root level, > and references to it are used when issueing commands; > > * leaf-nodes only contain logical references: > (e.g. "I am a T1 line, I can do 24 x Cap-1 OR 22 x Cap-2") > >5. That the discussion of "SDP Vs. H.245" is inherently flawed, as: > > * SDP is only capabilities descriptors, and H.245 is also multiple sets >of > procedures (master/slave, caps-exchange, OLCs, conferencing control). > > * The issue is whether we should be using H.245 CAPABILITIES DESCRIPTORS > irrelevant of packetizarion, not the actual procedures of H.245. > > * that talking about H.245 does not immediately mean ASN.1 PER. > >6. That the internal model is not consistent (this may have been > corrected in the latest draft from Brian) - by this I mean that > > * The MGC knows what the state of it's MG is because it is the only > entity that can change it (one-to-one relationship); and > > * if the state of the MG changed NOT DUE TO A COMMAND FROM THE MGC, > the MG must report this to the MGC. > > * This handles failures (where some trunk-group went out of service) > and when the resources of multiple logical MGs are an expression of > on physical MG. ______________________________________________________ Massimo Lucchina TEL: +33 1 69185269 16 av. du Quebec, Villebon BP FAX: +33 1 69288326 91961 Les Ulis - France GSM: +33 6 07675242

1 0

Re: Fwd: H.GCP / Megacop capabilities desctriptors issue
by Randall S Stewart [C] 10 May '99

10 May '99

Thanks for the Fwd Massimo, since I am not on the exploder for SG16.... Here are my comments based on my remeberances from our conversations... Massimo Lucchina wrote: > >X-SMAP-Received-From: outside > >X-Lotus-FromDomain: VOCALTEC > >Date: Fri, 7 May 1999 07:56:47 +0200 > >Reply-To: Mailing list for parties associated with ITU-T Study Group 16 > > <ITU-SG16(a)mailbag.cps.intel.com> > >Sender: Mailing list for parties associated with ITU-T Study Group 16 > > <ITU-SG16(a)mailbag.cps.intel.com> > >From: H323MAIL <H323MAIL(a)VOCALTEC.COM> > >Subject: H.GCP / Megacop capabilities desctriptors issue > >Comments: To: ITU-SG16(a)mailbag.cps.intel.com, > > MEGACO(a)STANDARDS.NORTELNETWORKS.COM > >To: ITU-SG16(a)mailbag.cps.intel.com > > > >Dear GCPers/MEGACOPers > > > >There has been some discussion lately on the suitability > >of standard SDP for expressing the capabilities of MGs. At the > >TIPHON meeting in Bangkok (some of us <are> having fun) we held an > >informal meeting with participants from Telcordia, VocalTec, Siemens, > >Ascend, Motorola, Dialogic and Lucent (forgive me if I forgot someone). > > > >There was general agreement (by which I do NOT mean consensus...) that > >the use of SDP in Megacop as it currently stands is a problem: > > > >1. SDP cannot express inartistic hardware limitations, such as mutually > > exclusive sets of capabilities (e.g. "I can do 24 x GSM and 24 x 723 but > > not at the same time"). > Yes.. > >2. This has two implications: > > > > * either the MG cannot express these limitations, which means that it > > will reject many commands from the MGC, as the MGC is unaware of the > > limitations (we called it "reject floods"). > > > > * or the MG will have to be designed (with extra DSP/memory for example) > > to not have any limitations that cannot be expressed using SDP. > > > > If you build hardware, this is immediately obvious. > I don't think we reached any conclusions about "reject flood" or other limitations based on hardware et.al. It may be that the author of this (which I cannot tell from the From: line) is reflecting a problem that they themselves have.. I do think it is a matter of individual postition... > >3. Interoperability between decomposed GWs and simple 323 endpoints will > > be effected, as many calls will fail due to capabilities (and current > > resource use implications) not being correctly represented to the call > > signalling layer. > > What was stated is that interop with 323 endpoints is a must and therefore the issue has to be studied agreed... we were to study this item... no conclusion was reached in the group... > >4. That the current method of expressing capabilities (regardless of SDP) > > is "by Value" and should be "by Reference", where: > > > > * a master-set of capabilites is represented at the root level, > > and references to it are used when issueing commands; > > > > * leaf-nodes only contain logical references: > > (e.g. "I am a T1 line, I can do 24 x Cap-1 OR 22 x Cap-2") > I liked this idea, by reference is always nice :) > >5. That the discussion of "SDP Vs. H.245" is inherently flawed, as: > > > > * SDP is only capabilities descriptors, and H.245 is also multiple sets > >of > > procedures (master/slave, caps-exchange, OLCs, conferencing control). > > > > * The issue is whether we should be using H.245 CAPABILITIES DESCRIPTORS > > irrelevant of packetizarion, not the actual procedures of H.245. > > > > * that talking about H.245 does not immediately mean ASN.1 PER. > Yes we did agree that a starting point (not the final solution) to look at fixing this problem is with the CAPABILITIES DESCRIPTORS of H.245. That is not to say we would use H.245 procedures and it is not to say that the current H.245 descriptors could not be enhanced and improved in a yet undetermined way... All we agreed is H.245 CD's are a good place to start to fix the problem... > >6. That the internal model is not consistent (this may have been > > corrected in the latest draft from Brian) - by this I mean that > > > > * The MGC knows what the state of it's MG is because it is the only > > entity that can change it (one-to-one relationship); and > > > > * if the state of the MG changed NOT DUE TO A COMMAND FROM THE MGC, > > the MG must report this to the MGC. > > > > * This handles failures (where some trunk-group went out of service) > > and when the resources of multiple logical MGs are an expression of > > on physical MG. > >I am suggesting that: > > > > * We acknowledge the limitation of SDP and find a solution that works, > > this is where people will write contributions. Whatever we choose is > > in any-case no longer compliant SDP. > > > > * we change the capabilities descriptors (that we choose based on the > > previous point...) to be "by reference". > > > > * that we clarify the internal consistency model. > Yes, some improvement will be needed... the above is your suggestion on how to improve it. I think we reached a point that we all agree we have some issues to address... we did not come anywhere near agreement on how to fix the problems.... But of course the first step to fixing a problem is to recognize that you have one :) Cheers R -- Randall R. Stewart Member Technical Staff Network Architecture and Technology (NAT) 847-632-7438 fax:847-632-6733

1 0

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

10 May '99

Paul, If we're going to standardise it, why should it be nonStandard? In other words, if it is considered an important thing to add, and it is considered impossible to include it in its original place (on which I express no opinion), then it should be added to the standard as an information element in the H.225.0 message, not put in a standard bit of non-standard information. If my reading of the ASN.1 is correct, and we were to follow your suggestion, it would be impossible to transmit a setup message with the addition you propose and also a non-standard parameter of my own devising (unless, of course, I could persuade Smith Micro to "like" my non-standard information and put it in their private non-standard parameter) - and I am sure this would be unacceptable to many. 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: Paul Long [mailto:Plong@SMITHMICRO.COM] > Sent: 08 May 1999 3:22 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: caller ID and implementer's guide > > > Karl, > > It may have been a mistake to exclude octet 3a, but it is far > too late to > "fix" this through its inclusion. H.323 is not merely an > academic work that is > forever in progress, with no real repercussions if we change > it. Compliant > products have been shipped according to what is written in the H.323 > Recommendation. Moreover, because an EP cannot determine the > H.323 version of > the remote EP before sending its SETUP, octet 3a must forever > be excluded in > H.323. > > Here is a way we can maintain H.323's integrity and provide > the apparently > much needed information in octet 3a. Carry the value for octet 3a in > H323-UU-PD.nonStandardData. Have boundary entities between > the packet network > and the SCN move this value between the real octet 3a on the > SCN side and the > octet-3a proxy on the packet side. Smith Micro would "donate" > our H.221 > identifier, but we could use anyone's. The > nonStandardData.data octet string > would hold an ASN.1 encoding of this type: > > H323-UU-PD-SMSINonStandardParameter ::= SEQUENCE > { > callingPartyNumberIEOctet3a OCTET STRING SIZE(1) OPTIONAL, > ... > } > > Practically speaking, > if h323-message-body is setup, > h323-uu-pdu.nonStandardData is present, > h323-uu-pdu.nonStandardData.nonStandardIdentifier is h221NonStandard, > h323-uu-pdu.nonStandardData.nonStandardIdentifier.h221NonStand > ard is {181, 0, > 30324}, and > bit 7 (bit 8 is MSB) of h323-uu-pdu.nonStandardData.data[0] is 1 > (callingPartyNumberIEOctet3a is present), then > h323-uu-pdu.nonStandardData.data[1] contains the value for octet 3a. > > Note that, according to ASN.1 PER aligned encoding, bits 6 > through 1 of > h323-uu-pdu.nonStandardData.data[0] are always 0 and that bit > 8 indicates > whether other, TBD components are present that are not in the > root extension. > This allows us to provide other info in the future if needed. > > This is what H323-UU-PD.nonStandardData would typically be set to: > { > h221NonStandard { 181, 0, 30324 }, -- Smith Micro's H.221 > identifier > { 64, x } -- x is octet 3a from calling > party number > information element > } > > This is similar to an H.324 fix, so there is precedent for > this sort of thing. > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Karl.Klaghofer(a)ICN.SIEMENS.DE > [SMTP:Karl.Klaghofer@ICN.SIEMENS.DE] > Sent: Friday, May 07, 1999 3:43 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: AW: caller ID and implementer's guide > > Glen and others, > > It was a mistake to exclude the octet 3a in H.225.0 > (v1 and v2) > Calling > party number IE. It has led to interoperability > problems with the SCN > in > the past (where octet 3a is used) ! > Now, it is time to fix this error as discussed in the Monterey > Rapporteuts > meeting in February (i.e. for H.225.0v3 but also for > H.225.0v2 via > Implementors Guide !). There may be procucts already > planning on that > announced correction. > > An endpoint B - not supporting octet 3a of Calling > Party Number > Information > element - should treat this situation as a > "non-mandatory information > element content error". The reaction to such an type > of error shall > be: > * Take actions on the SETUP received and on all > the information > elements that are recognized and have valid contents; > i.e. ignore only > the > Calling party Number IE > * A STATUS may optionally be returned with Cause #100. > > Refer also to Q.931 clause 5.8.7.2 (which should > applicable also to > H.225.0, > since H.225.0 is so much based on the Q.931). > > So, if such an endpoint B receives an octet 3a in > Calling party Number > set > to "presentation allowed", all that happens is that > the Number would > not be > displayed at B. > But for the really critical case where the octet 3a > is received by > such an > endpoint B being set to "presentation restrictet", we > have even the > behavier > we intend, namely NOT to display the number to the > endpoint B (since > the > whole IE should be ignored anyway). > > A miscoded optional Information element should never lead to a > clearing of > the call ! > > Regards, > Karl > ------------------------------------------------ > Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1 > Hofmannstr. 51, D-81359 Munich, Germany > Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 > e-mail: karl.klaghofer(a)icn.siemens.de > > > > -----Ursprüngliche Nachricht----- > > Von: Glen Freundlich [SMTP:ggf@lucent.com] > > Gesendet am: Donnerstag, 6. Mai 1999 22:11 > > An: ITU-SG16(a)mailbag.cps.intel.com > > Betreff: caller ID and implementer's guide > > > > At the Monterey meeting we discussed the > possibility of an addition > to > > the Implementer's Guide to support caller ID > features (APC-1527). > > H.225.0 V2 (and V1) forbids the use of octet 3a in > the Calling Party > > Number IE (and also specifies that the octet 3 > extension bit shall > be > > set to 1). The proposal calls for removing the > restriction through > the > > Implementer's Guide. (See also the meeting report > in APC-1554b.) > > > > Fixing this brings up the possibility of > interoperability problems > with > > existing products. Please respond if you think this > change will be a > > problem. You can respond to me individually, rather > than to the > entire > > list, if you prefer. > > > > Thanks, > > 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 >

3 2

Re: H.323 AnnexD & mandatory fax OpenLogicalChannel elements
by joachim.fabini＠SEA.ERICSSON.SE 10 May '99

10 May '99

> -----Original Message----- > From: vineet.kumar(a)INTEL.COM [mailto:vineet.kumar@INTEL.COM] > Sent: Thursday, May 06, 1999 11:35 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Cc: vineet.kumar(a)INTEL.COM > Subject: Re: H.323 AnnexD & mandatory fax OpenLogicalChannel elements > Vineet, I do have the recommendation H.323AnnexD that is available from the ITU website. The sentence can be found on page 4 (D.7: Interactions with gateways and T.38/AnnexB devices), second paragraph. Furthermore, section D.2 (Scope) says, that "An H.323 terminal that supports the procedures of this Annex shall interwork with T.38/AnnexB terminals". The interoperability with T.38 AnnexB terminals thus is mandatory. My understanding of this is that AnnexD compliant H.323 gateways must use the fastStart procedures and open both, fax and voice channels when the receiving gateway is also a H.323 terminal supporting AnnexD. --Joachim > > I think you have a draft version of Annex D and not the > decided version. I can't find the sentence you mentioned > in your email in my copy of Annex D. > > vineet

1 0

Input documents for the SG16 meeting in Santiago
by Sakae OKUBO 10 May '99

10 May '99

Dear Q.12-14/16 experts, For your review, the following documents have been placed at the ftp site: ftp://standard.pictel.com/avc-site/9905_San/ or http://standard.pictel.com/ftp/avc-site/9905_San/ Ott> I have placed a copy of the revised Draft H.323 Annex F (incorporating Ott> editorial changes from the last Rapporteur's meeting in Monterey) in Ott> the Incoming directory on the PicureTel ftp server: H323AnnexF- Ott> Delayed.zip Hellstrom> File: h323Annexg-11.zip Source: LM Ericsson Title: H.323 Annex G: Text Conversation Question: 13/16, 9/16 Doc for: Determination Summary: A proposal for introduction of text conversation in packet based multimedia systems. Contact : Gunnar Hellstr $BSN (B, Ericsson Sweden, tel +46 751 100 501 fax +46 8 556 002 06 e-mail: gunnar.hellstrom(a)omnitor.se File: T140missingtext1.zip Source: LM Ericsson Title : Marker for missing text in T.140 Text Conversation Protocol Question: 9/16, 13/16 Doc for: Approval Summary: A proposal to assign a character for marking missing text in a T.140 text conversation. Contact: Gunnar Hellstr $BSN (B, Ericsson Home Communications, tel +46 751 100 501 fax +46 8 556 002 06 e-mail: Gunnar.Hellstrom(a)omnitor.se File: H323AnnexFcomments1.zip Source: LM Ericsson Title: Minor modifications to H.323 Annex F Plen Doc for: Decision Summary: The document contains minor modification proposals to H.323 Annex F to make it easier to apply it as a template to other SET specifications. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

TD's for discussion at the Santiago meeting
by Espen Skjæran (ETO) 10 May '99

10 May '99

Dale, We would like to bring up a (rather new) topic for discussion about a future work item at the rapporteur's part of the Santiago meeting. We hope this is possible at this time. The topic is service control (and have been discussed at Tiphon meeting in Bankok this week). We will like to bring forward some of the Tiphon discussion to sg16. We will write a small note about the possible use of H.245 to establish service control channels. It will be explained via a few simple examples, and hopefully serve as a basis fo further dicsussion. Thus we will ask you as a rapporteur to give us a TD number if this is required. Espen Skjaeran

2 1

Annex G Editorial Comments - new version
by Lior Moscovici 09 May '99

09 May '99

I recieved some comments on the previous version. I made some revisions, added a few more modifications. Everyone is encouraged to comment until the Santiago meeting. (See attached file: annexg_editor_contribution2.doc) Lior ---------------------- Forwarded by Lior Moscovici/Vocaltec_Comm on 05/09/99 08:30 PM --------------------------- To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: h323mail) From: Lior Moscovici <Lior_Moscovici(a)VOCALTEC.COM> Date: 05/04/99 09:58:08 PM GMT Subject: Annex G Editorial Comments Hello All, Attached are editorial changes to Annex G. I intend to submit them as a Rapporteur TD to the Santiago meeting. If anyone has some additional comments, please forward to me, so I can incorporte them in the decided version. Thanks, Lior (See attached file: annexg_editor_contribution2.doc) Lior Moscovici Program Manager, Servers Group R&D VocalTec Communications Ltd. Voice: +972 9 9707767 E-mail: liorm(a)vocaltec.com Fax: +972 9 9561867 Lior Moscovici Program Manager, Servers Group R&D VocalTec Communications Ltd. Voice: +972 9 9707767 E-mail: liorm(a)vocaltec.com Fax: +972 9 9561867

1 0

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

08 May '99

Karl, It may have been a mistake to exclude octet 3a, but it is far too late to "fix" this through its inclusion. H.323 is not merely an academic work that is forever in progress, with no real repercussions if we change it. Compliant products have been shipped according to what is written in the H.323 Recommendation. Moreover, because an EP cannot determine the H.323 version of the remote EP before sending its SETUP, octet 3a must forever be excluded in H.323. Here is a way we can maintain H.323's integrity and provide the apparently much needed information in octet 3a. Carry the value for octet 3a in H323-UU-PD.nonStandardData. Have boundary entities between the packet network and the SCN move this value between the real octet 3a on the SCN side and the octet-3a proxy on the packet side. Smith Micro would "donate" our H.221 identifier, but we could use anyone's. The nonStandardData.data octet string would hold an ASN.1 encoding of this type: H323-UU-PD-SMSINonStandardParameter ::= SEQUENCE { callingPartyNumberIEOctet3a OCTET STRING SIZE(1) OPTIONAL, ... } Practically speaking, if h323-message-body is setup, h323-uu-pdu.nonStandardData is present, h323-uu-pdu.nonStandardData.nonStandardIdentifier is h221NonStandard, h323-uu-pdu.nonStandardData.nonStandardIdentifier.h221NonStandard is {181, 0, 30324}, and bit 7 (bit 8 is MSB) of h323-uu-pdu.nonStandardData.data[0] is 1 (callingPartyNumberIEOctet3a is present), then h323-uu-pdu.nonStandardData.data[1] contains the value for octet 3a. Note that, according to ASN.1 PER aligned encoding, bits 6 through 1 of h323-uu-pdu.nonStandardData.data[0] are always 0 and that bit 8 indicates whether other, TBD components are present that are not in the root extension. This allows us to provide other info in the future if needed. This is what H323-UU-PD.nonStandardData would typically be set to: { h221NonStandard { 181, 0, 30324 }, -- Smith Micro's H.221 identifier { 64, x } -- x is octet 3a from calling party number information element } This is similar to an H.324 fix, so there is precedent for this sort of thing. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Karl.Klaghofer(a)ICN.SIEMENS.DE [SMTP:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: Friday, May 07, 1999 3:43 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: AW: caller ID and implementer's guide Glen and others, It was a mistake to exclude the octet 3a in H.225.0 (v1 and v2) Calling party number IE. It has led to interoperability problems with the SCN in the past (where octet 3a is used) ! Now, it is time to fix this error as discussed in the Monterey Rapporteuts meeting in February (i.e. for H.225.0v3 but also for H.225.0v2 via Implementors Guide !). There may be procucts already planning on that announced correction. An endpoint B - not supporting octet 3a of Calling Party Number Information element - should treat this situation as a "non-mandatory information element content error". The reaction to such an type of error shall be: * Take actions on the SETUP received and on all the information elements that are recognized and have valid contents; i.e. ignore only the Calling party Number IE * A STATUS may optionally be returned with Cause #100. Refer also to Q.931 clause 5.8.7.2 (which should applicable also to H.225.0, since H.225.0 is so much based on the Q.931). So, if such an endpoint B receives an octet 3a in Calling party Number set to "presentation allowed", all that happens is that the Number would not be displayed at B. But for the really critical case where the octet 3a is received by such an endpoint B being set to "presentation restrictet", we have even the behavier we intend, namely NOT to display the number to the endpoint B (since the whole IE should be ignored anyway). A miscoded optional Information element should never lead to a clearing of the call ! Regards, Karl ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)icn.siemens.de > -----Ursprüngliche Nachricht----- > Von: Glen Freundlich [SMTP:ggf@lucent.com] > Gesendet am: Donnerstag, 6. Mai 1999 22:11 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: caller ID and implementer's guide > > At the Monterey meeting we discussed the possibility of an addition to > the Implementer's Guide to support caller ID features (APC-1527). > H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party > Number IE (and also specifies that the octet 3 extension bit shall be > set to 1). The proposal calls for removing the restriction through the > Implementer's Guide. (See also the meeting report in APC-1554b.) > > Fixing this brings up the possibility of interoperability problems with > existing products. Please respond if you think this change will be a > problem. You can respond to me individually, rather than to the entire > list, if you prefer. > > Thanks, > 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

SDP and H.245
by Tom-PT Taylor 07 May '99

07 May '99

I'm going to be reviewing our work plan this weekend and attempting to lay out a detailed schedule of issues to solve between now and July, just to establish priorities if necessary. Even without doing this I suspect we don't have time for a civil war over the SDP vs. H.245 issue, so I'm going to swallow my architectural principles and make the following proposal: Which method of expression is used will be a property of the MG, either discoverable by the MGC through an audit or administratively defined. MGs will use either H.245-based descriptors or SDP-based descriptors -- the control protocol is indifferent between them. If this is too drastic, the terms can be negotiated, but can we accept the principle of willingness to allow either protocol to be used as the basis for termination descriptors? 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 Kaynam Hedayat 07 May '99

07 May '99

Hi, H.323 V1 and V2 endpoints correctly assume that octet 3a is not present since H.225.0 states that it shall not be. Therefore there are endpoints that don't check for the extension bit of octet 3 (i.e. assume it is 1). I agree that it is useful to forward octet 3a but backward compatibility must be met. Kaynam Rich Bowen <rkbowen(a)CISCO.COM> on 05/07/99 03:49:54 PM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Kaynam Hedayat/PicTel) Subject: Re: caller ID and implementer's guide Glen, others, I also would support the proposal to allow octet 3a. We have had requests from customers to allow this information. Not knowing about APC-1527, I also submitted a contribution to allow octet 3a (D-264), with proposed text indicating that gateways "should" forward this information as received from the SCN. As Glen has indicated, however, we need to look further into interoperability issues. Regards, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen(a)cisco.com Research Triangle Park, NC -------------------------------------------------------------------- Karl.Klaghofer(a)ICN.SIEMENS.DE wrote: > > Glen and others, > > It was a mistake to exclude the octet 3a in H.225.0 (v1 and v2) Calling > party number IE. It has led to interoperability problems with the SCN in > the past (where octet 3a is used) ! > Now, it is time to fix this error as discussed in the Monterey Rapporteuts > meeting in February (i.e. for H.225.0v3 but also for H.225.0v2 via > Implementors Guide !). There may be procucts already planning on that > announced correction. > > An endpoint B - not supporting octet 3a of Calling Party Number Information > element - should treat this situation as a "non-mandatory information > element content error". The reaction to such an type of error shall be: > * Take actions on the SETUP received and on all the information > elements that are recognized and have valid contents; i.e. ignore only the > Calling party Number IE > * A STATUS may optionally be returned with Cause #100. > > Refer also to Q.931 clause 5.8.7.2 (which should applicable also to H.225.0, > since H.225.0 is so much based on the Q.931). > > So, if such an endpoint B receives an octet 3a in Calling party Number set > to "presentation allowed", all that happens is that the Number would not be > displayed at B. > But for the really critical case where the octet 3a is received by such an > endpoint B being set to "presentation restrictet", we have even the behavier > we intend, namely NOT to display the number to the endpoint B (since the > whole IE should be ignored anyway). > > A miscoded optional Information element should never lead to a clearing of > the call ! > > Regards, > Karl > ------------------------------------------------ > Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1 > Hofmannstr. 51, D-81359 Munich, Germany > Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 > e-mail: karl.klaghofer(a)icn.siemens.de > > > -----Ursprüngliche Nachricht----- > > Von: Glen Freundlich [SMTP:ggf@lucent.com] > > Gesendet am: Donnerstag, 6. Mai 1999 22:11 > > An: ITU-SG16(a)mailbag.cps.intel.com > > Betreff: caller ID and implementer's guide > > > > At the Monterey meeting we discussed the possibility of an addition to > > the Implementer's Guide to support caller ID features (APC-1527). > > H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party > > Number IE (and also specifies that the octet 3 extension bit shall be > > set to 1). The proposal calls for removing the restriction through the > > Implementer's Guide. (See also the meeting report in APC-1554b.) > > > > Fixing this brings up the possibility of interoperability problems with > > existing products. Please respond if you think this change will be a > > problem. You can respond to me individually, rather than to the entire > > list, if you prefer. > > > > Thanks, > > 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

Re: caller ID and implementer's guide
by Rich Bowen 07 May '99

07 May '99

Glen, others, I also would support the proposal to allow octet 3a. We have had requests from customers to allow this information. Not knowing about APC-1527, I also submitted a contribution to allow octet 3a (D-264), with proposed text indicating that gateways "should" forward this information as received from the SCN. As Glen has indicated, however, we need to look further into interoperability issues. Regards, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen(a)cisco.com Research Triangle Park, NC -------------------------------------------------------------------- Karl.Klaghofer(a)ICN.SIEMENS.DE wrote: > > Glen and others, > > It was a mistake to exclude the octet 3a in H.225.0 (v1 and v2) Calling > party number IE. It has led to interoperability problems with the SCN in > the past (where octet 3a is used) ! > Now, it is time to fix this error as discussed in the Monterey Rapporteuts > meeting in February (i.e. for H.225.0v3 but also for H.225.0v2 via > Implementors Guide !). There may be procucts already planning on that > announced correction. > > An endpoint B - not supporting octet 3a of Calling Party Number Information > element - should treat this situation as a "non-mandatory information > element content error". The reaction to such an type of error shall be: > * Take actions on the SETUP received and on all the information > elements that are recognized and have valid contents; i.e. ignore only the > Calling party Number IE > * A STATUS may optionally be returned with Cause #100. > > Refer also to Q.931 clause 5.8.7.2 (which should applicable also to H.225.0, > since H.225.0 is so much based on the Q.931). > > So, if such an endpoint B receives an octet 3a in Calling party Number set > to "presentation allowed", all that happens is that the Number would not be > displayed at B. > But for the really critical case where the octet 3a is received by such an > endpoint B being set to "presentation restrictet", we have even the behavier > we intend, namely NOT to display the number to the endpoint B (since the > whole IE should be ignored anyway). > > A miscoded optional Information element should never lead to a clearing of > the call ! > > Regards, > Karl > ------------------------------------------------ > Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1 > Hofmannstr. 51, D-81359 Munich, Germany > Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 > e-mail: karl.klaghofer(a)icn.siemens.de > > > -----Ursprüngliche Nachricht----- > > Von: Glen Freundlich [SMTP:ggf@lucent.com] > > Gesendet am: Donnerstag, 6. Mai 1999 22:11 > > An: ITU-SG16(a)mailbag.cps.intel.com > > Betreff: caller ID and implementer's guide > > > > At the Monterey meeting we discussed the possibility of an addition to > > the Implementer's Guide to support caller ID features (APC-1527). > > H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party > > Number IE (and also specifies that the octet 3 extension bit shall be > > set to 1). The proposal calls for removing the restriction through the > > Implementer's Guide. (See also the meeting report in APC-1554b.) > > > > Fixing this brings up the possibility of interoperability problems with > > existing products. Please respond if you think this change will be a > > problem. You can respond to me individually, rather than to the entire > > list, if you prefer. > > > > Thanks, > > 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

Roaming and mobility
by Kristiansen, Lill 07 May '99

07 May '99

On behalf of Espen and myself I will post this (delayed) reply to Douglas Best regards Lill -- Lill Kristiansen, Ericsson Internet Development, XoIP (former MMTS) Billingstad, Norway email: etolkr(a)eto.ericsson.se - - Hi, Thanks for clarifying this. We're basicly happy with an agreement that mobility issues more work. > It is not enough to just say "roaming"! > Douglas Fully support this statement! There are (at least) two different aspects of mobility: Terminal mobility - A terminal communicating independent of location User mobility - The user receives his phone service independent of of terminal and underlying network (domain). In addition we have the discrete vs continuous cases. See Tiphon WG7 for more definitions In wireless one mostly talk about the continuous case (aka handover). Discrete user mobility may very easy be achieved by user oriented E.164 numbers and RAS messages Discrete terminal mobility is often out of scope of the application (may be done by Mobile IP or other means) Digression: In case an H.323 E.164 number is assigned to a terminal/plug in the wall, (i.e. similar to the PSTN case) then you place a call towards this fixed place. The fact that my phusical phone can be plugged in also at another house, does not offer 'mobility', as the calls will still be charged to the plug in the wall. So even though is is a sort of 'discrete terminal mobility', it is not what we're after. (and why the UPT concept was invented) end digression However in most cases with terminal mobility the continuous/wireless case is the interesting one. We consider wireless to be a very important and radio specific access technology, outside the scope and competence of sg16 and Tiphon. Here we're talking about user mobility, as we hope terminal mobility can be achieved with other/access techniques. But the point is, when we are introducing "user mobility" between the Annex G domains, we should make sure that any supplementary services the user subscribes to are also reachable. This includes both services invoked by the service provider and terminal invoked services. For the service provider invoked services one can see solutions as 1. Downloading a service profile from home domain to the visited domain This is done in GSM networks, and requires all services to be standardized. 2. Route the call signaling channel through the home domain This allows proprietary services within the domain to be executed anywhere. I.e. one obtain service mobility, and virtual home environment There is danger of "tromboning" which is the reason it hasn't been introduced in switched networks, but as H.323 uses a packet network, the tromboning applies only to the signaling, which in many cases might not be problematic. See also some comments below Espen and Lill -----Original Message----- > From: Douglas Clowes [mailto:dclowes@ozemail.com.au] > Sent: 27. april 1999 01:01 > To: Espen Skjæran > Cc: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Annex G and Roaming? > > Espen, > It all depends on what you mean by "roaming of users between different > domains". > Annex G does support some functionality for some favours of roaming, but > requires further development - particularly in how to use these aspects > between domains. > > Comments below. > At 14:54 1999-04-23 +0200, Espen Skjæran wrote: > >Hi all, > > > >I've recently heard (unofficially) that some claim Annex G > >(APC-1546/TD-20 in Monterey) > >also to support roaming of users between different domains. > > > >If this is true, I wonder how. > > > >I can see how the AccessRequest/ValidationRequest might be sent from a > >visiting domain to the home domain for per-call authorization. While > >this might work in simple cases, it will hinder the use of services > >while roaming. > Per call authorization permits a user from one domain to use gateway > equipment from a second domain, to make calls to through a gateway in a > third domain. There could even be a fourth domain present as a clearinghouse. > > I don't know what you mean by "hinder the use of services while roaming" in > this context. Perhaps you could elaborate please. This is the VAS/supplementary services issue mention above > >I can not either see any mechanism to authorize the roaming > >registration. > Registration is a completely different issue, and I don't see support for > it in Annex G. Perhaps an RRQ with a remote e.164 or IP address could be > issued to the home domain, by the terminal or host gatekeeper? > >I am sorry to post based on "rumors", but this may change the scope of > >Annex G significally, and I worry if this might affect future work on > >roaming. As Tiphon has just started their work on roaming by analysing > >existing roaming techniques in telco and datacom/IETF work,and not yet > >reached any conclusion, it seems premature to use annex G > >in its current state for roaming. > These concepts will have to be developed in parallel. There is more than > one "type" or "roaming", and different people will think of different > things when that word is used. Maybe have a look at Tiphon 12TD088 for an overview of existing techniques for mobility and roaming in datacom and telecom > Some people think of terminal mobility, yes, and often the continuous/wireless one > while others think of mobile IP. > Neither of these apply to the mobile user on public ingress gateways > depicted above, but they are no less valid and need to be considered. If we compare to the terminology used above, we think what you refer to is discrete user mobility, more like in UPT, where you register for in/outgoing calls to be routed to your current location. I.e. it relates to you and your H.323 application, and the call routing you want (including routing to IVR etc..) And it is true that this is neither wireless nor Mobile IP. But it is important as well. > When we know what the opportunities are, we will be better placed to seek > solutions. It is not enough to just say "roaming"! > Douglas > >Espen

1 0

Delayed Document H.323 Annex F (changes to white paper)
by Joerg Ott 07 May '99

07 May '99

Dear Mr. Okubo, dear colleagues, I have placed a copy of the revised Draft H.323 Annex F (incorporating editorial changes from the last Rapporteur's meeting in Monterey) in the Incoming directory on the PicureTel ftp server: H323AnnexF-Delayed.zip Please disregards file H323AnnexF-02.zip (uploading failed last night). Regards, Joerg ------------------------------------------------------------------------------- Joerg Ott jo(a)tzi.uni-bremen.de Universitaet Bremen, Germany fax + 49 421 218-7000 TELES AG voice + 49 421 201-7028

1 0

Re: TD's for discussion at the Santiago meeting
by Roy, Radhika R, ALCOO 07 May '99

07 May '99

Dale: Yes, I like Espen's idea. I also like to add as follows: 1. Backend services for H.323 2. Mobility support for H.323 3. Other possible topics ... Radhika R. Roy AT&T (732) 420 1580 PS: "Mobile Internet Telephony: Mobile Extension to H.323 by W. Liao," INFOCOM'99, is a good start for support of mobility in H.323. > -----Original Message----- > From: Espen Skjæran (ETO) [SMTP:Espen.Skjaeran@ETO.ERICSSON.SE] > Sent: Friday, May 07, 1999 8:45 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: TD's for discussion at the Santiago meeting > > Dale, > > We would like to bring up a (rather new) topic for discussion about a > future work item at the rapporteur's part of the Santiago meeting. We hope > this is possible at this time. > > The topic is service control (and have been discussed at Tiphon meeting in > Bankok this week). We will like to bring forward some of the Tiphon > discussion to sg16. We will write a small note about the possible use of > H.245 to establish service control channels. It will be explained via a > few simple examples, and hopefully serve as a basis fo further dicsussion. > > Thus we will ask you as a rapporteur to give us a TD number if this is > required. > > > Espen Skjaeran

1 0

Re: flowControlCommand and packet overhead
by Pete Cordell 07 May '99

07 May '99

Let's not get too trigger happy here! The original intent of flowControl is to constrain the bit rate of a channel to something such as a video decoder can cope with. In the past these tended to be MIPS limited, and bit rate tended to be a major (although not only) parameter that affecting the number of MIPS required. Note that in this case this was bits of video data and had nothing to do with headers etc. flowControl is also used to control the rate at which gateways receive things like video data. This allows the gateways to squirt the data down fixed bit rate pipes such as parts of ISDN B channels. Again this figure is not interested in packet overhead. Use of flowControl in the QoS arena is the most recent of its uses. Therefore, even if it is broken in this context, it is not appropriate to change its definition as it would fix one problem and break two others! However, I don't believe it is actually broken in the latter context. In the QoS case, the flowControl command is really only used to switch the channel on and off. The transmitter knows at which rate it will send, and puts this in the RSVPParameters part of the OLC. This information is presumably also put in the RSVP PATH Sender TSPEC. Even if it is desired to allow flowControl to change the channel rate, a transmitter that receives a flowControl message can work out what it requires to add in terms of headers, and then change the RSVP PATH TSPEC accordingly. This will get to the receiver, which will send RESV using the new spec. As the transmitter knows what it is going to do in terms of packetisation and the receiver can only guess, this seems the right way round to me. Pete ============================================= Pete Cordell pete.cordell(a)btinternet.com ============================================= -----Original Message----- From: Gur Kimchi <Gur_Kimchi(a)VOCALTEC.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 07 May 1999 04:41 Subject: Re: flowControlCommand and packet overhead >Paul Wrote: > >>>> The value in consistently >>>> using the same, although arguably flawed, >>>> bandwidth calculations outweighs the >>>> benefit of having a mix of calculations. > >I don't quite agree, this is the type of corrections that should make >into the Implementer's guide. When you calculate for a few sessions >it does not make much of a difference, but there are high-scale GWs >and GKs based on 323 out in the market (supporting multiple DS3s) >and the offset will be too much - it will effect network provisioning. > >- gur > >______________________________________________________________________ > Gur Kimchi > Corporate Director, Advance Technologies, Research and Standards > VocalTec Communications Ltd > web: http://www.vocaltec.com > >-------- On 05/06/99 04:04 PM GMT Paul Long <Plong(a)SMITHMICRO.COM> wrote: > > > > >Steve, > >But H.323, the referencing document via H.225.0 of RFC 1889, says that >bandwidth for the open logical channel bitrate and ARQ is calculated >_without_ >headers. We cannot change this, because it would break existing >implementations. Are you suggesting that flowControlCommand should do it >differently, i.e., include at least the RTP header? The value in >consistently >using the same, although arguably flawed, bandwidth calculations outweighs >the >benefit of having a mix of calculations. > >Paul Long >Smith Micro Software, Inc. > > -----Original Message----- > From: Stephen Casner [SMTP:casner@CISCO.COM] > Sent: Wednesday, May 05, 1999 10:20 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: flowControlCommand and packet overhead > > On Wed, 28 Apr 1999, Paul Long wrote: > > > Therefore, clarification text to the following effect should be >added to > > 6.2.11.2 (in v2) of H.323: > > > > "flowControlCommand applies to the information streams >which >are the > > content of logical channel(s), not including RTP headers, RTP >payload headers, > > network headers and other overhead." > > I'm mostly a lurker on this list, but I thought I would offer >another > perspective. The RTP spec, RFC 1889, says the following: > > Bandwidth calculations for control and data traffic include >lower- > layer transport and network protocols (e.g., UDP and IP) since >that > is what the resource reservation system would need to know. The > application can also be expected to know which of these >protocols >are > in use. Link level headers are not included in the calculation >since > the packet will be encapsulated with different link level >headers >as > it travels. > > At a minimum, I would expect the RTP payload header to be included > because that is specific to the encoding and would not be known by > lower layers. The difficulty in pushing this problem off to lower > layers is that they need to know the packet rate in order to know >how > much overhead the additional headers will add. > -- Steve >

1 0

Re: Draft H.246 Annex C
by Edgar Martinez [1] 07 May '99

07 May '99

Hi Christian, Good timing, In the study D meeting in Washington dc I was asked to put my contribution as a proposal for new annex in h.246. In the contribution I show one example in Annex-A of the RAS messages mapping into ITU INAP other example may include HLR/VLR, MAP and WIN messages. I did not include the parameters mapping. Because, I did not want to do all that work until the concept is approved. (document attached) In any case I have proposed the lower layer sigtran transport (CTP) to carry upper layer protocol for tunneling and interworking. Which should not be any issue with h.246 or the work you are doing..I hope? I will read your contribution as a framework going forward on SS7 interworking. We both/all need to resolve the Transport problem where to terminate the Lower SS7 layers (MTP 1,2,3). That is, where does SS7 ends and IP begins? in the H.323 network i.e., tiphon. Regards, Ed Christian Groves wrote: > > G'Day All, > > Attached is a draft copy of H.246 Annex C. > > As you can see it is Version 0.0 so it needs some > work. It is based on Q.699 as is split into 4 > main sections: > > 1 Overview/Introduction > 2 ISUP to H225 message and parameter mapping > 3 Outgoing Call - H.225 to ISUP > Basic Call > Services > 4 Incoming Call - ISUP to H.225 > Basic Call > Services > > The services sections need some work to align > with the 3pty/conference discussions. > > RAS hasn't been considered in the document yet. > > Comments/addition/amendments welcome. > > Regards, Christian Groves > > ------------------------------------------------------------------------ > Name: h246_annex_c_v_0-0.zip > h246_annex_c_v_0-0.zip Type: Winzip32 File (application/x-zip-compressed) > Encoding: base64 -- 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/

2 1

Re: flowControlCommand and packet overhead
by Gur Kimchi 07 May '99

07 May '99

Paul Wrote: >>> The value in consistently >>> using the same, although arguably flawed, >>> bandwidth calculations outweighs the >>> benefit of having a mix of calculations. I don't quite agree, this is the type of corrections that should make into the Implementer's guide. When you calculate for a few sessions it does not make much of a difference, but there are high-scale GWs and GKs based on 323 out in the market (supporting multiple DS3s) and the offset will be too much - it will effect network provisioning. - gur ______________________________________________________________________ Gur Kimchi Corporate Director, Advance Technologies, Research and Standards VocalTec Communications Ltd web: http://www.vocaltec.com -------- On 05/06/99 04:04 PM GMT Paul Long <Plong(a)SMITHMICRO.COM> wrote: Steve, But H.323, the referencing document via H.225.0 of RFC 1889, says that bandwidth for the open logical channel bitrate and ARQ is calculated _without_ headers. We cannot change this, because it would break existing implementations. Are you suggesting that flowControlCommand should do it differently, i.e., include at least the RTP header? The value in consistently using the same, although arguably flawed, bandwidth calculations outweighs the benefit of having a mix of calculations. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Stephen Casner [SMTP:casner@CISCO.COM] Sent: Wednesday, May 05, 1999 10:20 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: flowControlCommand and packet overhead On Wed, 28 Apr 1999, Paul Long wrote: > Therefore, clarification text to the following effect should be added to > 6.2.11.2 (in v2) of H.323: > > "flowControlCommand applies to the information streams which are the > content of logical channel(s), not including RTP headers, RTP payload headers, > network headers and other overhead." I'm mostly a lurker on this list, but I thought I would offer another perspective. The RTP spec, RFC 1889, says the following: Bandwidth calculations for control and data traffic include lower- layer transport and network protocols (e.g., UDP and IP) since that is what the resource reservation system would need to know. The application can also be expected to know which of these protocols are in use. Link level headers are not included in the calculation since the packet will be encapsulated with different link level headers as it travels. At a minimum, I would expect the RTP payload header to be included because that is specific to the encoding and would not be known by lower layers. The difficulty in pushing this problem off to lower layers is that they need to know the packet rate in order to know how much overhead the additional headers will add. -- Steve

1 0

Re: Annex G & big messages (and TPKT and Annex E)
by Gur Kimchi 06 May '99

06 May '99

Another point to consider is when to use which transport: for Annex G: small/fast messages should be sent over UDP (e.g. the Access family) large/slow messages should be sent over TCP (e.g. information push/pull) ultimately this is an implementation + network environment issue. for Annex E, I really don't see this as an issue - 225 messages are small (we did specify PER for a purpose) and far between, so the follow the small/fast category. - gur -------- On 05/05/99 04:08 PM GMT Andrew Draper <Andrew.Draper(a)MADGE.COM> wrote: At 09:35 1999-05-04 +0200, ETO wrote: >When an Annex G message will exceed max packet size (typically a >DescriptorConfirm) on UDP, a Reject might be sent, and the session is >repeated on TCP. > >But, isn't our PDU size on TCP also limited? When using TPK, the max pdu >size is 65k too, as seen in RFC-1006.... I don't think this is a problem for Annex G. First, a sensible implementation is probably sending DescriptorRequests over TCP anyway since it expects a large (well larger than MRU) answer anyway so the UDP step described above won't happen (only AccessRequest and ValidationRequest is likely to be sent over UDP). Secondly, the only message likely to run into the maximum message size limit is the DescriptorConfirm (if a descriptor is more than 64K). I don't expect anyone to have a descriptor of 64K or more, but if they do it can be broken down into multiple descriptors, and each one transmitted separately. For call signalling over annex E the message size limit isn't a problem either. Annex E will be transmitting the same call signalling messages as would be sent over TPKT over TCP, so messages of more than 64K aren't allowed (since they wouldn't fit within TPKT), even if anyone can create a plausible one. Regards, Andy -- Andrew Draper -- Principal Development Engineer -- WAVE Software Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks, UK. mailto:adraper@madge.com = = = = = = = = = phone:+44 1753 661329 pgp fingerprint 8776 1F5F DD1B F37E BEF7 1E52 924D F6B7 34CB EFA9

1 0