Hi,
If there is Path in the AOR then lookup("domain") adds Route header(s), the
additional route(s) breaks routing.
The work arround is to use reg_fetch_contacts(domain, uri, profile) and
match gr parameter from $ru with $ulc(profile=>instance) to find
$ulc(profile=>addr).
How about change behav
As a complete "guide" to set up gruu handling, I've added below is_gruu
treatment in WITHINDLG, NATMANAGE, and NATDETECT routes.
# Handle requests within SIP dialogs
route[WITHINDLG] {
if (has_totag()) {
(...)
if(is_gruu()){
Indeed it makes sense to skip contact mangling if gruu is present.
Cheers,
Daniel
On 02/09/14 11:45, samuel wrote:
It turned out to be the NAT handling process that screwed the gruu
treatment. Kamailio modified Contact from the OK (because this user is
marked as natted) and calling fix_nated_c
It turned out to be the NAT handling process that screwed the gruu
treatment. Kamailio modified Contact from the OK (because this user is
marked as natted) and calling fix_nated_contact modified the Req-URI of
further in-dialog requests.
I have to look at the details but, using the standard config
Hello,
the problem is the contact coming with IP address and then used in r-uri
with IP. In a multi-domain deployment, you cannot assume what is the
right user id (sip address) to use in case of overlapping usernames.
Think about rather common multi-tenant scenario where the location can
be p
anoyone can provide information about how lookup function treats Req-URI
with gruu?
Thanks in advance,
Samuel.
On 27 August 2014 09:12, samuel wrote:
> Here it goes, apologies for the length:
>
> The registration process is done via TLS and therefore I "can not" post
> the trace. However, the
Here it goes, apologies for the length:
The registration process is done via TLS and therefore I "can not" post the
trace. However, the resulting data is the following:
AOR:: s...@domain.com
Contact:: sip:83652074@M.N.O.P:34120;transport=tls Q=
Expires:: 569
Callid:: iUcVvmbsda9Yu0DGUm4ex
Hello,
can you send a trace that includes the registration as well as the call?
The pub-gruu is using the AoR, iirc.
Also, the line you refer to is not matching anymore with latest 4.1.x --
paste the code around it to locate it properly.
Cheers,
Daniel
On 26/08/14 18:05, samuel wrote:
Hi a
Hi all,
I'm having some issues treating requests within dialogs with gruu enabled
with kamailio 4.1.2.
I've got the "standard" configuration of WITHIN route with the adition of
the next lines:
if(is_gruu()){
route(LOCATION);
