Hi Gang
A quick search via google did not reveal any useful hits.
Kamailio 5.7.6
CPE (TLS) => SBC (UDP) => Registrar (UDP) => Core
CPE uses a sips contact URI to register, no transport attribute!
sips:315996608@172.29.255.11:5061
SBC uses Path functionality.
Situation: Call to CPE
I see the registrar adding this Record-Route:
Record-Route: sips:registrar-ip;lr;ftag=6159862378
The SBC is adding a r2=on Record-Route to indicate the change between UDP and TLS.
The Route-Set received by the CPE then is:
INVITE sips:315996608@172.29.255.11:5061 SIP/2.0 Record-Route: sips:sbc-ip:5061;transport=tls;r2=on;lr;ftag=6159862378 Record-Route: sips:sbc-ip;r2=on;lr;ftag=6159862378 Record-Route: sips:registrar-ip;lr;ftag=6159862378 Record-Route: sip:core-ip;lr;ftag=6159862378
180 Ringing req 100rel is making it back as the Via header look right.
But when the remote side is sending a PRACK, is has to follow the Routeset which if I am not mistaking, is not making it back because because the CORE does not know how to send this via TLS to the Registrar.
Core logging: prepare_new_uac(): can't fwd to af 2, proto 3 (no corresponding listening socket)
IMHO already the 2nd Record-Route added by the Registrar should not contain a sips: URI but a sip: URI (reflecting the transport attribute not being present, defaulting to UDP)
Is this a known issue?
Mit freundlichen Grüssen
-Benoît Panizzon-
Hi
Quick update...
I switched the CPE from TLS to TCP
Now the CPE registers with sip: and ;transport=tcp
The problem does not occur.
I attemted to reproduce the issue with a CPE using sip: ;transport=tls
The problem does not occur.
I fear, something goes wrong kamailio internally if the sips: scheme is being used.
Mit freundlichen Grüssen
-Benoît Panizzon-
On 2 Jan 2025, at 14:54, Benoit Panizzon via sr-users sr-users@lists.kamailio.org wrote:
Hi
Quick update...
I switched the CPE from TLS to TCP
Now the CPE registers with sip: and ;transport=tcp
The problem does not occur.
I attemted to reproduce the issue with a CPE using sip: ;transport=tls
The problem does not occur.
I fear, something goes wrong kamailio internally if the sips: scheme is being used.
Well, something went wrong internally while writing the SIP RFC so the sips: scheme can’t really be implemented properly. My best defence for the authors is that they got a last minute request to add security like ldaps: and https: and they gave it a try without really implementing it beforehand.
Better to use ";transport=tls” and wait for energy in the IETF SIP wg to really focus on solving the TLS issues.
/O
Benoit, try testing the sips scheme with the option enabled: modparam("rr", "ignore_sips", 1)
чт, 2 янв. 2025 г. в 15:48, Olle E. Johansson via sr-users < sr-users@lists.kamailio.org>:
On 2 Jan 2025, at 14:54, Benoit Panizzon via sr-users <
sr-users@lists.kamailio.org> wrote:
Hi
Quick update...
I switched the CPE from TLS to TCP
Now the CPE registers with sip: and ;transport=tcp
The problem does not occur.
I attemted to reproduce the issue with a CPE using sip: ;transport=tls
The problem does not occur.
I fear, something goes wrong kamailio internally if the sips: scheme is being used.
Well, something went wrong internally while writing the SIP RFC so the sips: scheme can’t really be implemented properly. My best defence for the authors is that they got a last minute request to add security like ldaps: and https: and they gave it a try without really implementing it beforehand.
Better to use ";transport=tls” and wait for energy in the IETF SIP wg to really focus on solving the TLS issues.
/O __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hi Denys
Benoit, try testing the sips scheme with the option enabled: modparam("rr", "ignore_sips", 1)
Thank you, yes, this solved the issue!
Mit freundlichen Grüssen
-Benoît Panizzon-