[SR-Users] gruu within dialog
Daniel-Constantin Mierla
miconda at gmail.com
Tue Sep 2 12:06:46 CEST 2014
Indeed it makes sense to skip contact mangling if gruu is present.
Cheers,
Daniel
On 02/09/14 11:45, samuel wrote:
> 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 <miconda at gmail.com
> <mailto:miconda at 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 <samu60 at gmail.com
>> <mailto:samu60 at 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 at domain.com <mailto:sam at domain.com>
>> Contact:: sip:83652074 at 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 at pstn.domain.com
>> <mailto:sip%3A999666222 at 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 at A.B.C.D>;tag=as1a7b4c7d..To:
>> <sip:999666222 at pstn.domain.com
>> <mailto:sip%3A999666222 at pstn.domain.com>>..Contact:
>> <sip:111222333 at A.B.C.D:5060>..Call-ID: 59f5
>> 579c01f8039243ec830d317df994 at A.B.C.D:5060..CSeq
>> <mailto:579c01f8039243ec830d317df994 at 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 at A.B.C.D:5060..From
>> <mailto:59f5579c01f8039243ec830d317df994 at A.B.C.D:5060..From>:
>> "111222333" <sip:111222333 at A.B.C.D>;tag=as1a7b4c7d..To:
>> <sip:999666222 at pstn.domain.com
>> <mailto:sip%3A999666222 at 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 at 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
>> <tel:3618110757> 3618110758 <tel: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 at 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 at A.B.C.D>;tag=as1a7b4c7d..To:
>> <sip:999666222 at pstn.domain.com
>> <mailto:sip%3A999666222 at pstn.domain.com>>;tag=GcH-CAWXaNVzm0W314zxJF518oM-Okco..Contact:
>> <sip:111222333 at A.B.C.D:5060>..Call-ID:
>> 59f5579c01f8039243ec830d317df994 at A.B.C.D:5060..CSeq
>> <mailto:59f5579c01f8039243ec830d317df994 at 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 at M.N.O.P, which is not found because what
>> exists in the registrar database is sam at domain.com
>> <mailto:sam at 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 at gmail.com <mailto:miconda at 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 at A.B.C.D <mailto:sam at 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 at 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 at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>> --
>> Daniel-Constantin Mierla
>> http://twitter.com/#!/miconda <http://twitter.com/#%21/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 at lists.sip-router.org
>> <mailto:sr-users at 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 at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda <http://twitter.com/#%21/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 at lists.sip-router.org <mailto:sr-users at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140902/4060d5e5/attachment.html>
More information about the sr-users
mailing list