[SR-Users] gruu within dialog

Discussion:

samuel

2014-08-26 16:05:54 UTC

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(): '***@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 (***@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.

Daniel-Constantin Mierla

2014-08-26 16:22:06 UTC

Permalink

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

Post by samuel
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
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
2(4232) DEBUG: registrar [lookup.c:123]: lookup(): looking up pub
gruu [urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0]
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
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
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

samuel

2014-08-27 07:12:25 UTC

Permalink

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-9IKiO1iGCm/QT0dZR+***@public.gmane.org
Contact:: sip:***@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-***@public.gmane.org SIP/2.0..Via: SIP/2.0/UDP
A.B.C.D:5060;branch=z9hG4bK222c6640..Max-Forwards: 70..From: "111222333"
<sip:***@A.B.C.D>;tag=as1a7b4c7d..To:
<sip:999666222-***@public.gmane.org>..Contact:
<sip:***@A.B.C.D:5060>..Call-ID: 59f5
***@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:
***@A.B.C.D:5060..From: "111222333"
<sip:***@A.B.C.D>;tag=as1a7b4c7d..To:
<sip:999666222-***@public.gmane.org>;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:***@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:***@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:***@A.B.C.D>;tag=as1a7b4c7d..To: <
sip:999666222-***@public.gmane.org>;tag=GcH-CAWXaNVzm0W314zxJF518oM-Okco..Contact:
<sip:***@A.B.C.D:5060>..Call-ID:
***@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:***@M.N.O.P, which is not found because what exists in the registrar
database is sam-9IKiO1iGCm+Xj1p+***@public.gmane.org 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.

Post by Daniel-Constantin Mierla
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
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
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
2(4232) DEBUG: registrar [lookup.c:123]: lookup(): looking up pub gruu
[urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0]
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
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.
_______________________________________________
--
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
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

samuel

2014-09-01 13:33:24 UTC

Permalink

anoyone can provide information about how lookup function treats Req-URI
with gruu?

Thanks in advance,
Samuel.

Post by samuel
The registration process is done via TLS and therefore I "can not" post
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
U A.B.C.D:5060 -> X.Y.Z.W:5060
A.B.C.D:5060;branch=z9hG4bK222c6640..Max-Forwards: 70..From: "111222333"
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
102 INVITE..Server: Blink 0.9.1 (Linux)..Allow: SUBSCRIBE, NOTIFY, PRACK,
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
70..
IPXAdam..Content-Length:0....
What I was refering to is that in the logs the lookup process is using
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
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);
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.

Post by Daniel-Constantin Mierla
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
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
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
2(4232) DEBUG: registrar [lookup.c:123]: lookup(): looking up pub gruu
[urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0]
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
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.
_______________________________________________
--
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
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Daniel-Constantin Mierla

2014-09-01 13:46:55 UTC

Permalink

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

Post by samuel
anoyone can provide information about how lookup function treats
Req-URI with gruu?
Thanks in advance,
Samuel.
The registration process is done via TLS and therefore I "can not"
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
U A.B.C.D:5060 -> X.Y.Z.W:5060
A.B.C.D:5060;branch=z9hG4bK222c6640..Max-Forwards: 70..From: "111222333"
INVITE..User-Agent: IPXAdam..Date: Wed, 27 Aug 2014 06:45:54
GMT..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
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
102 INVITE..Server: Blink 0.9.1 (Linux)..Allow: SUBSCRIBE, NOTIFY,
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/2.0..Via: SIP/2.0/UDP
70..
ACK..User-Agent: IPXAdam..Content-Length:0....
What I was refering to is that in the logs the lookup process is
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
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);
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
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

Post by samuel
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
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
2(4232) DEBUG: registrar [lookup.c:123]: lookup(): looking
up pub gruu [urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0]
Where A.B.C.D is the local IP of the UA.
Looking at the code, this last line looks like is looking for
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
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
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

samuel

2014-09-02 09:45:26 UTC

Permalink

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.

Post by Daniel-Constantin Mierla
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,
- 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
anoyone can provide information about how lookup function treats Req-URI
with gruu?
Thanks in advance,
Samuel.

Post by samuel
The registration process is done via TLS and therefore I "can not" post
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
U A.B.C.D:5060 -> X.Y.Z.W:5060
A.B.C.D:5060;branch=z9hG4bK222c6640..Max-Forwards: 70..From: "111222333"
59f5
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
102 INVITE..Server: Blink 0.9.1 (Linux)..Allow: SUBSCRIBE, NOTIFY, PRACK,
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:X.Y.Z.W;lr;r2=on;fdrrm=82.63f;nat=yes>,
70..
ACK..User-Agent: IPXAdam..Content-Length:0....
What I was refering to is that in the logs the lookup process is using
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
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);
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.

Post by Daniel-Constantin Mierla
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
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
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
2(4232) DEBUG: registrar [lookup.c:123]: lookup(): looking up pub gruu
[urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0]
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
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.
_______________________________________________
--
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
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
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Daniel-Constantin Mierla

2014-09-02 10:06:46 UTC

Permalink

Indeed it makes sense to skip contact mangling if gruu is present.

Cheers,
Daniel

Post by samuel
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.
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
- 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

Post by samuel
anoyone can provide information about how lookup function treats
Req-URI with gruu?
Thanks in advance,
Samuel.
The registration process is done via TLS and therefore I "can
not" post the trace. However, the resulting data is the
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
U A.B.C.D:5060 -> X.Y.Z.W:5060
SIP/2.0/UDP
A.B.C.D:5060;branch=z9hG4bK222c6640..Max-Forwards: 70..From: "111222333"
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,
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
102 INVITE..Server: Blink 0.9.1 (Linux)..Allow: SUBSCRIBE,
NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE,
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/2.0..Via: SIP/2.0/UDP
70..
102 ACK..User-Agent: IPXAdam..Content-Length:0....
What I was refering to is that in the logs the lookup process
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
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);
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
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

Post by samuel
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
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
looking up pub gruu
[urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0]
Where A.B.C.D is the local IP of the UA.
Looking at the code, this last line looks like is
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
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
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

samuel

2014-09-02 10:28:37 UTC

Permalink

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.

Post by Daniel-Constantin Mierla
Indeed it makes sense to skip contact mangling if gruu is present.
Cheers,
Daniel
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.

Post by Daniel-Constantin Mierla
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,
- 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
anoyone can provide information about how lookup function treats
Req-URI with gruu?
Thanks in advance,
Samuel.

Post by samuel
The registration process is done via TLS and therefore I "can not" post
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
U A.B.C.D:5060 -> X.Y.Z.W:5060
A.B.C.D:5060;branch=z9hG4bK222c6640..Max-Forwards: 70..From: "111222333"
59f5
INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
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
102 INVITE..Server: Blink 0.9.1 (Linux)..Allow: SUBSCRIBE, NOTIFY, PRACK,
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:X.Y.Z.W;lr;r2=on;fdrrm=82.63f;nat=yes>,
70..
ACK..User-Agent: IPXAdam..Content-Length:0....
What I was refering to is that in the logs the lookup process is using
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
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);
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.

Post by Daniel-Constantin Mierla
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
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
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
2(4232) DEBUG: registrar [lookup.c:123]: lookup(): looking up pub gruu
[urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0]
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
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.
_______________________________________________
--
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
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