<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Indeed it makes sense to skip contact mangling if gruu is present.<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<div class="moz-cite-prefix">On 02/09/14 11:45, samuel wrote:<br>
</div>
<blockquote
cite="mid:CAOg=WDdXzAvtu_u1fCdsyXEAGG4gj0NFOjBYJUCMPBrEWecihw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>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.<br>
<br>
</div>
I have to look at the details but, using the standard config
file as basic, the NAT flags should no be marked if is_gruu is
TRUE. Shall this be included in the standard kamailio.cfg
config file?<br>
<br>
</div>
Thanks a lot for the answer!<br>
<br>
Samuel.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 1 September 2014 15:46,
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>
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
<div>
<div class="h5"><br>
<br>
<div>On 01/09/14 15:33, samuel wrote:<br>
</div>
<blockquote 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
moz-do-not-send="true">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
moz-do-not-send="true">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 moz-do-not-send="true"><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 moz-do-not-send="true"><sip:111222333@A.B.C.D:5060></a>..Call-ID:
59f5<br>
<a moz-do-not-send="true"
href="mailto:579c01f8039243ec830d317df994@A.B.C.D:5060..CSeq"
target="_blank">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 moz-do-not-send="true"><sip:X.Y.Z.W:5061;transport=tls;lr;r2=on;fdrrm=82.63f;nat=yes></a>..Record-Route:
<a moz-do-not-send="true"><sip:X.Y.Z.W;lr;r2=on;fdrrm=82.63f;nat=yes></a>..Call-ID:
<a moz-do-not-send="true"
href="mailto:59f5579c01f8039243ec830d317df994@A.B.C.D:5060..From"
target="_blank">59f5579c01f8039243ec830d317df994@A.B.C.D:5060..From</a>:
"111222333" <a
moz-do-not-send="true"><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
moz-do-not-send="true"><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=- <a
moz-do-not-send="true"
href="tel:3618110757"
value="+13618110757"
target="_blank">3618110757</a> <a
moz-do-not-send="true"
href="tel:3618110758"
value="+13618110758"
target="_blank">3618110758</a>
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 moz-do-not-send="true">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 moz-do-not-send="true"><sip:X.Y.Z.W;lr;r2=on;fdrrm=82.63f;nat=yes></a>,<a
moz-do-not-send="true"><sip:X.Y.Z.W:5061;transport=tls;lr;r2=on;fdrrm=82.63f;nat=yes></a>..Max-Forwards:
70..<br>
From: "111222333" <a
moz-do-not-send="true"><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 moz-do-not-send="true"><sip:111222333@A.B.C.D:5060></a>..Call-ID:
<a moz-do-not-send="true"
href="mailto:59f5579c01f8039243ec830d317df994@A.B.C.D:5060..CSeq"
target="_blank">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 moz-do-not-send="true">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><font
color="#888888"><br>
<br>
Samuel.<br>
<div>
<div>
<div>
<div><br>
</div>
</div>
</div>
</div>
</font></span></div>
<div>
<div>
<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></fieldset>
<br>
<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>
</pre>
</blockquote>
<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>
</div>
</div>
</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">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>
</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>