Hi,
I implemented an apple and android push server/proxy with kamailio 5.8.1. The server/proxy is transparent.
It works fine with UDP, since the registration after the push comes from the same ip and port. So t_continue works without problems. (We use the new registration as signal thet the phone is ready)
If we use tcp at the client, he gets the push, wakes up and send the new registration on an other port. The SIP stack uses now an other connection. t_continue fails, because it uses the old data of the original invite acccording to the first registration.
Is it possible to change the stored connection values according to the new registration data?
Best regards,
Bernd
Hi, you can achieve what you want using the tsilo module https://kamailio.org/docs/modules/5.8.x/modules/tsilo.html, which was designed for this kind of scenario. There is this KamailioWorld presentation of some years ago that you can follow to understand how it works: https://www.youtube.com/watch?v=4XIrR9bwUkM. Hope this helps.
Best regards,
Federico
On Mon, Aug 19, 2024 at 2:56 PM Bernd Krueger-Knauber via sr-users < sr-users@lists.kamailio.org> wrote:
Hi,
I implemented an apple and android push server/proxy with kamailio 5.8.1. The server/proxy is transparent.
It works fine with UDP, since the registration after the push comes from the same ip and port. So t_continue works without problems. (We use the new registration as signal thet the phone is ready)
If we use tcp at the client, he gets the push, wakes up and send the new registration on an other port. The SIP stack uses now an other connection. t_continue fails, because it uses the old data of the original invite acccording to the first registration.
Is it possible to change the stored connection values according to the new registration data?
Best regards,
Bernd
Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:
Hi Federico,
thank you for your response. But ... it was my fault. For debugging I commented 2 lines and forget to reenable them.
But the main problem is that when I come in with IPv6 and go out to an IPv4 PBX, it looks like I have to replace the contact header with a random IPv4 private address. If in the contact header is still the IPv6 address, freeswitch will no use the way back over the proxy.
But that's an other problem.
Best regards,
Bernd
-
Bernd Krueger-Knauber -
Federico Cabiddu