H.323 UUIE PDU

[Paul E. Jones]

Archana,

I don't believe that I have heard anybody raise this question before.  My
own opinion is that the endpoint should just forward them as received.
However, if the endpoint wishes to decode and then re-encode them, that
should be OK-- but there will be missing information, obviously, so that
might prove to be difficult unless the endpoint has multiple protocol
stacks.  Again, I'd suggest just passing the raw messages as they are
received and prior to decoding.

Paul

----- Original Message -----
From: "Nehru, Archana" <archie at trillium.com>
To: <PauleJ at packetizer.com>
Cc: <ITU-SG16 at mailbag.cps.INTEL.COM>
Sent: Thursday, March 15, 2001 6:01 PM
Subject: H.323 UUIE PDU


> hi all,
>
> I have a question about the encoding of the UUIE PDU that is sent by an
> endpoint to its GateKeeper through an IRR message.
>
> Suppose we have the following scenario:
>
> EP1
>
(v3)-----------------------------GK(v3/v2)----------------------------------
> ----EP2(v2)
>
> Here Ep1 is a version 3 client, Gk could either be v3 or V2. Ep2 is
version
> 2.
>
> Now if EP1 sends out a UUIE PDU to the GK for all incoming messages from
> EP2, is it supposed to encode them as version 3 messages or version 2
> messages?
> .
> The issue here is that the messages from EP2 will not contain V3 fields,
so
> EP1 can forward the message coming from EP2 to the GK in one of the
> following ways:
>
> 1) EP1 forwards the EXACT copy of message coming from EP2. This obviously
> means that
>     EP1 will forward a "version 2" message as a UUIE to the GK. Note that
> this means the GK gets an
>     incoming version 2 message inspite of knowing that EP1 is a version 3
> endpoint.
>
> 2) EP1 does not send an EXACT COPY of messages coming from EP2 as part of
> UUIEs.
>    This means that EP1 decodes the v2 message from EP2, re-encodes it as a
> version 3 message and then
>     sends this out to the GK. So the "information content" of the message
> sent to the Gk is the same as in
>    the incoming PDU from EP2, but the message sent is version3.
>
>
>  E.g: let us say  EP2 sent a SETUP message to EP1, so its ASN part does
not
> contain version 3 fields like
>     "maintain connection" or "multipleCalls". So EP1 can do the following
as
> indicated above:
>
> For choice 1(mentioned above):
> ---------------------------------
> It will forward the same SETP UUIE  to Gk
>
> For Choice 2 (mentioned above):
> -------------------------------------
> It will encode the incoming version 2 message as a version 3 message , i.e
> it will encode "maintain connection" and "multiple calls" BUT set their
> values to FALSE. This means that the information delivered to the Gk is
the
> same( maintain connection or multiple calls not supported).
>
> The point to clarify here is  whether :
> 1) it is acceptable that a GK sees a version 3 endpoint (EP1) sending out
a
> version 2 message?
> 2) it is acceptable to GK that the EP1 has actually converted a version 2
> message in to a version 3 message (choice no 2)?
>
> Pros and Cons of choice 1 and Choice 2:
> -----------------------------------------------------------
> With choice 1,  EP1 has to have logic for generating all backward
compatible
> messages (e.g: if EP1 is a V4 endpoint, it should be capable of "encoding
a
> v1, v2 and v3 message also. As the versions increase, this may become
> cumbersome to implement.
>
> With choice 2, EP1 can have the logic of encoding messages only for
version
> 3. But the disadvantage here is that EP1 has to fill in values
corresponding
> to all the fields added for version 3 in order to convert a version2 into
a
> version 3 message. Also it is possible to fill corresponding values for
> fields that are "BOOLEANs" , but
> it may not be possible to fill "dummy values" for all "non-BOOLEAN"
fields.
> E.g:what if the new fields added in version 3 is an integer? what dummy
> values will the GW fill in the version 3 message ?
>
> So the question here is , which one of the above choices is correct? My
> guess is choice 1) works better. Is that right? Any answers are greatly
> appreciated.
>
> -Archana
>
>
>
>

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