Hi,
If there is Path in the AOR then lookup("domain") adds Route header(s), the
additional route(s) breaks routing.
The work arround is to use reg_fetch_contacts(domain, uri, profile) and
match gr parameter from $ru with $ulc(profile=>instance) to find
$ulc(profile=>addr).
How about change behaviour and skip add Route within dialog in
lookup("domain") function or add optional parameter for this?
Regards,
SK
On Tue, Sep 2, 2014 at 12:28 PM, samuel <sam...@gmail.com> wrote:
> 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 <mico...@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 <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
>>>
>>>
>>
>> --
>> 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
>
>
--
MSC Seudin Kasumovic
Tuzla, Bosnia
_______________________________________________
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
