Now I see the problem.
When EP1 makes a call to EP2, it sends ARQ to the gatekeeper
with CAT token containg its alias/password. Then it takes this token,
puts it into Setup message and sends the Setup to EP2.
EP2 sends "answering" ARQ to the gatekeeper, but it does not contain
token with EP2 username/password - it contains CAT token received
from EP1 - the same that has been used with ARQ from EP1.
So it is not possible to authenticate EP2 using it's username/password.
Also it may be not always possible to send Access-Request with Framed-IP-Address
of EP1 upon receiving ARQ from EP2.
There could be three possible solutions:
1. Modify radius authentor to not send Access-Request for "answering" ARQ
and always admit such.
2. Modify your radius backend logic to check only User-Name and CHAP-Password
for Acess-Requests with Service-Type=Call-Check (the preferred solution).
3. Maybe the gatekeeper should store tokens received with "originating" ARQ inside
CallRec and upon receiving "answering" ARQ just compare a recevied tokens
with the stored tokens - if there is a match, no Access-Request is sent and answer call
is admitted. If there is not match, standard Access-Request is send. This would result
in a better performance for some configurations (both endpoints registered to the same GK).
This scenario will not work if you will have endpoints registered with different GKs.
---
Zygmuntowicz Michal
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
List: Openh323gk-users@lists.sourceforge.net
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
Homepage: http://www.gnugk.org/
