Am Thu, 20 Jun 2024 14:14:11 -0000 schrieb smartin114--- via sr-users sr-users@lists.kamailio.org:
Invite to carrier is good, sent over tls and so the reply from the carrier, the 200 ok. The ACK is sent via UDP and so is the Bye, which I didn't include.
I fear I need more information and a complete example to see what might be going wrong.
INVITE: FS => TLS => Kamailio => UDP => Carrier some more messages 200 OK: Carrier => UDP => Kamailio => TLS => FS and the ACK to the 200 OK, they are all fine?
So the Problem is the BYE when sent which direction? From the Carrier?
I assume this is the case.
Basically you need to look at the INVITE from the FS.
Does the Contact: header contain a transport=tls attribute? (According to your example, it does)
So this information needs to be stored on the Carrier side (or whatever B2BUA an the Carrier side handles the call) and when the carrier issues a BYE the R-URI of that BYE needs to contain transport=tls as this is the information, the last HOP towards the Fs side will be using when all Route: Header have been consumed.
If this is NOT the case and transport=tls is missing in the BYE R-URI the IMHO SIP implementation Carries side is 'broken', you face the same issue I have had. :-)
If you are able to put other attributes in the invite Contact header, and they are sent back the BYE from the Carrier, then you can copy the transport value to a custom contact attribute (I use t=) and restore the transport attribute on the R-URI from that.
Mit freundlichen Grüssen
-Benoît Panizzon-