I've been trying to track this issue down myself for the last two days but it appears the value is coming from somewhere in the tm module or somewhere else lower than that, which I haven't worked with at all. I have siptrace turned on and I'm using the destination port from the HEPv2 header but it seems to always come to me as 5060 even if the packet is actually sent to a different port (such as 51000). I'm able to reproduce this with my Polycom phone by having two registrations (one UDP and one TCP) going through a Kamailio server from the same phone. It looks like the first request comes from 5060 and is responded to on 5060, but the second connection comes from a random port on the phone (let's say 35000). When the reply (such as a 200) comes back from the server sitting behind the Kamailio proxy, the siptrace HEP header says the packet is going back to 5060 when it's actually being sent to 35000. I'm not even sure where the 5060 value is coming from in the first pl ace.

I've tracked the '5060' value to t.uas.response.dst.to.sin.sin_port in t_reply.c:reply_received() but the value of t is retrieved from get_t() and I'm not sure where that's added to the hash table in the first place. I can see the actual value of the destination port with t.uas.request.rcv.src_port within that same t_reply.c:reply_received() but I can't figure out how to get that value into the destination port at the source.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub