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

[Megaco] Purpose Of Annex C
by Tom-PT Taylor 01 Aug '01

01 Aug '01

Before last month's SG 16 meeting I raised the point of the proper use of Annex C values. Today I discovered that we already have it covered. See section 7.2.10, which states unequivocally that Annex C is for the Local and Remote descriptors. One of the open issues on the list is whether we can deprecate the Modem descriptor. If we do so, the corresponding Annex C property can remain there and I would remove mention of it from my SDP-TDM draft. There were some other Annex C properties that I had proposed to remove because they belonged in LocalControl. This wasn't done at the last SG 16 meeting because orderly procedure required list agreement plus alternative packages to put them in. The specific items I would focus on are Mode (tag 1002 in C.1), DialledN (tag 901F in C.9) and DiallingN (tag 9020 in C.9). Mode is in LocalControl already, and the other two are covered by the NAS package. I had also mentioned Gain (tag 100C in C.1) and Jitterbuff (tag 100D in C.1) previously. At this point I'd say Gain might suitably be specified by direction. Jitterbuff should be moved into RTP. Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ Megaco mailing list Megaco(a)ietf.org http://www.ietf.org/mailman/listinfo/megaco

2 1

AW: Syntax method of GEF extension definition
by Horvath Ernst 31 Jul '01

31 Jul '01

Pete, I fully agree with Terry. Let me add that the H.450 series use ROSE, which is pure ASN.1, as a formal method for the same kind of specifications as GEF. I admit that the definitions in H.450.1 look repulsively complex, but the individual supplementary service modules in H.450.x are very straightforward even for extensive services. And it's that latter quite intuitive notation that people use when defining new syntax. If there is need for a third formal method for GEF, I would opt for an ASN.1 based mechanism on the lines of H.450. Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Terry L Anderson [mailto:tla@LUCENT.COM] > Gesendet am: Dienstag, 10. Juli 2001 04:41 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: Re: Syntax method of GEF extension definition > > Pete > Sorry for not responding earlier. I am one of those who > expressed concern for > this section of the document during the discussion in Porto > Seguro. I share > your concern about the difficulty of using ASN.1 for these > specification since > I struggled with learning the value specification form for > use in Annex R, but > I believe that your first method (Encoded in Raw Method) is > satisfactory for > this and is what we eventually used in Annex R. I also > believe that the table > method is suitable for simple cases of values without > structure. I am not > convinced that we need a third method and don't believe that > introducing a new > syntax specification language helps make this simpler. If > this method were > used in a future annex it requires all users to learn yet one more > specification language - no matter how well designed, this > adds considerably to > the difficulty of using that Annex. You suggest that since > it is optional > people are not obliged to use it, but if the author of an > Annex chooses to use > it all users of that annex now become obliged to. > > I have not analyzed your new language in detail, but new > languages (and > especially abstract ones) usually take considerable > time/effort before they are > complete and correct and documented unambiguously. Perhaps > you are better than > most language writers and admittedly this is not a large > language but I can > hardly believe that it will not take a few iterations before > it is "done". > > But even if the current form is perfect, my concern is > introducing yet one more > language for a task that has two simpler solutions that I > believe cover the > need. > > My vote is "it goes". > > Pete Cordell wrote: > > > Hi All, > > > > As you may know, the most recent version of H.GEF.1 > included a syntax based > > method of defining GEF extensions. I defined this so that > people wouldn't > > get confused with trying to interpret a syntax based > definition as pure > > ASN.1. My principle is, if you are defining something that > is different to > > something that is already used, then make it obviously different. > > > > I'm fairly comfortable that the syntax is complete. Also, > if people don't > > want to use that method of GEF definition they are not > obliged to. I > > personally would therefore like to keep it in. > > > > However, we live in a democracy. Therefore, the person > that gives me the > > highest bid can decide whether it stays or goes! > > > > Meanwhile, people can vote on whether it stays or goes by > e-mailing me > > directly. I will then summarise and post the results to > the list. In the > > event of a draw I'll keep it in. > > > > All the best, > > > > Pete. > > > > ============================================= > > Pete Cordell > > Tech-Know-Ware > > pete(a)tech-know-ware.com > > +44 1473 635863 > > ============================================= > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > -- > It's not a lie. It's a gift for fiction. > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: H.235 Security Blues
by Paul, Manoj 27 Jul '01

27 Jul '01

Hi Martin, You pointed out that it should be a matter of local policy whether to allow processing of messages that did not conform to the security norms. I think that's what I meant by "a-priori" mechanisms. I want to view this issue for H.235 Annex D. This annexure is applicable only in administered environments. Even the password used for hashing is known through subscription process for ex. Is it correct to say, then, that as a part of this subscription, an endpoint can make a local policy decision whether or not to expect all messages coming from GK in a secured manner? regards Manoj. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@icn.siemens.de] Sent: Friday, July 27, 2001 8:13 AM To: 'Paul, Manoj'; Euchner Martin; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Manoj, the scenario that you described refers to a mixed environment that should cope both with security (entities, protocols) and also with unsecured ones. It is true, that such mixed environments do not provide the same security level as a secure environment without any unsecured entities. The problem with mixed environments is, that a secure entity should also process insecure messages from untrusted entities but has no way to know where such unprotected messages really came from. This issue not new and security experts have always warned people to realize this. Let me note, that exactly this kind of discussion comes up, when people add security later on and seek some way how secure and insecure (= older) systems could interwork in a secure way. Thus, it is exactly this weakness of insecure systems that breaks the entire security. I understand that this situation is unsatisfactory, but we have to live with that as long as dual mode or mixed environments are the case. However, your idea using pre-configured security in the entities (in a mixed environment) would be equal to the situation where all entities have implemented security but no insecure one is permitted to participate (which would then be a non-mixed security environment). Thus, as you see, this is either a contradiction or impossible to fulfill and wouldn't help anyway. As a conclusion, no one should expect to obtain any better security in a mixed environment than in an unsecured environment. If you really want to improve, the only way to achieve this, is to abandon the insecure entities and replace them by secure ones or forbid the secured entities from accepting any insecure message. This however is matter of security policy in your operating environment. It is a local matter how you would or could enforce such a security policy in your systems. Using H.235 you have all the means to determine whether a message has been secured (through the OIDs) and also verify (by checking the cryptographic hash value) whether it origins from a trusted entity. This should be sufficient to decide whether or not to discard a message. Think about! Kind Regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@trillium.com] Sent: Wednesday, July 25, 2001 7:25 PM To: 'Euchner Martin'; Paul, Manoj; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Martin, Thanks for your reply. I have a small concern to the fact that GK should let the EP know of GK initiated message security aspects in security tokens. I think an endpoint should a-priori know if it expects messages (RAS and 225) from GK to contain security tokens and hash values. If endpoint determines this at run time using in-band mechanisms, it may potential fall pray to a hostile router which sends it an unsecured message pretending as a GK. An EP, in such a case, would have no way to determine if GK indeed wants it to send unsecured messages. I shall appreciate your comments. best regards Manoj. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@icn.siemens.de] Sent: Wednesday, July 25, 2001 1:31 AM To: 'Paul, Manoj'; Euchner Martin; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Manoj, the GK determines whether to apply mutual authentication; i.e. authenticate and integrity protect the RAS messages towards the EP. This is a matter of security policy and therefore something, that is a local matter. For security reasons, I would recommend applying mutual authentication instead on just single sided authentication. There is no need to negotiate this feature, as an endpoint can always recognize whether messages from the GK are secured or not. The EP does this by looking at the presence of the various OIDs in the security tokens. Missing OIDs = no security. Thus, this feature is always indicated in-band in each message. Kind Regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@trillium.com] Sent: Tuesday, July 24, 2001 7:55 PM To: 'Euchner Martin'; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Martin, Thanks for your response. I have an additional question under section D.6.3.1 of H.235V2. Second para of this section states that Gk decides whether to apply Auth/Int in the reverse direction as well. I could not find any IE in GRQ/GCF where GK could inform the endpoint if messages originating from GK will also contain hash values and that EPs should also auth/int them. Does GK tell endpoints to apply Auth/Int in reverse direction also by out-of band mechanisms (something during password subscription etc.)? thanks Manoj. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@ICN.SIEMENS.DE] Sent: Tuesday, July 24, 2001 9:39 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: H.235 Security Blues Manoj and experts, thanks for pointing out several points in H.235v2 that do deserve clarification. My answers are included below in the original text. I've also attached draft text for the H.323 Implementors Guide, that proposes clarifications and corrections. If you agree, I would send the text "officially" to our H.323 IG editor. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Thursday, July 19, 2001 9:15 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.235 Security Blues Experts, Could someone clarify following aspects of H.235 V2 Annex D (Baseline Security Profile). 1) Section D.2, last but second paragraph (This profile defines to....). According to this paragraph, the generalId field shall be set to the "called endpoint ID" for H225 signalling messages. Since the calls must be GK routed, shouldn't the generalId refer to the gkId for 225 messages sent by endpoints? Yes, correct. The GeneralID should always be the destination ID. Please see, the section in the Implementors Guide which corrects this. Even if it is the called epId, how the peer endpoint can ever know the called epId, since it does not appear ARQ/ACF messages? I'm not really sure whether I got your question here. When the EP does not have an identifier yet, as might occur in early RAS messages, then D.10 say to fill-in NULL instead. Section D.10 throws some insight into the usage of senderId and generalId, but it does it so only for RAS messages. Do you think it is necessary to make sendersID and generalID explicit in the table in D.9.2? There shouldn't be any exceptions such as in the case of RAS where 2) Section D.9.1 of H.235 V2 states the 225 UUIEs which shall contain cryptoTokens field. H.323 V4 has added new UUIEs (Status, Status Enquiry,...). Ooops, this actually has been an oversight and not any intentional. Of course, the additional H.323 V4 signaling messages such as Status, Status inquiry, Setup-ack and notify-UUIEs etc shall be covered and secured as well. And similar correction is also necessary for Annex E. The IG provides the necessary corrections. Does that mean that H.323 V4 can not possibly use H.235 V2? Absolutely not. H.323 v4 and H.225.0 V4 were designed in such a way that H.235v2 deployment is possible. best regards Manoj Paul. -----Original Message----- From: ssilvy(a)hss.hns.com [mailto:ssilvy@hss.hns.com] Sent: Thursday, May 31, 2001 9:26 PM To: mpaul(a)TRILLIUM.COM; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Hi, In case of initial RRQ when EPID is not available the table D.10 in H235v2 says that sendersID would be NULL. So the hash would be calculated with sendersID as NULL when the identification information i.e EPID is not available as in initial RRQ. Silvy. Nagesh Kumar B V 06/01/2001 10:40 AM To: Silvy Samuel/HSSBLR@HSSBLR, Ivan T Varghis/HSSBLR@HSSBLR cc: Subject: ---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001 09:46 AM --------------------------- "Paul, Manoj" <mpaul(a)TRILLIUM.COM> on 05/31/2001 06:35:31 PM Please respond to "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM cc: (bcc: Nagesh Kumar B V/HSSBLR) Subject: Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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.235 Security Blues
by Euchner Martin 27 Jul '01

27 Jul '01

Hi Manoj, the scenario that you described refers to a mixed environment that should cope both with security (entities, protocols) and also with unsecured ones. It is true, that such mixed environments do not provide the same security level as a secure environment without any unsecured entities. The problem with mixed environments is, that a secure entity should also process insecure messages from untrusted entities but has no way to know where such unprotected messages really came from. This issue not new and security experts have always warned people to realize this. Let me note, that exactly this kind of discussion comes up, when people add security later on and seek some way how secure and insecure (= older) systems could interwork in a secure way. Thus, it is exactly this weakness of insecure systems that breaks the entire security. I understand that this situation is unsatisfactory, but we have to live with that as long as dual mode or mixed environments are the case. However, your idea using pre-configured security in the entities (in a mixed environment) would be equal to the situation where all entities have implemented security but no insecure one is permitted to participate (which would then be a non-mixed security environment). Thus, as you see, this is either a contradiction or impossible to fulfill and wouldn't help anyway. As a conclusion, no one should expect to obtain any better security in a mixed environment than in an unsecured environment. If you really want to improve, the only way to achieve this, is to abandon the insecure entities and replace them by secure ones or forbid the secured entities from accepting any insecure message. This however is matter of security policy in your operating environment. It is a local matter how you would or could enforce such a security policy in your systems. Using H.235 you have all the means to determine whether a message has been secured (through the OIDs) and also verify (by checking the cryptographic hash value) whether it origins from a trusted entity. This should be sufficient to decide whether or not to discard a message. Think about! Kind Regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@trillium.com] Sent: Wednesday, July 25, 2001 7:25 PM To: 'Euchner Martin'; Paul, Manoj; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Martin, Thanks for your reply. I have a small concern to the fact that GK should let the EP know of GK initiated message security aspects in security tokens. I think an endpoint should a-priori know if it expects messages (RAS and 225) from GK to contain security tokens and hash values. If endpoint determines this at run time using in-band mechanisms, it may potential fall pray to a hostile router which sends it an unsecured message pretending as a GK. An EP, in such a case, would have no way to determine if GK indeed wants it to send unsecured messages. I shall appreciate your comments. best regards Manoj. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@icn.siemens.de] Sent: Wednesday, July 25, 2001 1:31 AM To: 'Paul, Manoj'; Euchner Martin; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Manoj, the GK determines whether to apply mutual authentication; i.e. authenticate and integrity protect the RAS messages towards the EP. This is a matter of security policy and therefore something, that is a local matter. For security reasons, I would recommend applying mutual authentication instead on just single sided authentication. There is no need to negotiate this feature, as an endpoint can always recognize whether messages from the GK are secured or not. The EP does this by looking at the presence of the various OIDs in the security tokens. Missing OIDs = no security. Thus, this feature is always indicated in-band in each message. Kind Regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@trillium.com] Sent: Tuesday, July 24, 2001 7:55 PM To: 'Euchner Martin'; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Martin, Thanks for your response. I have an additional question under section D.6.3.1 of H.235V2. Second para of this section states that Gk decides whether to apply Auth/Int in the reverse direction as well. I could not find any IE in GRQ/GCF where GK could inform the endpoint if messages originating from GK will also contain hash values and that EPs should also auth/int them. Does GK tell endpoints to apply Auth/Int in reverse direction also by out-of band mechanisms (something during password subscription etc.)? thanks Manoj. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@ICN.SIEMENS.DE] Sent: Tuesday, July 24, 2001 9:39 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: H.235 Security Blues Manoj and experts, thanks for pointing out several points in H.235v2 that do deserve clarification. My answers are included below in the original text. I've also attached draft text for the H.323 Implementors Guide, that proposes clarifications and corrections. If you agree, I would send the text "officially" to our H.323 IG editor. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Thursday, July 19, 2001 9:15 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.235 Security Blues Experts, Could someone clarify following aspects of H.235 V2 Annex D (Baseline Security Profile). 1) Section D.2, last but second paragraph (This profile defines to....). According to this paragraph, the generalId field shall be set to the "called endpoint ID" for H225 signalling messages. Since the calls must be GK routed, shouldn't the generalId refer to the gkId for 225 messages sent by endpoints? Yes, correct. The GeneralID should always be the destination ID. Please see, the section in the Implementors Guide which corrects this. Even if it is the called epId, how the peer endpoint can ever know the called epId, since it does not appear ARQ/ACF messages? I'm not really sure whether I got your question here. When the EP does not have an identifier yet, as might occur in early RAS messages, then D.10 say to fill-in NULL instead. Section D.10 throws some insight into the usage of senderId and generalId, but it does it so only for RAS messages. Do you think it is necessary to make sendersID and generalID explicit in the table in D.9.2? There shouldn't be any exceptions such as in the case of RAS where 2) Section D.9.1 of H.235 V2 states the 225 UUIEs which shall contain cryptoTokens field. H.323 V4 has added new UUIEs (Status, Status Enquiry,...). Ooops, this actually has been an oversight and not any intentional. Of course, the additional H.323 V4 signaling messages such as Status, Status inquiry, Setup-ack and notify-UUIEs etc shall be covered and secured as well. And similar correction is also necessary for Annex E. The IG provides the necessary corrections. Does that mean that H.323 V4 can not possibly use H.235 V2? Absolutely not. H.323 v4 and H.225.0 V4 were designed in such a way that H.235v2 deployment is possible. best regards Manoj Paul. -----Original Message----- From: ssilvy(a)hss.hns.com [mailto:ssilvy@hss.hns.com] Sent: Thursday, May 31, 2001 9:26 PM To: mpaul(a)TRILLIUM.COM; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Hi, In case of initial RRQ when EPID is not available the table D.10 in H235v2 says that sendersID would be NULL. So the hash would be calculated with sendersID as NULL when the identification information i.e EPID is not available as in initial RRQ. Silvy. Nagesh Kumar B V 06/01/2001 10:40 AM To: Silvy Samuel/HSSBLR@HSSBLR, Ivan T Varghis/HSSBLR@HSSBLR cc: Subject: ---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001 09:46 AM --------------------------- "Paul, Manoj" <mpaul(a)TRILLIUM.COM> on 05/31/2001 06:35:31 PM Please respond to "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM cc: (bcc: Nagesh Kumar B V/HSSBLR) Subject: Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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.323 (8.1) Phase A - Call Setup
by Peter Price 27 Jul '01

27 Jul '01

Paul, I don't feel this tread reached a conclusion. The last comment I saw from you was that the intent was alerting. I asked on July 20 (see below) why that was the intent and received no reply. I also commented in a separate email about you last paragraph > > The ideas are related, but independent. What we have seen some folks do is > > send a Call Proceeding to the caller and then nothing else until the > > connect. The result is that the calling party hears silence for a very long > > time: that's not good. We both agree Alerting should be sent to the caller as soon as the callee's phone is ringing but the text opens the door for someone to send Call Proceeding and then not ever send Alerting. It becomes clearer to me that the original intent was almost certainly "If an endpoint can respond to a Setup message with a Connect within 4 seconds, it is not required to send the Alerting message." Reference to Call Proceeding is incorrect and to Release Complete irrelevent. So was this latter interpretation what was really intended or is my original suggestion that the text should have refereed to Call Proceeding still valid? Thanks Peter > -----Original Message----- > From: Peter Price > Sent: 20 July 2001 14:03 > To: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: RE: H.323 (8.1) Phase A - Call Setup > > > Paul, > > I don't understand why the intent was Alerting. > > "If an endpoint can respond to a Setup message with a > Connect, Call Proceeding, or Release Complete within 4 > seconds, it is not required to send the Alerting message." > > Why, if an endpoint can respond to a Setup with a Call > Proceeding within 4 seconds, should it not have to send the > Alerting? How will the user get a ringing sound in his ear then? > > I know that Alerting (and Connect) also stops T303. > However, in Table 9-1/Q.931 (refernced by H.225 (7.5)), > receipt of an Alerting starts T301, while receipt of Call > Proceeding starts T310. I realise that T310 is not > explicitly required by H.323 but the second para of (8.1.8.2) > implies that the mechanism it represents IS required (I know > its says should and not shall - perhaps this is a second error) > > "A Gateway should send a Call Proceeding message after it > receives the Setup message (or after it receives ACF) if it > expects more than 4 seconds to elapse before it can respond > with Alerting, Connect, or Release Complete." > > The specific reason for sending Call Proceeding here is to > stop T303 timing out and the call failing. > > The point is that for H.323 endpoints Call Proceeding is > superfluous, if a terminal device cannot respond with an > Alerting or Release Complete within 4 seconds it has problems > [ or it's running windows (-; ] and the call probably should > fail. However, gateways are different. If they interface to > a large network then the Alerting must not be sent to the > caller until an appropriate message has been received [ also > in (8.1) "In the case of interworking through a Gateway, the > Gateway ***shall send Alerting when*** it receives a ring > indication from the SCN." ie WHEN it receives the ring > indication and not before ] and this might take longer than 4 > seconds - hence the need for gateways to send Call Proceeding > and the relevance of 4 seconds in the sentence in question. > > My original assertion that the text in (8.1) is incorrect stands. > > "If an endpoint can respond to a Setup message with a > Connect, Alerting, or Release Complete within 4 seconds, it > is not required to send the Call Proceeding message." > > Alternatively, if an endpoint *cannot* respond to a Setup > message with a Connect, Alerting, or Release Complete within > 4 seconds, it *should* (shall?) send a Call Proceeding message. > > The only other interpretation I can come up with is that the > intent was > "If an endpoint can respond to a Setup message with a Connect > within 4 seconds, it is not required to send the Alerting message." > If it responds with a Release Complete within 4 seconds it's > not going to send an Alerting! > > I've just seen Chris's reply as well - I think my > observations still stand. > I think in fact that the whole paragraph is poorly > structured, mixing a number of different ideas. > I was juts trying to suggest the simplest change. > > Peter > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > > Sent: 20 July 2001 12:48 > > To: ITU-SG16(a)mailbag.cps.INTEL.COM > > Subject: Re: H.323 (8.1) Phase A - Call Setup > > > > > > Peter, > > > > Alerting was the intent. Call Proceeding not produce a > > ringing sound in the > > caller's ear. H.323 devices have to be able to send an > > Alerting, though > > they're not required to do so if they can send a Connect > > within 4 second. > > The 4 seconds is the T303 timeout and the T303 timer is > disabled when > > receiving Alerting, too... not just Call Proceeding. > > > > The ideas are related, but independent. What we have seen > > some folks do is > > send a Call Proceeding to the caller and then nothing else until the > > connect. The result is that the calling party hears silence > > for a very long > > time: that's not good. > > > > Paul > > > > ----- Original Message ----- > > From: "Peter Price" <PeterP(a)VEGASTREAM.COM> > > To: <ITU-SG16(a)mailbag.cps.INTEL.COM> > > Sent: Friday, July 20, 2001 6:54 AM > > Subject: H.323 (8.1) Phase A - Call Setup > > > > > > > Hi folks, > > > > > > I think I may have found some incorrect text in H.323 8.1 > > > > > > The same text appears in both V3 and V4 so I suspect nobody > > has commented > > > before. > > > > > > In the paragraph beginning: > > > "An endpoint shall be capable of sending the Alerting > message. ..." > > > > > > it goes on to say: > > > "If an endpoint can respond to a Setup message with a > Connect, Call > > > Proceeding, or Release Complete within 4 seconds, it is not > > required to > > send > > > the Alerting message. An endpoint sending the Setup message > > can expect to > > > receive either an Alerting, Connect, Call Proceeding, or > > Release Complete > > > message within 4 seconds after successful transmission." > > > > > > I believe the first sentence here should really be discussing the > > > requirement to send a Call Proceeding (not Alerting) message. > > > The period of 4 seconds in the last sentence is related to > > T303 which is > > > specifically terminated by a Call Proceeding message in > > order to extend > > the > > > timeout for the sending endpoint. > > > > > > I think the sentence should read: > > > "If an endpoint can respond to a Setup message with a > > Connect, Alerting, > > or > > > Release Complete within 4 seconds, it is not required to > > send the Call > > > Proceeding message." > > > > > > This is then consistent with the use of Call Proceeding > described in > > 8.1.8.2 > > > (second para). > > > > > > Peter Price > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > 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

Package Dependencies
by Tom-PT Taylor 27 Jul '01

27 Jul '01

I have an interesting situation with the Advanced Audio Server packages (H.248 Annex M.1), and I wanted to check out my proposed solution with the list. The "basic" package currently consists of three functions: play, play and collect digits, and play and collect a recording. It also includes an extensive description of a syntax for specifying individual announcements, including variable elements. This syntax appears to the Megaco/H.248 grammar as a parameter VALUE in quotedString form. One "advanced" package defined in the current draft Annex doesn't change any of the functions, but extends the announcement-specifying syntax. Using past practice as a guide, the package was modelled as an extension of the basic one. However, note that the new functionality is actually hidden below the level that would normally distinguish an extension -- no new signals or events are added, and no new parameters are added. (That last wouldn't be legal in any event.) However, this approach doesn't really work. The first sign of trouble was when I thought to split up the play, play-and-collect, and play-and-record functions, both to clarify the functional definitions and because it would provide more flexibility for product implementation. How would I introduce the "advanced" syntax for each function? Do I need to define an "advanced" package for each, so that the two packages become six? It becomes worse now that more than one advanced syntax feature has been proposed. I now need a package for the basic announcement syntax, one for that plus feature A, one for that plus feature B, and a fourth one for all three features together. You get the idea: an exponential explosion, multiplied by the number of functions if we decide to split them. I have an answer to this, but I thought it might be a good idea to legitimize it. It could even lead to a v2 formalization of the process if accepted (with no change in what goes out over the wire!). My proposal is this: 1) We define the announcement specification syntax itself in a package of its own. Note that this package will have none of the usual content -- no properties, signals, events, or statistics. 2) We define each additional feature of the announcement specification syntax in another package which is an extension of the basic syntax package. 3) Within the functional packages (play, play-and-collect, etc.) we say first that the package USES the syntax of the basic syntax package and secondly that if any extension of the basic syntax package is supported the functional package also USES that extension. An implication is that if a device supports an advanced syntactical feature (e.g. sets) for one function it MUST support that feature for all of the functions it implements. Comments? Is this a legitimate use of packaging? Should we add the USES relationship to our section 12 package description requirements in v2? Please copy follow-ups to the Megaco list, now at megaco(a)ietf.org. Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490)

2 1

You Can Too #539D
by Frank Jerwin 26 Jul '01

26 Jul '01

***** This is an HTML Message ! *****

1 0

Re: H.235 Security Blues
by Euchner Martin 26 Jul '01

26 Jul '01

Hi Manoj, there is always the risk of denial-of-service attacks where any response message with some security hints were maliciously deleted, would leave the EP in uncertainty. I do not see a way how such attacks could be effectively be prevented at an application level. Implementation should be prepared of such losses. However, when we put the denial-of-service issues to the side, there is at least some way, how the EP obtains some security status information from the GK. This is as you described when the GK would send a FACILITY with reason code indicating a security failure. This appears as a reasonable solution. I do not see particular benefit, to make any exceptional distinction with the processing of manipulated RELEASE COMPLETE against any other manipulated H.225.0 message, where you proposed not to send back a FACILITY? I would safely propose that the GK drops such a RELEASE COMPLETE and responds with a FACILITY + securitydenial as in any other case. Finally, I can see some value in that the EP can align a FACILTY with security reason to the failed call signaling message. I'm not so certain whether there is really a need to distinguish the individual messages with the FACILITY message. This would have to be signaled explicitly somewhere in the message. At present, my impression is that H.225.0 does not provide such an explicit signaling capability. On the other hand, there is probably no need for adding fields to H.225.0. Assuming TCP transport, the EP should be able to relate such a FACILITY + securitydenial with the pending call signaling message and its state. Any other FACILITY message received with security denial which is unrelated to any unsent call signaling message should be treated by the EP as an attack. This could be implemented without changes to the standard. The only item I hear, is to make the procedure for the GK obvious, to respond with a FACILITY + security denial in case of security failures. This should be described more precisely in the Implementors Guide, I agree. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@trillium.com] Sent: Wednesday, July 25, 2001 7:36 PM To: 'Euchner Martin'; Paul, Manoj; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Martin, The only problem I see with that approach is that the endpoint shall have no way to find the reasons for not getting a response from GK. If someway could be found to make EP know that it;s last message could not pass the security tests, it may be able to take a recovery action. (As it happens with RAS messages). Do you think GK can send FACILITY with reason SecurityDenied to the endpoint when it gets a call signalling message which fails security test. GK can silently drop that message but sends FACILITY to the endpoint, except when the incoming 225 message failing the security test is RELEASE COMPLETE. Although, the endpoint shall become aware of the reason for GK dropping it's messages, it shall still have no way to distinguish which call signalling message failed the security test. What do you suggest? best regards Manoj. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@icn.siemens.de] Sent: Wednesday, July 25, 2001 7:50 AM To: 'Paul, Manoj'; Euchner Martin; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Manoj, The issue with security denial is correct as you stated it. For RAS, sending a reject message with security denial as reason code should work. What is not clearly specified in H.235 at the moment is, what to do with security failures during call signaling. If one would reply with ReleaseComplete and similar security reason code indicated, an attacker could very easily launch a denial-of-service attack and make the peer call signaling entity drop the call. That is probably not what we want with security. Thus, I'm really hesitating to add a sentence to H.235 saying that whenever a secured call signaling message such as Connect with invalid security has been received, ReleaseComplete with security denial should/shall be sent. I pretty much prefer a much simpler yet more secure variant: Instead of replying with a message in case of failure, it should be sufficient for the recipient to discard the illegal message and for the sender to obtain a timeout and then try again. I think, that I should add a similar statement to D.6.3.1. Do you agree? With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@trillium.com] Sent: Tuesday, July 24, 2001 8:53 PM To: 'Euchner Martin'; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Experts, As I work through H.235, questions are popping to me. May be I should pack them in one e-mail and send it on reflector next time. My question is more to do with the procedure when Auth/Int on a H225 message fails. Clause D.6.3.1 of H.235 V2 states that GK should send a correponding Reject message with SecurityDenial reason. That may work fine for RAS, but for H.225 messages, the only way would be to send Release Complete to the peer with reason as SecurityDenied. Is that so? If yes, then doesn't it allows a hostile router to force GK/endpoint to release the established calls by sending it spurious messages? best regards Manoj Paul. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@ICN.SIEMENS.DE] Sent: Tuesday, July 24, 2001 9:39 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: H.235 Security Blues Manoj and experts, thanks for pointing out several points in H.235v2 that do deserve clarification. My answers are included below in the original text. I've also attached draft text for the H.323 Implementors Guide, that proposes clarifications and corrections. If you agree, I would send the text "officially" to our H.323 IG editor. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Thursday, July 19, 2001 9:15 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.235 Security Blues Experts, Could someone clarify following aspects of H.235 V2 Annex D (Baseline Security Profile). 1) Section D.2, last but second paragraph (This profile defines to....). According to this paragraph, the generalId field shall be set to the "called endpoint ID" for H225 signalling messages. Since the calls must be GK routed, shouldn't the generalId refer to the gkId for 225 messages sent by endpoints? Yes, correct. The GeneralID should always be the destination ID. Please see, the section in the Implementors Guide which corrects this. Even if it is the called epId, how the peer endpoint can ever know the called epId, since it does not appear ARQ/ACF messages? I'm not really sure whether I got your question here. When the EP does not have an identifier yet, as might occur in early RAS messages, then D.10 say to fill-in NULL instead. Section D.10 throws some insight into the usage of senderId and generalId, but it does it so only for RAS messages. Do you think it is necessary to make sendersID and generalID explicit in the table in D.9.2? There shouldn't be any exceptions such as in the case of RAS where 2) Section D.9.1 of H.235 V2 states the 225 UUIEs which shall contain cryptoTokens field. H.323 V4 has added new UUIEs (Status, Status Enquiry,...). Ooops, this actually has been an oversight and not any intentional. Of course, the additional H.323 V4 signaling messages such as Status, Status inquiry, Setup-ack and notify-UUIEs etc shall be covered and secured as well. And similar correction is also necessary for Annex E. The IG provides the necessary corrections. Does that mean that H.323 V4 can not possibly use H.235 V2? Absolutely not. H.323 v4 and H.225.0 V4 were designed in such a way that H.235v2 deployment is possible. best regards Manoj Paul. -----Original Message----- From: ssilvy(a)hss.hns.com [mailto:ssilvy@hss.hns.com] Sent: Thursday, May 31, 2001 9:26 PM To: mpaul(a)TRILLIUM.COM; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Hi, In case of initial RRQ when EPID is not available the table D.10 in H235v2 says that sendersID would be NULL. So the hash would be calculated with sendersID as NULL when the identification information i.e EPID is not available as in initial RRQ. Silvy. Nagesh Kumar B V 06/01/2001 10:40 AM To: Silvy Samuel/HSSBLR@HSSBLR, Ivan T Varghis/HSSBLR@HSSBLR cc: Subject: ---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001 09:46 AM --------------------------- "Paul, Manoj" <mpaul(a)TRILLIUM.COM> on 05/31/2001 06:35:31 PM Please respond to "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM cc: (bcc: Nagesh Kumar B V/HSSBLR) Subject: Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: FastStart in Call Proceeding
by Francois Audet 25 Jul '01

25 Jul '01

In the FACILITY message. It is described somewhere in H.225.0 and H.323. Look in version 4 (It might also be in v3, but I don't remember). -----Original Message----- From: Shan Lu [mailto:slu@NEXTONE.COM] Sent: Wednesday, July 25, 2001 10:47 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: FastStart in Call Proceeding Hi all, I have a question when the FastStart element is returned in the Call Proceeding message by the called EP. The problem arises when a GK is routing the signalling and let's further assume that the GK has already sent a Call Proceeding to the calling EP before the Call Proceeding from the called EP arrives. How is the GK supposed to do to relay the FastStart element to the calling EP asap? Another call proceeding? Facility? You have the same issue even without FastStart. Say the call proceeding may contain the called EP's H245 address which the GK should send to the calling EP right away. Appreciate any responses. Regards, Shan Lu NexTone Communications ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

FastStart in Call Proceeding
by Shan Lu 25 Jul '01

25 Jul '01

1 0