sourceInfo in LRQ

[Francois Audet]

Agreed. I want to make sure that the case where a Gatekepeer is using the
endpoint's address because it is proxying its request.
 
Like this:
 
EP1(+1 408 565 5675)          GK1                        GK2         EP2(+1
408 495 3756)
 
ARQ(Public.local=4953756)
sourceInfo(h323-ID=EP1)
------------------------------> LRQ(Public.local=4953756)
                                sourceInfo(h323-ID=EP1)
                               -------------------------->
 
In this example GK1 doesn't know how to resolve 4953756. It asks GK2 to
help. It provides the sourceInfo of EP1 (e.g., an h323-ID or the phone
number of the originator). GK2 uses the h323-ID to "figure out" the country
code and area code that should be used for the Called party (if EP1 dials a
local number, then it is the same country code as EP1's).
 
Of course GK1 can do whatever it pleases since it might be using LRQs for
its own purposes, not prompted by an ARQ.

-----Original Message-----
From: Paul E. Jones [mailto:paulej at packetizer.com]
Sent: Thursday, June 14, 2001 10:15 AM
To: Audet, Francois [SC2:4K02:EXCH]; ITU-SG16
Subject: Re: sourceInfo in LRQ


Francois,
 
I agree with you that what we should do is modify the text to be a bit more
tolerant of what "source" means.  It might be the source Gatekeeper or it
might be the source endpoint's alias.  It is possible to find either there
today (since either an endpoint or a Gatekeeper may source an LRQ), so the
text should reflect that.
 
Paul

----- Original Message ----- 
From: Francois Audet <mailto:audet at NORTELNETWORKS.COM>  
To: ITU-SG16 at mailbag.cps.INTEL.COM <mailto:ITU-SG16 at mailbag.cps.INTEL.COM>  
Sent: Wednesday, June 13, 2001 2:40 PM
Subject: sourceInfo in LRQ

Hi all,
 
The sourceInfor in LRQ states that it should be the alias address of the
originator of the LRQ (as opposed to the originator of the call).
 
One of the consequence of this is that if an endpoint sends an ARQ to its
gatekeeper, and its gatekeeper can not resolve it, the LRQ that it will send
to other gatekeepers may not have enough information to resolve the address.
For example, if the number was a "local" number or a "national" number, the
gatekeeper that receives the LRQ will not have enough context (where is the
originator of the call) to resolve the address (like the country code of the
calling user to figure out the contry code of the called user).
 
Anybody has any views on this?
 
My take is that the LRQ.sourceInfo should really reflect the alias address
of the originator of the call (the initial ARQ) as opposed to the gatekeeper
that originated the LRQ. An alternative would be to define a new field, but
I'm not too keen on this approach since it won't work until H.323v5...
 
----
François AUDET, Nortel Networks
mailto:audet at nortelnetworks.com <mailto:audet at nortelnetworks.com> , tel:+1
408 495 3756
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20010614/ef863cf5/attachment-0009.html>