[SR-Users] gruu within dialog
Daniel-Constantin Mierla
miconda at gmail.com
Mon Sep 1 15:46:55 CEST 2014
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: 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
> <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
> 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: 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
> 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/20140901/cc9477cd/attachment.html>
More information about the sr-users
mailing list