<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 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 href="mailto:sam@domain.com" target="_blank">sam@domain.com</a><br>Contact:: sip:83652074@M.N.O.P:34120;transport=tls Q=<br> Expires:: 569<br> Callid:: iUcVvmbsda9Yu0DGUm4exTHiZYIqwgtZ<br> Cseq:: 2<br>
User-agent:: Blink 0.9.1 (Linux)<br>
Received:: sip:M.N.O.P:39961;transport=TLS<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 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><sip:111222333@A.B.C.D>;tag=as1a7b4c7d..To: <<a href="mailto:sip%3A999666222@pstn.domain.com" target="_blank">sip:999666222@pstn.domain.com</a>>..Contact: <sip:111222333@A.B.C.D:5060>..Call-ID: 59f5<br>
579c01f8039243ec830d317df994@A.B.C.D:5060..CSeq: 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: <sip:X.Y.Z.W:5061;transport=tls;lr;r2=on;fdrrm=82.63f;nat=yes>..Record-Route: <sip:X.Y.Z.W;lr;r2=on;fdrrm=82.63f;nat=yes>..Call-ID: 59f5579c01f8039243ec830d317df994@A.B.C.D:5060..From: "111222333" <sip:111222333@A.B.C.D>;tag=as1a7b4c7d..To: <<a 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: <sip:sam@M.N.O.P:39961;transport=tls;gr=urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0>..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 sip:sam@M.N.O.P:39961;transport=tls;gr=urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0 SIP/2.0..Via: SIP/2.0/UDP A.B.C.D:5060;branch=z9hG4bK22a00025..Route: <sip:X.Y.Z.W;lr;r2=on;fdrrm=82.63f;nat=yes>,<sip:X.Y.Z.W:5061;transport=tls;lr;r2=on;fdrrm=82.63f;nat=yes>..Max-Forwards: 70..<br>
From: "111222333" <sip:111222333@A.B.C.D>;tag=as1a7b4c7d..To: <<a href="mailto:sip%3A999666222@pstn.domain.com" target="_blank">sip:999666222@pstn.domain.com</a>>;tag=GcH-CAWXaNVzm0W314zxJF518oM-Okco..Contact: <sip:111222333@A.B.C.D:5060>..Call-ID: 59f5579c01f8039243ec830d317df994@A.B.C.D:5060..CSeq: 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 sip:sam@M.N.O.P, which is not found because what exists in the registrar database is <a 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 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 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 href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a>
<a 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 href="http://twitter.com/#!/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a>
Next Kamailio Advanced Trainings 2014 - <a 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 href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
<a 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>