<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
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 partitioned to different servers, based on domain.<br>
<br>
AFAIK, in case GRUU is supported, the UA has to use the give GRUU
URI as contact for further requests. Kamailio is giving the domain
and the UA should use it as it is. So, for me it looks as an issue
in the UA, unless there is some other proxy in the middle changing
the contact.<br>
<br>
Of course, with the flexibility of kamailio you can fix it in the
config, like:<br>
- if there is gr parameter to uri and the domain part is IP (see
siputils and ipops for appropriate functions to be used), then set
$rd to the domain of the user.<br>
- the domain of the user can be discovered from various sources,
depending on local profile and signaling (e.g, From/To headers, do a
sql_query() over subscriber table, etc.)<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<div class="moz-cite-prefix">On 01/09/14 15:33, samuel wrote:<br>
</div>
<blockquote
cite="mid:CAOg=WDdJpziNPvPGj3+Utsx0ONUCCgHNChFbSM91LtSPys+FLA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>anoyone can provide information about how lookup function
treats Req-URI with gruu?<br>
<br>
</div>
Thanks in advance,<br>
Samuel.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 27 August 2014 09:12, samuel <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:samu60@gmail.com" target="_blank">samu60@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>Here it goes, apologies for the length:<br>
<br>
The registration process is done via TLS and
therefore I "can not" post the trace. However,
the resulting data is the following:<br>
<br>
AOR:: <a moz-do-not-send="true"
href="mailto:sam@domain.com" target="_blank">sam@domain.com</a><br>
Contact::
<a class="moz-txt-link-freetext" href="sip:83652074@M.N.O.P:34120;transport=tls">sip:83652074@M.N.O.P:34120;transport=tls</a> Q=<br>
Expires:: 569<br>
Callid:: iUcVvmbsda9Yu0DGUm4exTHiZYIqwgtZ<br>
Cseq:: 2<br>
User-agent:: Blink 0.9.1 (Linux)<br>
Received:: <a class="moz-txt-link-freetext" href="sip:M.N.O.P:39961;transport=TLS">sip:M.N.O.P:39961;transport=TLS</a><br>
State:: CS_DIRTY<br>
Flags:: 0<br>
Cflag:: 64<br>
Socket:: tls:X.Y.Z.W:5061<br>
Methods:: 4294967295<br>
Ruid:: uloc-53fc870d-1097-4<br>
Instance::
<urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0><br>
Reg-Id:: 0<br>
Last-Keepalive:: 1409121941<br>
Last-Modified:: 1409121941<br>
<br>
</div>
The call trace is the following (Trying and
Ringing messages removed for simplicity):<br>
<br>
U A.B.C.D:5060 -> X.Y.Z.W:5060<br>
INVITE <a moz-do-not-send="true"
href="mailto:sip%3A999666222@pstn.domain.com"
target="_blank">sip:999666222@pstn.domain.com</a>
SIP/2.0..Via: SIP/2.0/UDP
A.B.C.D:5060;branch=z9hG4bK222c6640..Max-Forwards:
70..From: "111222333"<br>
<a class="moz-txt-link-rfc2396E" href="sip:111222333@A.B.C.D"><sip:111222333@A.B.C.D></a>;tag=as1a7b4c7d..To:
<<a moz-do-not-send="true"
href="mailto:sip%3A999666222@pstn.domain.com"
target="_blank">sip:999666222@pstn.domain.com</a>>..Contact:
<a class="moz-txt-link-rfc2396E" href="sip:111222333@A.B.C.D:5060"><sip:111222333@A.B.C.D:5060></a>..Call-ID:
59f5<br>
<a class="moz-txt-link-abbreviated" href="mailto:579c01f8039243ec830d317df994@A.B.C.D:5060..CSeq">579c01f8039243ec830d317df994@A.B.C.D:5060..CSeq</a>:
102 INVITE..User-Agent: IPXAdam..Date: Wed, 27
Aug 2014 06:45:54 GMT..Allow: INVITE, ACK,
CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH..Supported: replaces,
timer..Content-Type:
application/sdp..Content-Length:
311....v=0..o=root 936120945 936120945 IN IP4
A.B.C.D..s=Asterisk PBX 11.6-cert2..c=IN IP4
A.B.C.D..t=0 0..m=audio 12018 RTP/AVP 8 3 0
101..a=rtpmap:8 PCMA/8000..a=rtpmap:3
GSM/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:101
telephone-event/8000..a=fmtp:101
0-16..a=silenceSupp:off - - -
-..a=ptime:20..a=sendrecv..<br>
<br>
<br>
U X.Y.Z.W:5060 -> A.B.C.D:5060<br>
SIP/2.0 200 OK..Via: SIP/2.0/UDP
A.B.C.D:5060;rport=5060;branch=z9hG4bK222c6640..Record-Route:
<a class="moz-txt-link-rfc2396E" href="sip:X.Y.Z.W:5061;transport=tls;lr;r2=on;fdrrm=82.63f;nat=yes"><sip:X.Y.Z.W:5061;transport=tls;lr;r2=on;fdrrm=82.63f;nat=yes></a>..Record-Route:
<a class="moz-txt-link-rfc2396E" href="sip:X.Y.Z.W;lr;r2=on;fdrrm=82.63f;nat=yes"><sip:X.Y.Z.W;lr;r2=on;fdrrm=82.63f;nat=yes></a>..Call-ID:
<a class="moz-txt-link-abbreviated" href="mailto:59f5579c01f8039243ec830d317df994@A.B.C.D:5060..From">59f5579c01f8039243ec830d317df994@A.B.C.D:5060..From</a>:
"111222333"
<a class="moz-txt-link-rfc2396E" href="sip:111222333@A.B.C.D"><sip:111222333@A.B.C.D></a>;tag=as1a7b4c7d..To:
<<a moz-do-not-send="true"
href="mailto:sip%3A999666222@pstn.domain.com"
target="_blank">sip:999666222@pstn.domain.com</a>>;tag=GcH-CAWXaNVzm0W314zxJF518oM-Okco..CSeq:
102 INVITE..Server: Blink 0.9.1 (Linux)..Allow:
SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE,
CANCEL, UPDATE, MESSAGE, REFER..Contact:
<a class="moz-txt-link-rfc2396E" href="sip:sam@M.N.O.P:39961;transport=tls;gr=urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0"><sip:sam@M.N.O.P:39961;transport=tls;gr=urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0></a>..Supported:
100rel, replaces, norefersub,
gruu..Content-Type:
application/sdp..Content-Length:
236....v=0..o=- 3618110757 3618110758 IN IP4
M.N.O.P..s=Blink 0.9.1 (Linux)..t=0 0..m=audio
50002 RTP/AVP 8 101..c=IN IP4 M.N.O.P..a=<br>
rtcp:50003..a=rtpmap:8 PCMA/8000..a=rtpmap:101
telephone-event/8000..a=fmtp:101
0-15..a=sendrecv..<br>
<br>
U A.B.C.D:5060 -> X.Y.Z.W:5060<br>
ACK
<a class="moz-txt-link-freetext" href="sip:sam@M.N.O.P:39961;transport=tls;gr=urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0">sip:sam@M.N.O.P:39961;transport=tls;gr=urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0</a>
SIP/2.0..Via: SIP/2.0/UDP
A.B.C.D:5060;branch=z9hG4bK22a00025..Route:
<a class="moz-txt-link-rfc2396E" href="sip:X.Y.Z.W;lr;r2=on;fdrrm=82.63f;nat=yes"><sip:X.Y.Z.W;lr;r2=on;fdrrm=82.63f;nat=yes></a>,<a class="moz-txt-link-rfc2396E" href="sip:X.Y.Z.W:5061;transport=tls;lr;r2=on;fdrrm=82.63f;nat=yes"><sip:X.Y.Z.W:5061;transport=tls;lr;r2=on;fdrrm=82.63f;nat=yes></a>..Max-Forwards:
70..<br>
From: "111222333"
<a class="moz-txt-link-rfc2396E" href="sip:111222333@A.B.C.D"><sip:111222333@A.B.C.D></a>;tag=as1a7b4c7d..To:
<<a moz-do-not-send="true"
href="mailto:sip%3A999666222@pstn.domain.com"
target="_blank">sip:999666222@pstn.domain.com</a>>;tag=GcH-CAWXaNVzm0W314zxJF518oM-Okco..Contact:
<a class="moz-txt-link-rfc2396E" href="sip:111222333@A.B.C.D:5060"><sip:111222333@A.B.C.D:5060></a>..Call-ID:
<a class="moz-txt-link-abbreviated" href="mailto:59f5579c01f8039243ec830d317df994@A.B.C.D:5060..CSeq">59f5579c01f8039243ec830d317df994@A.B.C.D:5060..CSeq</a>:
102 ACK..User-Agent:
IPXAdam..Content-Length:0.... <br>
<br>
</div>
What I was refering to is that in the logs the
lookup process is using <a class="moz-txt-link-freetext" href="sip:sam@M.N.O.P">sip:sam@M.N.O.P</a>, which is
not found because what exists in the registrar
database is <a moz-do-not-send="true"
href="mailto:sam@domain.com" target="_blank">sam@domain.com</a>.
In the Contact header of the 200 OK the local IP
is used instead of the FQDN form. I might have
been misleaded by the logs or the gruu lookup
process, but in the following lines of the code
(you were right about the lines and verion):<br>
<br>
The first log ouput comes from the following lines
of lookup.c:<br>
<br>
120 if(puri.gr_val.len>0) {<br>
121 /* pub-gruu */<br>
122 inst = puri.gr_val;<br>
123 LM_DBG("looking up pub
gruu [%.*s]\n", inst.len, inst.s);<br>
<br>
But afterwards, there are these lines, with the
return -1 statement:<br>
154 /* aor or pub-gruu lookup
*/<br>
155 ul.lock_udomain(_d,
&aor);<br>
156 res = ul.get_urecord(_d,
&aor, &r);<br>
157 if (res > 0) {<br>
158 LM_DBG("'%.*s' Not
found in usrloc\n", aor.len, ZSW(aor.s));<br>
159
ul.unlock_udomain(_d, &aor);<br>
160 return -1;<br>
161 }<br>
162 <br>
</div>
<br>
This is the point where I would need expertise help,
because it looks like it uses the "short" AoR
(without URI gruu parameters) according to the logs
and a -1 is returned. Afterwards there are the lines
used to lookup the pub and temp gruu but are not, as
far as I understand, used because of the return -1.<br>
</div>
<br>
</div>
What is my mistake in the above assumption?<br>
<br>
</div>
Thanks a lot for the amazing fast reply.<span
class="HOEnZb"><font color="#888888"><br>
<br>
Samuel.<br>
<div>
<div>
<div>
<div><br>
</div>
</div>
</div>
</div>
</font></span></div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
On 26 August 2014 18:22, Daniel-Constantin Mierla <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Hello,<br>
<br>
can you send a trace that includes the
registration as well as the call?<br>
<br>
The pub-gruu is using the AoR, iirc.<br>
<br>
Also, the line you refer to is not matching
anymore with latest 4.1.x -- paste the code
around it to locate it properly.<br>
<br>
Cheers,<br>
Daniel
<div>
<div><br>
<br>
<div>On 26/08/14 18:05, samuel wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>Hi all,<br>
<br>
I'm having some issues
treating requests within
dialogs with gruu enabled with
kamailio 4.1.2.<br>
<br>
</div>
I've got the "standard"
configuration of WITHIN route
with the adition of the next
lines:<br>
<br>
if(is_gruu()){<br>
route(LOCATION);<br>
};<br>
<br>
</div>
before the the RELAY route call in
the loose_route section.<br>
<br>
The "problem" is that the ACK with
a pub-gruu on the Req-URI is not
properly lookup. In the logs I can
see the following statements:<br>
2(4232) DEBUG: registrar
[lookup.c:123]: lookup(): looking
up pub gruu
[urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0]<br>
2(4232) DEBUG: registrar
[lookup.c:158]: lookup(): '<a
moz-do-not-send="true"
href="mailto:sam@A.B.C.D"
target="_blank">sam@A.B.C.D</a>'
Not found in usrloc<br>
<br>
</div>
Where A.B.C.D is the local IP of the
UA.<br>
<br>
Looking at the code, this last line
looks like is looking for the
"standard" URI (username@domain)
instead of using the pub gruu. Am I
right with this assumption or am I
missing something from the code?<br>
As far as I could look, it looks
like there's an exit -1 statement in
the line 158 of lookup.c which
disables the following gruu
treatment.<br>
<br>
</div>
Since the username with IP is not
registered, this ACK is lost and the
sesion is not stablished (lost ACK).<br>
<br>
</div>
Can anyone provide some hints why is
this failing?<br>
<br>
Thanks a lot in advance!<br>
Samuel.<br>
<div>
<div>
<div><br>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a moz-do-not-send="true" href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a>
<a moz-do-not-send="true" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><span><font color="#888888">
</font></span></pre>
<span><font color="#888888"> </font></span></blockquote>
<span><font color="#888888"> <br>
<pre cols="72">--
Daniel-Constantin Mierla
<a moz-do-not-send="true" href="http://twitter.com/#%21/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a moz-do-not-send="true" href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a>
Next Kamailio Advanced Trainings 2014 - <a moz-do-not-send="true" href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA</pre>
</font></span></div>
<br>
_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) -
sr-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:sr-users@lists.sip-router.org"
target="_blank">sr-users@lists.sip-router.org</a><br>
<a moz-do-not-send="true"
href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users"
target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Next Kamailio Advanced Trainings 2014 - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA</pre>
</body>
</html>