Ambiguity in H.225.0 Appendix D

Joerg Ott jo at INFORMATIK.UNI-BREMEN.DE
Thu Jan 14 06:02:31 EST 1999


>Kishore,
>
>Looks a pretty good summary of our discussions - let's see what fallout it
>generates!!!
>
Chris, Kishore,

here are some ideas on the problem for further thinking (no solutions, of
course :-)

In essence, basing a protocol action on on whether the provoking message
was sent via unicast or multicast is not a very good idea anyway -- even
if you manage to solve the problem of distinguishing one from the other
upon reception.  Rather, we may need a "bit" indicating transmission via
multicast or unicast:

Our data transmission allows for multi-unicast, so why should discovery not
do so as well?  Particularly, you could imagine a scenario where you receive
a set of potential gatekeeper locations via private DHCP extensions,
via manual configuation, etc. some of which may be up and willing to register
you and some may not -- be it for load balancing, robustness, etc.
Now you have to try all those locations to find a gatekeeper that accepts
your registration but your network (unfortunately) is not supporting
multicast.  Querying the gatekeepers one by one may (but need not) lead
to having to wait for timers to expire before you try the next one.
Querying them in parallel is semantically equivalent to multicast even
if you do not us IP multicast to reach everybody.  Finally note that a
gatekeeper's decision if to respond (and how much information to include
in a response) may depend on whether it was asked individually or together
with a number of other gatekeepers.

Assuming these considerations are valid, the remaining question would be
which piece(s) of information to use to implement the "this-request-is-
multicast-bit".

Joerg



More information about the sg16-avd mailing list