- sg16-avd - lists.packetizer.com

Re: Rapporteur for Q5/16
by SAMOU Jean-claude FTRD/DAC/ISS 19 Jan '01

19 Jan '01

Hi, Paul: All my congragulations to you for your appointment as Q5/16 Rapporteur. And be the force with our mobility team in Q5/16 to progress substantially our work. Best regards, Jean-Claude Samou ================================================= Dr. Jean-Claude Samou France Telecom R&D 38-40, rue du General Leclerc 92131 Issy les moulineaux France Tel: + 33 1 45 29 58 40 Fax: + 33 1 46 29 31 62 -----Original Message----- From: OKUBO Sakae [mailto:okubo@GITI.WASEDA.AC.JP] Sent: Wednesday, January 17, 2001 9:28 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Rapporteur for Q5/16 Dear SG16 WP2/16 experts, Mr. F Tosco, Chairman of WP2/16, has advised us that Mr. Paul K Reddy, Intel <paul.k.reddy(a)intel.com> has been appointed as Rapporteur for Q5/16 - Mobility for Multimedia Systems and Services. Best regards, OKUBO Sakae *********************************************************** 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 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

SIP support by H.323 gateways
by Agboh, Charles 19 Jan '01

19 Jan '01

<<Advertisement of SIP Support by H.323 Gateways.doc>> <<Advertisement of SIP by H323GW.txt>> Hello experts; Please read the attached document and if possible, could you please try to answer the following question; Are there any capabilities that you might want to advertise that might be important when an H.323 gatekeeper selects a H.323-SIP Gateway? Best Regards, Charles ------------8-)-------------------------------------- Charles Agboh - IP Telephony Systems Engineer ebOne IP Engineering RFC822: charles.agboh(a)ebone.com Tel: +32 (0) 2 658 4243 mob: +32 495 58 52 67 Fax: +32(0) 2 658 5118 http://www.ebone.com Quan Yin Method

1 0

Re: Rapporteur for Q5/16
by Roy, Radhika R, ALCOO 18 Jan '01

18 Jan '01

Hi, Everyone: It is a good news that we now got a Rapp. for Q5/16 mobility. Earlier, we also got an editor and this makes our mobility team complete. Given the fact, Paul Reddy has been associated with the mobility work from the very beginning, it is hoped that things will go forward resolving all potential issues that we have discussing for a long time. Let us welcome Mr. Reddy for taking this responsibility and Mr. Tosco for finding the right person in this position. Best regards, Radhika R. Roy AT&T -----Original Message----- From: OKUBO Sakae [mailto:okubo@GITI.WASEDA.AC.JP] Sent: Wednesday, January 17, 2001 9:28 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Rapporteur for Q5/16 Dear SG16 WP2/16 experts, Mr. F Tosco, Chairman of WP2/16, has advised us that Mr. Paul K Reddy, Intel <paul.k.reddy(a)intel.com> has been appointed as Rapporteur for Q5/16 - Mobility for Multimedia Systems and Services. Best regards, OKUBO Sakae *********************************************************** 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 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.225- CRV
by Callaghan, Robert 18 Jan '01

18 Jan '01

Chris, The object is to uniquely identify the signaling part of a call. The uniqueness consists of two points, the signaling link and the CRV. The real question is the definition of the signaling link. In a direct call routed model, the endpoints define the link, not the TCP connection. For the gatekeeper routed model, it is more complicated. For a call going EP->GK->GK->EP there are three links. The CRV must be unique for each of the three links. In that the originating endpoint can determine uniqueness for the first (EP->GK) link but not for the following links, it may be necessary for the GKs to change the CRV for a call transiting the GK is forwarded to the next link. I agree that this has not been clear for a long time, and was not properly clarified. The rules should be more clearly defined. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Tuesday, January 16, 2001 5:16 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.225- CRV Paul, I disagree. CRV is surely unique per connection. One may be well advised to keep it more unique than that, because in gatekeepered environments you're liable to end up with problems if you're not careful because of your note 1 - but if I receive Q.931 messages on separate TCP connections giving the same CRV I shouldn't expect them to refer to the same call. I argue that this is rooted in the principal of TransportAddress throughout the H.323 standards including the SAPI (IP port number) as well as actual address. Regards, Chris "Paul E. Jones" wrote: > > Archana, > > (a) is closer to the way things actually work. > > Essentially, you can use whatever values you wish so long as you never place > two calls to the same endpoint using the same CRV value. So, whether two > calls to an endpoint use the same TCP connection or different connections, > the CRV must be unique. > > You should also consider the possibility that an endpoint may have two call > signaling addresses. How would you know if this were the case? The safest > thing to do is never have two calls with the same CRV at the same time. > However, if you know that the destination endpoints are unique, you could > re-use the CRV value.. at least when a Gatekeeper is not being used. > > There are also so other properties of CRVs: > 1) The CRV sent in an ARQ to place a call shall be the same as the > CRV in the resulting Setup message > 2) The CRV sent in an ARQ to accept a call should *not* be taken > from the incoming Setup message-- it should be locally generated so > that it is a unique between the endpoint and the GK > > Paul > > ----- Original Message ----- > From: "Nehru, Archana" <archie(a)trillium.com> > To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM> > Cc: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Monday, January 15, 2001 10:28 PM > Subject: H.225- CRV > > > hi all, > > > > I have a question about H.323 -CRV values. Q.931 specs says that a CRV > value > > should be unique per D-channel layer 2 logical link. > > > > In H.225 context, does the above mean that: > > > > a) CRV values should be unique across all outgoing H.225 calls that have > the > > same "destination" IP address ? > > > > b) CRV value only needs to be unique across all H.225 connections using > the > > same TCP connection? In other words, if an endpoint A makes two > simultaneous > > calls to endpoint B, then the same CRV can be used on both the calls, as > > long as they use different TCP connections? > > > > I would appreciate any help on this. > > > > Regards > > Archana > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.225- CRV
by Nehru, Archana 18 Jan '01

18 Jan '01

hi all, I have a question about H.323 -CRV values. Q.931 specs says that a CRV value should be unique per D-channel layer 2 logical link. In H.225 context, does the above mean that: a) CRV values should be unique across all outgoing H.225 calls that have the same "destination" IP address ? b) CRV value only needs to be unique across all H.225 connections using the same TCP connection? In other words, if an endpoint A makes two simultaneous calls to endpoint B, then the same CRV can be used on both the calls, as long as they use different TCP connections? I would appreciate any help on this. Regards Archana ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

4 4

Re: Interoperability Problems due to Open Type encoding of Null types (fwd)
by Bancroft Scott 17 Jan '01

17 Jan '01

On Wed, 17 Jan 2001, Manoj Paul wrote: > Experts, > > We have come across a specific problem which has been the root > cause of interoperability failures across different implementations > of H.323 stack. The problem is related to the > 1) Encoding and decoding of NULL data types when they appear as > extension IEs. > 2) Encoding and decoding of extension IEs which have NULL as the > outermost ASN type. > > There have been different interpretations of the PER rules that apply > to the above conditions causing interop failures at encode/decode level. > Although the implementations would encode/decode (1) and (2) according > to Open Type elements, some subtle differences come as mentioned below: > > In case of (1), some implementations would not encode an extra 0x00 > octet for NULL data type and would just encode the length of the open type > element as 0x00. This idea probably stems from the fact that a NULL > data type has no encoding when they appear in the root of the ASN.1 type. > However, as per 10.1.3 and 10.2.1 of X.691, the correct encoding for > such a case would be 0x01 0x00, where 0x01 is the uncosntrained length > of the NULL data type encoding and 0x00 is the value of NULL data type in > extension. Your understanding of the encoding is correct. > In case of (2), some implementations would encode the extension IE as per > it's rules (e.g as a Choice/Sequence etc.), but would not add a 0x00 for > the outermost NULL data type in it's encode tree. This would change the > value of length field to be appended to this open type. Whereas some > implementations do add 0x00 octet for the outermost NULL data type. > > There appears to be a confusion as to what is meant by the "outermost" > value in 10.1.3 of X.691. I would appreciate clarification on this > clause as it would save a lot of interop overhead at encode/decode level. "outermost" value refers to a value of a type that is either directly nested in an open type or is a complete application message unto itself. For example, if you had: Foo ::= SEQUENCE { b BOOLEAN, v TYPE-IDENTIFIER.&Type, ..., i NULL } bar Foo ::= {b TRUE, v NULL : NULL, i NULL} The value of Foo, bar, is an outermost value. The value of v (NULL : NULL) is encoded as an outermost value, so in this case since NULL encodes to 0 bits it is replaced with eight 0-bits, and this is prefixed with a length of 1. Similarly, the value of i is encoded as an outermost value, so the resulting encoding in this case will have a length of 1 followed by eight 0-bits. ------------------------------------------------------------------------- Bancroft Scott Toll Free :1-888-OSS-ASN1 OSS Nokalva International:1-732-302-0750 baos(a)oss.com Tech Support :1-732-302-9669 x-1 1-732-302-9669 x-200 Fax :1-732-302-0023 http://www.oss.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Rapporteur for Q5/16
by OKUBO Sakae 17 Jan '01

17 Jan '01

Dear SG16 WP2/16 experts, Mr. F Tosco, Chairman of WP2/16, has advised us that Mr. Paul K Reddy, Intel <paul.k.reddy(a)intel.com> has been appointed as Rapporteur for Q5/16 - Mobility for Multimedia Systems and Services. Best regards, OKUBO Sakae *********************************************************** 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 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Interoperability Problems due to Open Type encoding of Null types
by Paul, Manoj 17 Jan '01

17 Jan '01

Experts, We have come across a specific problem which has been the root cause of interoperability failures across different implementations of H.323 stack. The problem is related to the 1) Encoding and decoding of NULL data types when they appear as extension IEs. 2) Encoding and decoding of extension IEs which have NULL as the outermost ASN type. There have been different interpretations of the PER rules that apply to the above conditions causing interop failures at encode/decode level. Although the implementations would encode/decode (1) and (2) according to Open Type elements, some subtle differences come as mentioned below: In case of (1), some implementations would not encode an extra 0x00 octet for NULL data type and would just encode the length of the open type element as 0x00. This idea probably stems from the fact that a NULL data type has no encoding when they appear in the root of the ASN.1 type. However, as per 10.1.3 and 10.2.1 of X.691, the correct encoding for such a case would be 0x01 0x00, where 0x01 is the uncosntrained length of the NULL data type encoding and 0x00 is the value of NULL data type in extension. In case of (2), some implementations would encode the extension IE as per it's rules (e.g as a Choice/Sequence etc.), but would not add a 0x00 for the outermost NULL data type in it's encode tree. This would change the value of length field to be appended to this open type. Whereas some implementations do add 0x00 octet for the outermost NULL data type. There appears to be a confusion as to what is meant by the "outermost" value in 10.1.3 of X.691. I would appreciate clarification on this clause as it would save a lot of interop overhead at encode/decode level. -Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Corrections to Mobile-UIM
by Reddy, Paul K 17 Jan '01

17 Jan '01

Paul, I agree with Mr.Ernst that word OPTIONAL shall be inserted for the tmsi parameter. thanks, Paul -----Original Message----- From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.AT] Sent: Wednesday, January 17, 2001 1:45 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: AW: Corrections to Mobile-UIM Importance: High Paul, when changing GSM-UIM element tmsi you deleted the word OPTIONAL. This should be re-inserted because tmsi should certainly not become mandatory. Regards, Ernst > -----Ursprüngliche Nachricht----- > Von: Paul E. Jones [mailto:paulej@ACM.ORG] > Gesendet am: Mittwoch, 17. Jänner 2001 07:16 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Corrections to Mobile-UIM > > Folks, > > In the past week or so, the specifications of the mobile number > definitions-- particularly for GSM-UIM-- were discussed and > changes were > deemed necessary. > > I have made changes as recommended by the Annex H and Annex > E/H.246 editors. > > Please find the attached document with the list of > corrections for H.323v4 > and H.225.0v4. In particular, the first GSM-UIM type in > section 2.5 has > been modified since the last time I e-mailed this draft. > > Please review the changes and any other relevant ASN.1 changes. > > Thanks, > Paul > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

AW: Corrections to Mobile-UIM
by Horvath Ernst 17 Jan '01

17 Jan '01

Paul, when changing GSM-UIM element tmsi you deleted the word OPTIONAL. This should be re-inserted because tmsi should certainly not become mandatory. Regards, Ernst > -----Ursprüngliche Nachricht----- > Von: Paul E. Jones [mailto:paulej@ACM.ORG] > Gesendet am: Mittwoch, 17. Jänner 2001 07:16 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Corrections to Mobile-UIM > > Folks, > > In the past week or so, the specifications of the mobile number > definitions-- particularly for GSM-UIM-- were discussed and > changes were > deemed necessary. > > I have made changes as recommended by the Annex H and Annex > E/H.246 editors. > > Please find the attached document with the list of > corrections for H.323v4 > and H.225.0v4. In particular, the first GSM-UIM type in > section 2.5 has > been modified since the last time I e-mailed this draft. > > Please review the changes and any other relevant ASN.1 changes. > > Thanks, > Paul > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1