On 27 August 2014 09:12, samuel <samu60@gmail.com> 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 resulting data is the following:

AOR:: sam@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:999666222@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:999666222@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:999666222@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:999666222@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 sam@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 <miconda@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 list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla http://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