Tunneling ISDN - semi-permanent scenario

[Peter Price]

Frank,

I've added the subject line that I forgot on the original posting.

thanks for your reply but I still don't see how it all works.
I'm either missing something fundamental or there really is a need for this
to be covered in H.323.

> 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.

You have the correct references, but I think a minor mis-interpretation.
9.3.2/ECMA-333 says the pair of logical channels shall be established and
then it says that the session numnber shall be used as the Uq-channel
number. In other words the session number is determined before the
Uq-channel number.

This means that when a QSIG SETUP is received by a gateway that is going to
tunnel using the semi-permanent scenario an exchange of H.323 messages must
occur to establish the RTP streams and hence the session number before it is
possible to forward the QSIG SETUP with the correct Uq-channel number
through the H323 tunnel.

The gateway that received the SETUP can only establish the RTP stream in one
direction.  The RTP stream in the other direction must be initiated by the
destination gateway.  If that destination gateway is the H.323 slave how
does it ensure that it achieves the same session number for the return
channel (consider the possibility of multiple QSIG calls arriving at the
gateway simultaneously).  11.2/ECMA-333 Note 2 is a reminder that each
gateway/PINX must open its own tx channel.

The only way I can think of to ensure both RTP streams have matching session
numbers is for the original OLC to be initiated from the slave so that the
master can assign the session number and immediately open a return channel
with the same session number.

So now the question becomes - what if the QSIG SETUP is originally received
at the master gateway.  What message does it send to the remote gateway?

Hence my original questions.  Or alternatively - what am I missing?

Regards
Peter



> -----Original Message-----
> From: frank.derks at philips.com [mailto:frank.derks at philips.com]
> Sent: 10 February 2003 18:10
> To: Peter Price
> Cc: ITU-SG16 at echo.jf.INTEL.COM
> Subject: Re:
>
>
> 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