Re: [SR-Users] record_route() from websocket UA to tls UA

2021-08-20 Thread Juha Heinanen
> 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

Re: [SR-Users] record_route() from websocket UA to tls UA

2021-08-20 Thread Daniel-Constantin Mierla
On 20.08.21 08:22, Juha Heinanen wrote: >> 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

Re: [SR-Users] record_route() from websocket UA to tls UA

2021-08-19 Thread Juha Heinanen
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

Re: [SR-Users] record_route() from websocket UA to tls UA

2021-08-19 Thread Juha Heinanen
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

[SR-Users] record_route() from websocket UA to tls UA

2021-08-19 Thread Juha Heinanen
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

Re: [SR-Users] record_route() from websocket UA to tls UA

2021-08-19 Thread Daniel-Constantin Mierla
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

Re: [SR-Users] record_route() from websocket UA to tls UA

2021-08-19 Thread Daniel-Constantin Mierla
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

Re: [SR-Users] record_route() from websocket UA to tls UA

2021-08-13 Thread Juha Heinanen
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

[SR-Users] record_route() from websocket UA to tls UA

2021-08-13 Thread Juha Heinanen
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

Re: [SR-Users] record_route() from websocket UA to tls UA

2021-08-13 Thread Daniel-Constantin Mierla
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