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 place
.
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:
https://github.com/kamailio/kamailio/issues/581