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@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:999666222@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:999666222@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:999666222@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:999666222@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 sam@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@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-users@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

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@gmail.com mailto:samu60@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@domain.com <mailto:sam@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:999666222@pstn.domain.com
<mailto:sip%3A999666222@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:999666222@pstn.domain.com
<mailto:sip%3A999666222@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:999666222@pstn.domain.com
<mailto:sip%3A999666222@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:999666222@pstn.domain.com
<mailto:sip%3A999666222@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 sam@domain.com <mailto:sam@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@gmail.com <mailto:miconda@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 <mailto: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 list
    sr-users@lists.sip-router.org  <mailto:sr-users@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@lists.sip-router.org
    <mailto: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 list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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@gmail.com mailto:miconda@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@gmail.com
<mailto:samu60@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@domain.com <mailto:sam@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:999666222@pstn.domain.com
    <mailto:sip%3A999666222@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:999666222@pstn.domain.com
    <mailto:sip%3A999666222@pstn.domain.com>>..Contact:
    <sip:111222333@A.B.C.D:5060>..Call-ID: 59f5
    579c01f8039243ec830d317df994@A.B.C.D:5060..CSeq
    <mailto: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
    <mailto:59f5579c01f8039243ec830d317df994@A.B.C.D:5060..From>:
    "111222333" <sip:111222333@A.B.C.D>;tag=as1a7b4c7d..To:
    <sip:999666222@pstn.domain.com
    <mailto:sip%3A999666222@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
    <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@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:999666222@pstn.domain.com
    <mailto:sip%3A999666222@pstn.domain.com>>;tag=GcH-CAWXaNVzm0W314zxJF518oM-Okco..Contact:
    <sip:111222333@A.B.C.D:5060>..Call-ID:
    59f5579c01f8039243ec830d317df994@A.B.C.D:5060..CSeq
    <mailto: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 sam@domain.com
    <mailto:sam@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@gmail.com <mailto:miconda@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 <mailto: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 list
        sr-users@lists.sip-router.org  <mailto:sr-users@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@lists.sip-router.org
        <mailto: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 list
sr-users@lists.sip-router.org  <mailto:sr-users@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@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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 samu60@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 miconda@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@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@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@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:999666222@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:999666222@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:999666222@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:999666222@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 sam@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@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-users@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-users@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