H.225- CRV

[Chris Wayman Purvis]

Paul,

> Considering that V1 only allowed a single call over a single TCP connection,
REALLY?
First I've heard of it!  Clarifications were added later as to the mechanics,
but I don't believe multiple calls over single call signalling connection was
ever forbidden!

> what would have been the point of a CRV in the Setup message?  If they could
> all be the same, it makes them worthless.  (Of course, I've found CRVs in
> packet-switched systems mostly worthless, but not entirely.)
It was part of a job lot stolen from Q.931, remember!
Besides, I'm surprised at you suggesting that nothing in H.323v1 was
worthless...

> From H.323:
> ``One CRV is used to associate the call signalling messages. This CRV shall
> be used in all call signalling messages between two entities (endpoint to
> Gatekeeper, endpoint-to-endpoint, etc.) related to the same call.''
> 
> Note the text that says "between two entities".  If the intent was that
> these values were only unique "per connection", it would say so.  The CRVs
> are unique between two entities.
Yup.  All messages between two given entities associated with a given call have
the same CRV.  That does not imply that all messages between two given entities
with the same CRV are associated with the same call (i.e. => is not the same as
<=).

> From H.225.0:
> ``Note that the CRV is only unique on a particular part of a call, e.g.
> between two terminals, or between a terminal and a gatekeeper. If a given
> terminal has two calls in the same conference, each shall have the same
> conference ID but different CRVs.''
> 
> The latter sentence is more important: when communicating between two
> entities, it states clearly that there must be different CRVs.  Again, with
> V1 those two calls would have been using different TCP connections, yet the
> text clearly says the CRVs must be different.
This is much more pertinent!
It's also impossible to be certain about.  What constitutes a different
"terminal" in this context?  For example, if a single piece of equipment has
two IP addresses, is it one terminal or two?

> Now, I may be wrong-- this is just my interpretation of the text.  I'd like
> to hear other comments.
It's opened a can of worms, for sure.
Maybe CRV is only unique per combination of IP addresses, ignoring port
numbers.  Seems strange to me, but possible.  I really don't recall anything
ever having said that only a single call was allowed per TCP call signalling
connection, however.

Philosophical question (not seriously intended for detailed discussion):
If the call signalling connection were dropped (still, I believe, permitted,
although not recommended), and a fresh call signalling connection made between
the same address/port pairs, is this the same connection?  Are these the same
endpoints as those involved in the initial call?  Consider a signalling proxy
(no media, doesn't handle H.245 directly within the same box on the same IP
address), which crashes, and has its IP address taken over by a similar
signalling proxy, all while a "call" is going on...

Regards,
Chris

> ----- Original Message -----
> From: "Chris Wayman Purvis" <cwp at isdn-comms.co.uk>
> To: "Paul E. Jones" <paulej at packetizer.com>
> Cc: <ITU-SG16 at mailbag.cps.intel.com>
> Sent: Tuesday, January 16, 2001 5:16 AM
> Subject: Re: H.225- CRV
> 
> > Paul,
> >
> > I disagree.  CRV is surely unique per connection.
> > One may be well advised to keep it more unique than that, because in
> > gatekeepered environments you're liable to end up with problems if you're
> not
> > careful because of your note 1 - but if I receive Q.931 messages on
> separate
> > TCP connections giving the same CRV I shouldn't expect them to refer to
> the
> > same call.  I argue that this is rooted in the principal of
> TransportAddress
> > throughout the H.323 standards including the SAPI (IP port number) as well
> as
> > actual address.
> >
> > Regards,
> > Chris
> >
> > "Paul E. Jones" wrote:
> > >
> > > Archana,
> > >
> > > (a) is closer to the way things actually work.
> > >
> > > Essentially, you can use whatever values you wish so long as you never
> place
> > > two calls to the same endpoint using the same CRV value.  So, whether
> two
> > > calls to an endpoint use the same TCP connection or different
> connections,
> > > the CRV must be unique.
> > >
> > > You should also consider the possibility that an endpoint may have two
> call
> > > signaling addresses.  How would you know if this were the case?  The
> safest
> > > thing to do is never have two calls with the same CRV at the same time.
> > > However, if you know that the destination endpoints are unique, you
> could
> > > re-use the CRV value.. at least when a Gatekeeper is not being used.
> > >
> > > There are also so other properties of CRVs:
> > >   1) The CRV sent in an ARQ to place a call shall be the same as the
> > >      CRV in the resulting Setup message
> > >   2) The CRV sent in an ARQ to accept a call should *not* be taken
> > >      from the incoming Setup message-- it should be locally generated so
> > >      that it is a unique between the endpoint and the GK
> > >
> > > Paul
> > >
> > > ----- Original Message -----
> > > From: "Nehru, Archana" <archie at trillium.com>
> > > To: "'Paul E. Jones'" <paulej at PACKETIZER.COM>
> > > Cc: <ITU-SG16 at mailbag.cps.intel.com>
> > > Sent: Monday, January 15, 2001 10:28 PM
> > > Subject: H.225- CRV
> > >
> > > > hi all,
> > > >
> > > > I have a question about H.323 -CRV values. Q.931 specs says that a CRV
> > > value
> > > > should be unique per D-channel layer 2 logical link.
> > > >
> > > > In H.225 context, does the above mean that:
> > > >
> > > > a) CRV values should be unique across all outgoing H.225 calls that
> have
> > > the
> > > > same "destination" IP address ?
> > > >
> > > > b) CRV value only needs to be unique across all H.225 connections
> using
> > > the
> > > > same TCP connection? In other words, if an endpoint A makes two
> > > simultaneous
> > > > calls to endpoint B, then the same CRV can be used on both the calls,
> as
> > > > long as they use different TCP connections?
> > > >
> > > > I would appreciate any help on this.
> > > >
> > > > Regards
> > > > Archana
> > > >
> > > >
> > > >
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > listserv at mailbag.intel.com
> >
> > --
> > Dr Chris Purvis -- Development Manager
> > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> > Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
> > Phone: +44 1344 899 007
> > Fax:   +44 1344 899 001
> >

-- 
Dr Chris Purvis -- Development Manager
ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
Phone: +44 1344 899 007
Fax:   +44 1344 899 001