EndSessionCommand?

Paul E. Jones paulej at PACKETIZER.COM
Fri Apr 13 02:18:41 EDT 2001


Manoj,

The H.245 Control Channel always exists when endpoints exchange H.245
message: the Control Channel may be separate or tunnelled.

To answer your question: yes, the end session command must be sent as it
would normally be sent: tunneling H.245 does not change any procedure
related to H.245 communication.

With that said: there are good reasons why we might want to lift that
requirement.  Sending a Release Complete is a pretty good indicator to shut
down media and clean up the call :)

Paul

----- Original Message -----
From: "Paul, Manoj" <mpaul at TRILLIUM.COM>
To: <ITU-SG16 at mailbag.cps.INTEL.COM>
Sent: Thursday, April 12, 2001 10:07 PM
Subject: EndSessionCommand?


> Hi,
>
>   Does an endpoint using Tunnelling to exchange H.245 messages with peer,
> need
> to send EndSessionCommand message during call termination?
>   There are two different texts relating to this:
>
> H.245 Specification(V7), Section B.13.4:
>   "This command indicates the end of the h245 session. After tx
> EndSessionCommand,
> the terminal shallnot send any more of the messages defined in this
> Recommendation".
>
> H.323 Specification (V4), Section 8.5: Phase E-Call Termination
> "..It shall transmit H.245 endSessionCommand message in the H.245 Control
> Channel..."
>
> First statement seems to indicate that notwithstanding how H.245 messages
> are
> exchanged, an EndSessionCOmmand should be sent to stop any further
exchange.
> Second statement seems to mean that EndSessionCommand is sent only when
> H.245
> Control Channel exists (tunnelling not used).
>
> Could someone clarify?
> thanks
> Manoj Paul.
> Trillium Digital Systems.
>
> -----Original Message-----
> From: Nehru, Archana [mailto:archie at TRILLIUM.COM]
> Sent: Thursday, April 12, 2001 5:34 PM
> To: ITU-SG16 at mailbag.cps.INTEL.COM
> Subject: H.323 v1 problem
>
>
> hi all,
>
> I have a doubt about ARQ message in H.323 -V1.  The H.323 specs for V1 say
> that "srcCallSignalAddress" and "destCallSignalAddress" are optional. But
> there were some mails exchanged somtime back on the mailing list which
said
> that these two fields are MANDATORY for v1, since without these fields it
is
> not possible to identify a call in H.323 V1.
>
> E.g:
> Let us say we have an endpoint EP1, and EP2 and a GK and a call is
> Gk-routed.
> When EP1 wants to make a connection to EP2, it finishes RAS with GK and
then
> sends a SETUP to GK. When EP2 receives the incoming SETUP from the GK, it
> send an ARQ to the GK. At this point the Gk needs to identify the "call "
> associated with the incoming ARQ. As there was no "callId" in V1, the only
> parameters that can give the GK a clue are the "srcCallSignalAddress" and
> "destCallSignalAddress" tuple. But if these are treated optional, then
what
> parameters can the GK use to find the "associated call"?
>
> I believe for this reason it was suggested that  "srcCallSignalAddress"
and
> "destCallSignalAddress" would always be present in ARQ from a V1. Can
> someone please confirm this?.
>
> Many thanks,
> -Archana
>
> Archana Nehru,
> Engineering Project Manager,
> Trillium Digital Systems Inc., an Intel Company.
> http://www.trillium.com
> Ph:310-481-5525
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>

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



More information about the sg16-avd mailing list