Hello list,
in order to deal with NAT-Clients properly I am using dialog-flags to store the information, whether callee or caller is NATed.
So if there is an incoming call to a NATed client, the callee-NAT-DLGflag is being set directly after usrloc lookup.
But: If the client returns a 3xx response which is processed by the kamailio instance that has just contaced the device, the callee (usually one of our sip-proxies) is NOT NATed anymore - so I need to reset the callee-nat-dlgflag out of 3xx-reply route. And that seems to be a problem.
In reply route the dlg functions/flags are not available, and trying to call a normal route with dlg_manage() out of reply(or failure) route results in strange behaviour...
I think it is generally a good idea to have access to dlg flags/functions in reply/failure route. So what about the suggestion to identify the dialog, if a reply on a request arrives?
Have a nice weekend Jasmin
Hey Jasmin,
On 16.09.2011 18:09, Jasmin Schnatterbeck wrote:
In reply route the dlg functions/flags are not available, and trying to call a normal route with dlg_manage() out of reply(or failure) route results in strange behaviour...
I think it is generally a good idea to have access to dlg flags/functions in reply/failure route. So what about the suggestion to identify the dialog, if a reply on a request arrives?
Dialogs can already be accessed in response routes. The required glue code was added a while ago and should be part of 3.1.5.
The main purpose for that, however, was to make callbacks work properly. (And to implement dialog variables correctly in the master branch.) Dialog flags weren't considered at the time but it shouldn't be too hard to make it work.
Could you please issue a bug report on the tracker?
Thanks,
--Timo
-
Jasmin Schnatterbeck -
Timo Reimann