[SR-Users] gruu within dialog
samuel
samu60 at gmail.com
Mon Sep 1 15:33:24 CEST 2014
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> 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
> 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 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>..Contact:
> <sip:111222333 at A.B.C.D:5060>..Call-ID: 59f5
> 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: "111222333"
> <sip:111222333 at A.B.C.D>;tag=as1a7b4c7d..To: <sip:999666222 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 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>;tag=GcH-CAWXaNVzm0W314zxJF518oM-Okco..Contact:
> <sip:111222333 at A.B.C.D:5060>..Call-ID:
> 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. 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>
> 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' 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 listsr-users at 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 at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140901/21283736/attachment.html>
More information about the sr-users
mailing list