Usage of CallID in H.323v2 for rerouted (diverted, transferre d,.. .) calls

[Santo Wiryaman]

Hi Karl, Chris:

>From the very beginning there was Conference ID (CID) that was created to
identify
a "conference". There was also CRV which is used to associate call
signalling.
messages.  However, since the RAS and H.225 CRV values are independent, a GK
may not be able to associate the ARQ pair with the Setup message.

The in version 2, the Call ID was created to associate the H.225.0 messages
with
the call.  Karl is now proposing to add CallLegID to identify the leg of the
call.  It seems clear
that as soon as we define a new ID to identify a particular thing, there is
a need to identify
yet another thing related to the thing.

I am not saying that a new field called the CallLegID is a bad thing.
However, perhaps we
need to step back and think what is it that we are really trying to get a
handle of.

I propose that what we are dealing here is a call, a conference, and the
connection legs to
the call.  A word can mean different things to different people, and the
H.323 spec does not
necessarily help either.  My favorite definitions so far came from the ECTF
CTI Encyclopedia
Volume 3, p 10:

        Device -  And endpoint
        Call -      The association of one or more devices
        Connection - A device's representation in a given call

Consider the example of device D1 in a call with device D2:

        D1 --------- C1 --------- D2

Call C1 associates devices D1 and D2.  Call C1 consists of 2 connections:
D1C1 and D2C2.

H.450.2 (Call Transfer SS), for example, uses a similar notation.  CT with
consultaion figure 7/H.450.2 can be redrawn in ASCII art as:

Before Service:
        A ----------- C1 ----------- B
                                            C (idle)

Consultation:
        A ----h----- C1 -----h----- B  ( A puts B on hold)
        A ----------- C2 ------------ C  ( A makes a new call to C)

Transfer
                A ----t----- C1 -----t----- B  ( A transfers B to C)
                A ----t----- C2 -----t----- C

After Service:
                A (idle)
                B ----------- C3 ----------- C

The question is how do CID, CRV, CallID, CallLegID map to the above model.

CID somewhat maps to the ID of the calls, e.g. C1, C2, C3.  It breaks down,
though, if an MCU calls out to A, B, C with the same CID. As far as the
model
goes, there are 3 calls:
                MCU ----------- C1 ----------- A
                MCU ----------- C2 ----------- B
                MCU ----------- C3 ----------- C

As far as a device is concerned, the CRV is the ID for the connections.  For
a
GK, however, the ID for the connections is (CRV plus the EndpointID).  The
ambiguity
with CRV's is when an endpoint can make multiple calls.  For example, A
makes
two simultaneous calls to B:
  1. A sends ARQ to GK with CRV=1
  2. A sends ARQ to GK with CRV=2
  3. A sends Setup to GK with CRV= 17
  4. A sends Setup to GK with CRV= 21
Since the CRV's of RAS and Q.931 are independent, the GK can not associate
the
Setup with the correct ARQ.

Version 2 CallID was suppose to fix this since it associate the RAS and the
Call Signalling
for the same connection (i.e. connection leg).  Section 7.5 of H.323v2 says
that the CallID
must be the same for the following call:
                A ----------- C1 ----------- B
Specifically it says that the CallID of the AC1 connection must be the same
as the BC1
connection and that in both connections, the RAS and Call Signalling
messages CallID's
must be the same.  Karl is proposing that in the case of a rerouted call, as
described in
Fig 19/H.323, the second Setup uses the same CallID.  I agree that this is
fine.

However, in the case of a call transfer as described above, during the
Consultation phase
when A makes a new call to C, the CallID for the AC2 connection leg shall be
diferent than
the AC1 leg, because by definition, this is a new call.  Would you agree
with that Karl?
Otherwise, if the CallID of AC1 and AC2 are the same, then we'll make it
impossible for the
GK to match the RAS and CallSignalling messages once again.  Or is this why
you are
proposing a new CallLeg field?

Finally, I have a question on the After Service phase of the call transfer
operation.  At this phase
we have a new call (C3) with CC3 and BC3 connections.  If the SS-CT was done
on the GK
w/gk-routed model, the H.225 connections on CC3 and BC3 could remain
connected during the
whole procedure.  At the end, though, we end up with a call (C3) and two
different CallID's on
CC3 (which was the same as AC2) and on BC3 (which was the same as AC1).
This is permitted
and should not cause any misoperations, correct?  Should this be pointed out
in an implementor's
guide?

A similar situation is true today with meet-me MCU's.  In theory, all the
calls in the same conference
would use the same CID.  However, in a meet-me MCU, the endpoints initiates
the call each
generating unique CID's.  There are procedures to change CID's during a
call, but I don't know if
that happens in the field.

Regards,

Santo Wiryaman
VideoServer Inc.









> -----Original Message-----
> From: Klaghofer Karl PN VS LP3 [SMTP:Karl.Klaghofer at VS.SIEMENS.DE]
> Sent: Monday, November 16, 1998 8:34 AM
> To:   ITU-SG16 at mailbag.cps.intel.com
> Subject:      AW: Usage of CallID in H.323v2 for rerouted (diverted,
> transferre d,.. .) calls
>
> Chris,
>
> Thanks for your comment.
>
> CRV is unique just at one signalling link of a call (e.g. between EP A and
> GK; and may be different between GK and EP2 of the same call) .
>
> Since CallID may be preserved when calls are redirected (incl. transfer,
> forward,...), the CallID actually identifies the call scenario and not
> exactly one call. I think this is fine.
>
> A CallLegID would be a new identifier that is somehow in between CallID
> and
> CRV by identifying exactly one call (or call attempt) between two
> endpoints.
> We might think about for H.225.0v3.
>
> Regards,
> Karl
>
> > -----Ursprüngliche Nachricht-----
> > Von:  Chris Purvis [SMTP:CPurvis at MADGE.COM]
> > Gesendet am:  Montag, 16. November 1998 12:52
> > An:   ITU-SG16 at mailbag.cps.intel.com
> > Betreff:      Re: Usage of CallID in H.323v2 for rerouted (diverted,
> > transferre d,.. .) calls
> >
> > Karl,
> >
> > I agree with your comments on CallID being preserved when calls are
> > transferred.  However...
> >
> >
> > >As an alternative, we might add a new multilevel CallID (e.g.
> > >to H.225.0 v3)
> > >that consists of an identifier that indicates the "overal
> > >call" and a second
> > >identifier that indicates the call leg.
> >
>         Isn't this the CRV, that's always been there?
>
> > Regards,
> > Chris
> > --
> > Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
> > Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks.
> > Phone:+44 1753 661359  email: cpurvis at madge.com