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.,
- 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:
- To check the supported version of the calling EP.
- If the version is >=4 than above scenario may be used.
- 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