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

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

---

...

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@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@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

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:

...

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

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:

...

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

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