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@trillium.com To: PauleJ@packetizer.com Cc: ITU-SG16@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
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:
- 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.
- 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 :
- 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
- 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@mailbag.intel.com