That's one way of doing it, but CallProceeding is not an end-to-end message, so it's conceptually wrong. How hard is it for your gatekeeper to translate between tunnelling and non-tunnelling? Another reasonable way of doing it is always to respond that tunnelling IS possible, and do the translation in the gatekeeper.

Regards, Chris

danlee@YNNMAIL.COM wrote:

According to ver.4 "If the called entity does not yet know if H.245 tunneling can be supported, it shall include the provisionalRespToH245Tunneling flag. This may happen, for example, when a Gatekeeper is responding to a calling entity with a message such as Call Proceeding before the called endpoint responds to the h245Tunneling flag. "

The problem arises when the calling entity does not support this flag (i.e., does not yet support ver.4). E.g.,

1. Calling entity (let's say ver.3 EP) is sending Setup with indication of the

tunneling support. 2. The gatekeeper answers with Call Proceeding including h245Tunneling ==False and provisionalRespToH245Tunneling ==True. 3. The calling entity (that was implemented BEFORE ver.4) will understand this as "tunneling is not supported". 4. But the called entity can send tunneled messages.

What we've decided is:

1. To check the supported version of the calling EP.
2. If the version is >=4 than above scenario may be used.
3. Otherwise Call Proceeding will be delayed until getting the information from

the called EP.

---

Join YnnMail at http://www.ynnmail.com and get your free secure e-mail and 40,000+ newsgroup...

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@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@mailbag.intel.com