Tunneling ISDN - semi-permanent scenario

[Peter Price]

Peter,

I assume that you are referring to 9.3.2/ECMA-333 and 11.2/ECMA-333.
In 9.3.2/ECMA-333, it is stated that the Uq-channel number is used
as the session identifier and not the other way around, but this is
a only a trivial matter.

Your concern seems to be the fact that the "H.245 slave" can
establish a QSIG call and therefore tunnel a QSIG SETUP message, but
it is not in control over the H.245 session identifier: H.245 states
that the session identifier can only be created by the master.

When the slave opens its logical channel towards the master it will
specify a session identifier with the value 0. In the
OpenLogicalChannelAck message, the master will provide the session
identifier that is to be used for this session. If the master
overruled the Uq-channel number, it will return this number as the
session identifier. If the master accepted the Uq-channel number
that was proposed by the slave, it will return this number as the
session identifier.

So, unless I don't quite understood you concerns, I do not see any
real problems.


Regards,

Frank

-----------------------------------------------------
Frank Derks                    |Tel  +31 35 6893238 |
APPlications                   |Fax  +31 35 6891290 |
Philips Business Communications|P.O. Box 32         |
                               |1200 JD  Hilversum  |
                               |The Netherlands     |
----------------------------------------------------|
E-mail: mailto:frank.derks at philips.com              |
WWW: http://www.sopho.philips.com                   |
-----------------------------------------------------









Peter Price <PeterP at VEGASTREAM.COM>
Sent by:
Mailing list for parties associated with ITU-T Study Group 16
<ITU-SG16 at echo.jf.INTEL.COM>
2003-02-06 11:53
Please respond to Peter Price


        To:     ITU-SG16 at echo.jf.INTEL.COM
        cc:     (bcc: Frank Derks/HVS/BE/PHILIPS)
        Subject:
        Classification:



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 at lists.intel.com

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