- sg16-avd - lists.packetizer.com

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