Hey!
> Quickly looking through the code, I see there is no link in nathelper to tm module, so the solution is to modify nathelper code, maybe?
Yes, I also experimentally detected that sending OPTIONS probing does not depend on the TM module.
In my scenario, the upstream SIP Proxy inserts Path headers towards the Registrar. And I need to somehow force nathelper to route ping OPTIONS according to a set of Routes.
This is now achieved by setting the received_avp parameter on Registrar as the IP address of the upstream SIP Proxy, but setting this adds the received parameter to the Contact of 200 OK.
However, the address entered above is not the client's real address, and some ancient terminals do not react well to this.
REGISTER: SIP-UA -> SIP Proxy (adds Path) -> SIP Registrar (setting $avp(received) = $sut before saving aor)
OPTIONS: SIP Registrar (routing as per Received) -> SIP Proxy (loose_route) -> SIP-UA