Chris,

The object is to uniquely identify the signaling part of a call. The uniqueness consists of two points, the signaling link and the CRV. The real question is the definition of the signaling link. In a direct call routed model, the endpoints define the link, not the TCP connection. For the gatekeeper routed model, it is more complicated. For a call going EP->GK->GK->EP there are three links. The CRV must be unique for each of the three links. In that the originating endpoint can determine uniqueness for the first (EP->GK) link but not for the following links, it may be necessary for the GKs to change the CRV for a call transiting the GK is forwarded to the next link.

I agree that this has not been clear for a long time, and was not properly clarified. The rules should be more clearly defined.

Bob

-------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan@ICN.Siemens.com -----------------------------------------------------------------

-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Tuesday, January 16, 2001 5:16 AM To: ITU-SG16@mailbag.cps.intel.com 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@trillium.com To: "'Paul E. Jones'" paulej@PACKETIZER.COM Cc: ITU-SG16@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@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

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

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