Contribution number

Sakae OKUBO okubo at GITI.WASEDA.AC.JP
Mon Jul 17 22:37:08 EDT 2000


I'm not sure if anyone still does it, but some switches used to use
one-byte CRVs.  A note about mapping 8 bit CRVs to 16 bit CRVs might be useful.

For example,
"If the CRV in the Q.931 message is only 8 bits, the CRV Flag is mapped to
the 16th bit of the Session Field and bits 1-7 of the original CRV are
mapped to bits 1-7 of the Session Field.  The remaining bits are set to zero."

But perhaps this is already present.

Chip

At 02:41 AM 7/3/00 -0400, Paul E. Jones wrote:
>Sasha,
>
>As you stated, the flag bit in the session field of Annex E/H.323 messages
>shall be set to the same value as the CRV in the Q.931 message found in the
>payload.
>
>Would you like to propose clarifying text?  I'll put it into the IG for
>review in Portland.
>
>Paul
>
>----- Original Message -----
>From: "Sasha Ruditsky" <sasha at TLV.RADVISION.COM>
>To: <ITU-SG16 at mailbag.cps.intel.com>
>Sent: Sunday, July 02, 2000 12:01 PM
>Subject: Annex E Question.
>
>
> > > Hi
> > >
> > > I believe that the following paragraph from the H.323 Annex E may be
> > > understood differently by different people:
> > > -------
> > > E.2.3.5       Session field
> > > The session field shall be present in all payloads. The Session value
> > > shall contain the CRV from the Q.931 messages. Specifically, the call
> > > reference flag shall be included as the most significant bit of the
> > > CallReferenceValue. This restricts the actual CRV to the range of 0
> > > through 32767, inclusive.
> > > -------
> > >
> > > I think this means that the Annex E session field is different (in the
> > > Flag bit) for Setup and Connect messages of the same call. (Exactly like
> > > CRV is).
> > > I agree that the alternation of the 16th bit of the Annex E session
>field
> > > in the messages of the same session (call) moving in different
>directions
> > > is required,
> > > but I do not think that the described behavior is obvious from the
>field's
> > > name and its description.
> > >
> > > If there is agreement on the fact that the messages belonging to the
>same
> > > call but moving in opposite directions shall have different values of
>the
> > > 16th bit  of the Annex E session field, that probably we need to state
> > > this explicitly in the E.2.3.5. I agree that this is ALMOST what is
> > > written their, but we all know how ambiguous may be the CRV-like field
> > > description.
> > >
> > >
> > > Sasha
> > >
> > > ***********************************************
> > > Alexander(Sasha) Ruditsky
> > > RADVision Ltd.
> > > 24 Raul Wallenberg St.
> > > Tel Aviv 69719  Israel
> > >
> > > Tel:       +972-3-645-5220
> > > Fax:       +972-3-645-6464
> > > Direct:    +972-3-645-5273
> > > sasha at radvision.rad.co.il
> > > ***********************************************
> > >
> > >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 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


-------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Change it.
http://www.netaid.org
-------------------------------------------------------------------

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