All,

ECMA 333 defines the mapping functions for tunneling QSIG over H.323 networks. It describes two scenarios, on-demand and semi-permanent. In on-demand each new ISDN call is tunneled through a separate H.323 call. In semi-permanent multiple ISDN calls can be tunneled through a single H323 call.

10.2.4/H323 V4 describes the mechanism for tunneling ISDN protocols within H323 calls. However, this only ssems to cover the on-demand scenario. It does not include any procedures for the establisment of the additional RTP streams that will be required to support multiple calls.

Obviously the existing logical channel procedures can be used to actually open the channels - thats not the problem.

ECMA 333 states that the Channel ID IE in the tunneled messages should contain the H.323 session id of the logical channel to be used for the audio stream. This isn't a problem for on-demand, there is only one voice channel and it uses the well-known session id 1.

However there are multiple active channels whenn using semi-permanent and the problem is that the session ID is allocated by the H.323 master - what happens if you want to originate a call from the H.323 slave - what do you put in the tunneled ISDN SETUP message?

Is this actually covered anywhere or does it need something in H.323? Is there any work in progress within the standards community to cover this issue? Any other commnents?

Thanks

Peter Price Principal Software Engineer Vegastream, a division of Pace Micro Technology plc

Enabling Digital. Our Vision is to be the biggest supplier worldwide of digital gateway technology.

Tel: +44 1344 784914 Fax: +44 1344 784901 Berkshire Court, Western Road, Bracknell, Berkshire. RG12 1RE www.pace.co.uk www.vegastream.co.uk

This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com