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:: iUcVvmbsda9Yu0DGUm4exTHiZYIqwgtZ
Cseq:: 2
User-agent:: Blink 0.9.1 (Linux)
Received:: sip:M.N.O.P:39961;transport=TLS
State:: CS_DIRTY
Flags:: 0
Cflag:: 64
Socket:: tls:X.Y.Z.W:5061
Methods:: 4294967295
Ruid:: uloc-53fc870d-1097-4
Instance:: <urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0>
Reg-Id:: 0
Last-Keepalive:: 1409121941
Last-Modified:: 1409121941
The call trace is the following (Trying and Ringing messages removed for
simplicity):
U A.B.C.D:5060 -> X.Y.Z.W:5060
INVITE sip:999666...@pstn.domain.com SIP/2.0..Via: SIP/2.0/UDP
A.B.C.D:5060;branch=z9hG4bK222c6640..Max-Forwards: 70..From: "111222333"
<sip:111222333@A.B.C.D>;tag=as1a7b4c7d..To:
<sip:999666...@pstn.domain.com>..Contact:
<sip:111222333@A.B.C.D:5060>..Call-ID: 59f5
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..
U X.Y.Z.W:5060 -> A.B.C.D:5060
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:
<sip:999666...@pstn.domain.com>;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=
rtcp:50003..a=rtpmap:8 PCMA/8000..a=rtpmap:101
telephone-event/8000..a=fmtp:101 0-15..a=sendrecv..
U A.B.C.D:5060 -> X.Y.Z.W:5060
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..
From: "111222333" <sip:111222333@A.B.C.D>;tag=as1a7b4c7d..To: <
sip:999666...@pstn.domain.com>;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....
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 s...@domain.com. 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):
The first log ouput comes from the following lines of lookup.c:
120 if(puri.gr_val.len>0) {
121 /* pub-gruu */
122 inst = puri.gr_val;
123 LM_DBG("looking up pub gruu [%.*s]\n",
inst.len, inst.s);
But afterwards, there are these lines, with the return -1 statement:
154 /* aor or pub-gruu lookup */
155 ul.lock_udomain(_d, &aor);
156 res = ul.get_urecord(_d, &aor, &r);
157 if (res > 0) {
158 LM_DBG("'%.*s' Not found in usrloc\n",
aor.len, ZSW(aor.s));
159 ul.unlock_udomain(_d, &aor);
160 return -1;
161 }
162
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.
What is my mistake in the above assumption?
Thanks a lot for the amazing fast reply.
Samuel.
On 26 August 2014 18:22, Daniel-Constantin Mierla <mico...@gmail.com> wrote:
> 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 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);
> };
>
> before the the RELAY route call in the loose_route section.
>
> 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:
> 2(4232) DEBUG: registrar [lookup.c:123]: lookup(): looking up pub gruu
> [urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0]
> 2(4232) DEBUG: registrar [lookup.c:158]: lookup(): 'sam@A.B.C.D' Not
> found in usrloc
>
> Where A.B.C.D is the local IP of the UA.
>
> 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?
> 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.
>
> Since the username with IP is not registered, this ACK is lost and the
> sesion is not stablished (lost ACK).
>
> Can anyone provide some hints why is this failing?
>
> Thanks a lot in advance!
> Samuel.
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda -
> http://www.linkedin.com/in/miconda
> Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
> Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
