[SR-Users] gruu within dialog
samuel
samu60 at gmail.com
Tue Sep 2 12:28:37 CEST 2014
As a complete "guide" to set up gruu handling, I've added below is_gruu
treatment in WITHINDLG, NATMANAGE, and NATDETECT routes.
# Handle requests within SIP dialogs
route[WITHINDLG] {
if (has_totag()) {
(...)
if(is_gruu()){
route(LOCATION);
};
route(RELAY);
# RTPProxy control
route[NATMANAGE] {
(...)
if (is_reply()) {
if(isbflagset(FLB_NATB)) {
if(!is_gruu(@contact.uri)){
fix_nated_contact();
};
}
}
}
# Caller NAT detection route
route[NATDETECT] {
#!ifdef WITH_NAT
force_rport();
if (nat_uac_test("19")) {
if (is_method("REGISTER")) {
fix_nated_register();
} else {
if(!is_gruu(@contact.uri)){
fix_nated_contact();
};
}
setflag(FLT_NATS);
}
#!endif
return;
}
If someone can take a look, is there any missing point about this feature
that shall be included in the default config file?
Thanks a lot for the time spent and the fast reply!
Samuel.
On 2 September 2014 12:06, Daniel-Constantin Mierla <miconda at gmail.com>
wrote:
> 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>
> 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> 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
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
> --
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140902/8986c2a9/attachment.html>
More information about the sr-users
mailing list