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.
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?
Thanks a lot for the answer!
Samuel.
On 1 September 2014 15:46, Daniel-Constantin Mierla <mico...@gmail.com>
wrote:
> Hello,
>
> 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.
>
> 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.
>
> Of course, with the flexibility of kamailio you can fix it in the config,
> like:
> - 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.
> - 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.)
>
> Cheers,
> Daniel
>
>
> On 01/09/14 15:33, samuel wrote:
>
> anoyone can provide information about how lookup function treats Req-URI
> with gruu?
>
> Thanks in advance,
> Samuel.
>
>
> On 27 August 2014 09:12, samuel <sam...@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:: 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
> 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
