June 2001 - sg16-avd - lists.packetizer.com

Private telephone number in H.323v4
by Francois Audet 20 Jun '01

20 Jun '01

Hi, I just realize a contradiction in H.323v4 and H.225.0v4 concerning the encoding of "private telephone numbers" (i.e., the type we all use at work): * H.225.0v4 says that "Private telephone numbers" shall be encoded in the UUIE as private numbers, and NOT in the Q.931 information elements (Calling party IE, etc.). Let's call this the "Bob method". See Table 18/H.225.0 Note 1. * H.323v4 says that the Q.931 information element is used for "telephone numbers", and that the UUIE is used for things that are not telephone numbers. Let's call this the "Glenn method". See H.323v4/7.8.2.1 and 7.8.2.2. There is no conflict with both method for "public" telephone number, but there is a conflict for "private" telephone numbers. Which method is right, Bob's or Glenn's? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

2 1

H323 and NAT
by Santosh Kadam - Silicon Portals 19 Jun '01

19 Jun '01

Hi there, I am a new-bird in the VOIP applications , and I would like to clear some basic doubts. Basically I would like to know, why the H323 clients do not work behind the NAT or the proxy network ? I understand that the H323 non compliant clients like net2Phone are able to talk to the PC which r behind NAT but the H323 compliant applications like netMeeting , I am not able to communicate people behind NAT-Proxy network . why and what it can be preventing that these applications are not able to pass audio behind the NAT? Thanks n Regards, Santosh Kadam. e-mail: san(a)siliconportals.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Porto Seguro output documents
by OKUBO Sakae 15 Jun '01

15 Jun '01

Dear Christian, >Please find the following attached: >H.248 Annex L Error Codes and Service Change Reasons >H.248 Annex M.2 MG Congestion Handling Package >H.248 Implementors' Guide >H.248 Series Supplement 2: Packages Guide They have been uploaded to the following place: http://standard.pictel.com/ftp/avc-site/0105_Por/ >H248_annexM2_Load_Control.zip >H248_Annex_L_consent.zip >H248_supp2_Packages_guide.zip >PL-015_H248_imp_guide.zip Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* My contract with TAO finished on 31 March. Please change my e-mail address as above, though okubo(a)giti.or.jp will continue to work for some time. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Porto Seguro output documents
by OKUBO Sakae 15 Jun '01

15 Jun '01

Dear Mike, >I have uploaded H245Version8.zip to the incoming directory. Thank you. This has been moved to /0105_Por directory. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: sourceInfo in LRQ
by Francois Audet 14 Jun '01

14 Jun '01

Agreed. I want to make sure that the case where a Gatekepeer is using the endpoint's address because it is proxying its request. Like this: EP1(+1 408 565 5675) GK1 GK2 EP2(+1 408 495 3756) ARQ(Public.local=4953756) sourceInfo(h323-ID=EP1) ------------------------------> LRQ(Public.local=4953756) sourceInfo(h323-ID=EP1) --------------------------> In this example GK1 doesn't know how to resolve 4953756. It asks GK2 to help. It provides the sourceInfo of EP1 (e.g., an h323-ID or the phone number of the originator). GK2 uses the h323-ID to "figure out" the country code and area code that should be used for the Called party (if EP1 dials a local number, then it is the same country code as EP1's). Of course GK1 can do whatever it pleases since it might be using LRQs for its own purposes, not prompted by an ARQ. -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Thursday, June 14, 2001 10:15 AM To: Audet, Francois [SC2:4K02:EXCH]; ITU-SG16 Subject: Re: sourceInfo in LRQ Francois, I agree with you that what we should do is modify the text to be a bit more tolerant of what "source" means. It might be the source Gatekeeper or it might be the source endpoint's alias. It is possible to find either there today (since either an endpoint or a Gatekeeper may source an LRQ), so the text should reflect that. Paul ----- Original Message ----- From: Francois Audet <mailto:audet@NORTELNETWORKS.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM <mailto:ITU-SG16@mailbag.cps.INTEL.COM> Sent: Wednesday, June 13, 2001 2:40 PM Subject: sourceInfo in LRQ Hi all, The sourceInfor in LRQ states that it should be the alias address of the originator of the LRQ (as opposed to the originator of the call). One of the consequence of this is that if an endpoint sends an ARQ to its gatekeeper, and its gatekeeper can not resolve it, the LRQ that it will send to other gatekeepers may not have enough information to resolve the address. For example, if the number was a "local" number or a "national" number, the gatekeeper that receives the LRQ will not have enough context (where is the originator of the call) to resolve the address (like the country code of the calling user to figure out the contry code of the called user). Anybody has any views on this? My take is that the LRQ.sourceInfo should really reflect the alias address of the originator of the call (the initial ARQ) as opposed to the gatekeeper that originated the LRQ. An alternative would be to define a new field, but I'm not too keen on this approach since it won't work until H.323v5... ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

1 0

sourceInfo in LRQ
by Francois Audet 14 Jun '01

14 Jun '01

Hi all, The sourceInfor in LRQ states that it should be the alias address of the originator of the LRQ (as opposed to the originator of the call). One of the consequence of this is that if an endpoint sends an ARQ to its gatekeeper, and its gatekeeper can not resolve it, the LRQ that it will send to other gatekeepers may not have enough information to resolve the address. For example, if the number was a "local" number or a "national" number, the gatekeeper that receives the LRQ will not have enough context (where is the originator of the call) to resolve the address (like the country code of the calling user to figure out the contry code of the called user). Anybody has any views on this? My take is that the LRQ.sourceInfo should really reflect the alias address of the originator of the call (the initial ARQ) as opposed to the gatekeeper that originated the LRQ. An alternative would be to define a new field, but I'm not too keen on this approach since it won't work until H.323v5... ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

2 1

Query Regarding H.235 BES
by ivarghis＠HSS.HNS.COM 13 Jun '01

13 Jun '01

Hi I have a doubt regarding using BES (Radius ) in H.235 . The H235v2 has mention that in Radius default mode operation the encryption algorithms which are used is DES-CBC or 3DES-Outer CBC. But since the standard has not mentioned any way in which the keys (one key for DES-CBC and 3 keys for 3DES-OCBC ) should be generated, wouldnt it create an interoperability problem as different vendors will use different techniques for generating the keys. Note : In the case of of Baseline Security Profile the key is generated as follows shared key = sha1(password) Is there any endpoint which has implemented the H.235 BES support. If so can you send me some info regarding that. Thanks and Best Regards Ivan ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.225.0 Annex G and Mobility
by Douglas Clowes 13 Jun '01

13 Jun '01

Annex G was in part based on the BEST protocol (APC-1480b, APC-1481 Torino Nov-98). That protocol was architected for a mobile-user application, although it is not depicted in the use cases included in APC-1480b. Much of what was in BEST was carried over into Annex G, but some parts were omitted, and other modified. If people are considering using Annex G for mobility, I would recommend a re-read of those documents (which are still available on the ftp site) ftp://standard.pictel.com/avc-site/till_0012/9811_Tor/APC-1480b.zip and ftp://standard.pictel.com/avc-site/till_0012/9811_Tor/APC-1481.zip Regards, Douglas Clowes Savant Solutions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Introducing new ASN.1 notation for imported elements in H.323 - Some ideas
by Frank Derks 12 Jun '01

12 Jun '01

H.323 imports ASN.1 constructs from H.248. If I am correct, these elements must be encoded as OCTET STRINGS. However, specifying elements in these way does not make it clear what is supposed to go in the OCTET STRING, unless this is added as a comment in the ASN.1 or as explanatory text somewhere else in the document. Recently, I was introduced to the TYPE-IDENTIFIER notation and it would seem that its "&Type part" could help to make the ASN.1 a bit clearer. E.g. the StimulusControl structure currently looks like: StimulusControl ::= SEQUENCE { nonStandard NonStandardParameter OPTIONAL, isText NULL OPTIONAL, h248Message OCTET STRING OPTIONAL } According to the text in Annex L/H.323, the h248Message element may contain any H.248 command. Assuming that this refers to the "Command" element from the H.248 ASN.1, the above can be re- written as: StimulusControl ::= SEQUENCE { nonStandard NonStandardParameter OPTIONAL, isText NULL OPTIONAL, h248Message TYPE-IDENTIFIER.&Type(Command) } This makes it clear that what goes in the h248 message, is a (h.248) command. The same can be applied to the following definitions: H248PackagesDescriptor ::= PackagesDescriptor H248SignalsDescriptor ::= SignalsDescriptor I.e. H248PackagesDescriptor ::= TYPE-IDENTIFIER.&Type(PackagesDescriptor) H248SignalsDescriptor ::= TYPE-IDENTIFIER.&Type(SignalsDescriptor) Any ideas? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

CSRC Usage
by Leano, Bob 11 Jun '01

11 Jun '01

Hello: I need some clarification on the use of the CSRC field with respect to audio conferencing by the MC/MCU. Is it optional or mandatory? the only entry in any spec that I saw was in h.225.0 where it talked about csrc count, not csrc list. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0