13 Aug
2021
13 Aug
'21
8:46 a.m.
I noticed that when jsSIP UA that has registered over wss calls another
SIP UA that has registered over tls, record_route() adds only one Route
URI to outgoing INVITE (example below). This causes BYE to fail.
This issue may be caused by the fact that both UAs register over the
same Kamailio tls listening socket. Still two Route URIs should be
added in the same way as is done when one UA registers over tcp and the
other over udp.
-- Juha
---------------------------------------------------------------------
09:25:43.639833 wss:87.95.73.155:19458 wss:192.27.134.1:5061
INVITE sip:foo@test.tutpro.com SIP/2.0
Via: SIP/2.0/WSS jovobf9n4svm.invalid;branch=z9hG4bK2639638
Max-Forwards: 69
To: <sip:foo@test.tutpro.com>
From: " Test" <sip:test@test.tutpro.com>;tag=f7lpsuo7cb
Call-ID: ovhd9fu1fl1a66nec011
CSeq: 1387 INVITE
Contact:
<sip:test@test.tutpro.com;gr=urn:uuid:e7f92a54-2295-4772-abc8-504be07e94c5>
...
09:25:43.649462 tls:192.27.134.1:5061 tls:87.95.73.155:19461
INVITE sip:foo-0x793ee87a90@10.158.141.103:38378;transport=tls SIP/2.0
Record-Route:
<sip:192.27.134.1:5061;transport=ws;sn=ext_tls;lr;n2;dtlsf=avp;pm=0;ice>
Via: SIP/2.0/TLS 192.27.134.1:5061;branch=z9hG4bK637c.7e15ef5b84ea054cfc8ea3d4e860521f.0
Via: SIP/2.0/WSS
jovobf9n4svm.invalid;rport=19458;received=87.95.73.155;branch=z9hG4bK2639638
Max-Forwards: 68
To: <sip:foo@test.tutpro.com>
From: " Test" <sip:test@test.tutpro.com>;tag=f7lpsuo7cb
Call-ID: ovhd9fu1fl1a66nec011
CSeq: 1387 INVITE
Contact:
<sip:test@test.tutpro.com;gr=urn:uuid:e7f92a54-2295-4772-abc8-504be07e94c5>
13 Aug
13 Aug
9:08 a.m.
Hello,
this should be fixed indeed, can you try and see if setting next
modparam helps for the moment?
modparam("rr", "enable_double_rr", 2)
Cheers,
Daniel
On 13.08.21 08:46, Juha Heinanen wrote:
I noticed that when jsSIP UA that has registered over
wss calls another
SIP UA that has registered over tls, record_route() adds only one Route
URI to outgoing INVITE (example below). This causes BYE to fail.
This issue may be caused by the fact that both UAs register over the
same Kamailio tls listening socket. Still two Route URIs should be
added in the same way as is done when one UA registers over tcp and the
other over udp.
-- Juha
---------------------------------------------------------------------
09:25:43.639833 wss:87.95.73.155:19458 wss:192.27.134.1:5061
INVITE sip:foo@test.tutpro.com SIP/2.0
Via: SIP/2.0/WSS jovobf9n4svm.invalid;branch=z9hG4bK2639638
Max-Forwards: 69
To: <sip:foo@test.tutpro.com>
From: " Test" <sip:test@test.tutpro.com>;tag=f7lpsuo7cb
Call-ID: ovhd9fu1fl1a66nec011
CSeq: 1387 INVITE
Contact:
<sip:test@test.tutpro.com;gr=urn:uuid:e7f92a54-2295-4772-abc8-504be07e94c5>
...
09:25:43.649462 tls:192.27.134.1:5061 tls:87.95.73.155:19461
INVITE sip:foo-0x793ee87a90@10.158.141.103:38378;transport=tls SIP/2.0
Record-Route:
<sip:192.27.134.1:5061;transport=ws;sn=ext_tls;lr;n2;dtlsf=avp;pm=0;ice>
Via: SIP/2.0/TLS 192.27.134.1:5061;branch=z9hG4bK637c.7e15ef5b84ea054cfc8ea3d4e860521f.0
Via: SIP/2.0/WSS
jovobf9n4svm.invalid;rport=19458;received=87.95.73.155;branch=z9hG4bK2639638
Max-Forwards: 68
To: <sip:foo@test.tutpro.com>
From: " Test" <sip:test@test.tutpro.com>;tag=f7lpsuo7cb
Call-ID: ovhd9fu1fl1a66nec011
CSeq: 1387 INVITE
Contact:
<sip:test@test.tutpro.com;gr=urn:uuid:e7f92a54-2295-4772-abc8-504be07e94c5>
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
9:42 a.m.
Daniel-Constantin Mierla writes:
this should be fixed indeed, can you try and see if
setting next
modparam helps for the moment?
modparam("rr", "enable_double_rr", 2)
That caused two r-r headers to be inserted:
INVITE sip:foo-0x793ee87a90@10.158.141.103:38378;transport=tls SIP/2.0
Record-Route:
<sip:192.27.134.1:8003;transport=tls;sn=ext_tls;r2=on;lr;n2;dtlsf=avp;pm=0;ice>
Record-Route:
<sip:192.27.134.1:8003;transport=ws;sn=ext_tls;r2=on;lr;n2;dtlsf=avp;pm=0;ice>
and BYE worked OK. But it would be better to only add two r-r headers
when it is really needed.
-- Juha
19 Aug
19 Aug
5:40 p.m.
Should I create a bug issue to GitHub about this? I looked at
rr/record.c, but could not figure out, what needs to be changed.
-- Juha
-------------------------------------------------------------------------
I noticed that when jsSIP UA that has registered over
wss calls another
SIP UA that has registered over tls, record_route() adds only one Route
URI to outgoing INVITE (example below). This causes BYE to fail.
This issue may be caused by the fact that both UAs register over the
same Kamailio tls listening socket. Still two Route URIs should be
added in the same way as is done when one UA registers over tcp and the
other over udp.
-- Juha
---------------------------------------------------------------------
09:25:43.639833 wss:87.95.73.155:19458 wss:192.27.134.1:5061
INVITE sip:foo@test.tutpro.com SIP/2.0
Via: SIP/2.0/WSS jovobf9n4svm.invalid;branch=z9hG4bK2639638
Max-Forwards: 69
To: <sip:foo@test.tutpro.com>
From: " Test" <sip:test@test.tutpro.com>;tag=f7lpsuo7cb
Call-ID: ovhd9fu1fl1a66nec011
CSeq: 1387 INVITE
Contact:
<sip:test@test.tutpro.com;gr=urn:uuid:e7f92a54-2295-4772-abc8-504be07e94c5>
...
09:25:43.649462 tls:192.27.134.1:5061 tls:87.95.73.155:19461
INVITE sip:foo-0x793ee87a90@10.158.141.103:38378;transport=tls SIP/2.0
Record-Route:
<sip:192.27.134.1:5061;transport=ws;sn=ext_tls;lr;n2;dtlsf=avp;pm=0;ice>
Via: SIP/2.0/TLS 192.27.134.1:5061;branch=z9hG4bK637c.7e15ef5b84ea054cfc8ea3d4e860521f.0
Via: SIP/2.0/WSS
jovobf9n4svm.invalid;rport=19458;received=87.95.73.155;branch=z9hG4bK2639638
Max-Forwards: 68
To: <sip:foo@test.tutpro.com>
From: " Test" <sip:test@test.tutpro.com>;tag=f7lpsuo7cb
Call-ID: ovhd9fu1fl1a66nec011
CSeq: 1387 INVITE
Contact:
<sip:test@test.tutpro.com;gr=urn:uuid:e7f92a54-2295-4772-abc8-504be07e94c5>
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
5:56 p.m.
Probably the code that needs to be changed is in the core, where the
message is built (msg_translator.c). rr module adds second conditional
lump for record route, but at that stage is not aware what is going to
be the final target address.
One more workaround would be using separate sockets, one tls and one
websocket, I ended up doing so because the latest versions of web
browsers do not allow traffic to standard sip ports anyhow because of
the the slipstream attack.
I will try to look over the code soon, if nothing happens in 1-2 days,
you can open an issue not to be forgotten.
Cheers,
Daniel
On 19.08.21 17:40, Juha Heinanen wrote:
Should I create a bug issue to GitHub about this? I
looked at
rr/record.c, but could not figure out, what needs to be changed.
-- Juha
-------------------------------------------------------------------------
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
I noticed that when jsSIP UA that has registered
over wss calls another
SIP UA that has registered over tls, record_route() adds only one Route
URI to outgoing INVITE (example below). This causes BYE to fail.
This issue may be caused by the fact that both UAs register over the
same Kamailio tls listening socket. Still two Route URIs should be
added in the same way as is done when one UA registers over tcp and the
other over udp.
-- Juha
---------------------------------------------------------------------
09:25:43.639833 wss:87.95.73.155:19458 wss:192.27.134.1:5061
INVITE sip:foo@test.tutpro.com SIP/2.0
Via: SIP/2.0/WSS jovobf9n4svm.invalid;branch=z9hG4bK2639638
Max-Forwards: 69
To: <sip:foo@test.tutpro.com>
From: " Test" <sip:test@test.tutpro.com>;tag=f7lpsuo7cb
Call-ID: ovhd9fu1fl1a66nec011
CSeq: 1387 INVITE
Contact:
<sip:test@test.tutpro.com;gr=urn:uuid:e7f92a54-2295-4772-abc8-504be07e94c5>
...
09:25:43.649462 tls:192.27.134.1:5061 tls:87.95.73.155:19461
INVITE sip:foo-0x793ee87a90@10.158.141.103:38378;transport=tls SIP/2.0
Record-Route:
<sip:192.27.134.1:5061;transport=ws;sn=ext_tls;lr;n2;dtlsf=avp;pm=0;ice>
Via: SIP/2.0/TLS 192.27.134.1:5061;branch=z9hG4bK637c.7e15ef5b84ea054cfc8ea3d4e860521f.0
Via: SIP/2.0/WSS
jovobf9n4svm.invalid;rport=19458;received=87.95.73.155;branch=z9hG4bK2639638
Max-Forwards: 68
To: <sip:foo@test.tutpro.com>
From: " Test" <sip:test@test.tutpro.com>;tag=f7lpsuo7cb
Call-ID: ovhd9fu1fl1a66nec011
CSeq: 1387 INVITE
Contact:
<sip:test@test.tutpro.com;gr=urn:uuid:e7f92a54-2295-4772-abc8-504be07e94c5>
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
6:08 p.m.
Daniel-Constantin Mierla writes:
Probably the code that needs to be changed is in the
core, where the
message is built (msg_translator.c). rr module adds second conditional
lump for record route, but at that stage is not aware what is going to
be the final target address.
OK.
One more workaround would be using separate sockets,
one tls and one
websocket, I ended up doing so because the latest versions of web
browsers do not allow traffic to standard sip ports anyhow because of
the the slipstream attack.
The problem with using 443 port is that then it is not possible to run
web server on the same host unless it is configured to proxy websocket
traffic to sip proxy. But proxying causes its own issues due to which I
would prefer direct access from browser to sip proxy.
I will try to look over the code soon, if nothing
happens in 1-2 days,
you can open an issue not to be forgotten.
OK, thanks,
-- Juha
6:16 p.m.
Can you try the latest master (or the last commit backported to your
local branch)? Maybe I nailed down with one more condition in the core.
Cheers,
Daniel
On 19.08.21 18:08, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Probably the code that needs to be changed is in
the core, where the
message is built (msg_translator.c). rr module adds second conditional
lump for record route, but at that stage is not aware what is going to
be the final target address.
OK.
One more workaround would be using separate
sockets, one tls and one
websocket, I ended up doing so because the latest versions of web
browsers do not allow traffic to standard sip ports anyhow because of
the the slipstream attack.
The problem with using 443 port is that then it is not
possible to run
web server on the same host unless it is configured to proxy websocket
traffic to sip proxy. But proxying causes its own issues due to which I
would prefer direct access from browser to sip proxy.
I will try to look over the code soon, if nothing
happens in 1-2 days,
you can open an issue not to be forgotten.
OK, thanks,
-- Juha
7:10 p.m.
Daniel-Constantin Mierla writes:
Can you try the latest master (or the last commit
backported to your
local branch)? Maybe I nailed down with one more condition in the
core.
Now two r-r headers are added without
modparam("rr", "enable_double_rr", 2)
and bye work fine.
Can the change be backported to 5.5?
Thanks, Juha
8:31 p.m.
Have you tested the usual cases as well? e.g., tls-to-tls, udp-to-udp,
... I don't expect problems, just double-checking. If all ok, then it
will be backported.
Cheers,
Daniel
On 19.08.21 19:10, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Can you try the latest master (or the last commit
backported to your
local branch)? Maybe I nailed down with one more condition in the
core.
Now two r-r headers are added without
modparam("rr", "enable_double_rr", 2)
and bye work fine.
Can the change be backported to 5.5?
Thanks, Juha
20 Aug
20 Aug
8:22 a.m.
Daniel-Constantin Mierla writes:
Have you tested the usual cases as well? e.g., tls-to-tls, udp-to-udp,
... I don't expect problems, just double-checking. If all ok, then it
will be backported.
I tested all tcp, tls, and ws combinations and record routing worked
fine. My sip proxy does not support udp.
-- Juha
10:12 a.m.
On 20.08.21 08:22, Juha Heinanen wrote:
OK. I pushed another commit for the proto conditional lumps that seem
used by other rr functions, not the classic record_route().
The commits are now backported to 5.5 branch.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Daniel-Constantin Mierla writes:
Have you tested the usual cases as well? e.g., tls-to-tls, udp-to-udp,
... I don't expect problems, just double-checking. If all ok, then it
will be backported.
I tested all tcp, tls, and ws combinations and record routing
worked
fine. My sip proxy does not support udp.
1005
days inactive
1012
days old
11 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Juha Heinanen