Below is configuration of my SIP trunk. it is working fine. the actual device/host that my PBX is sending the voice traffic to is defined in the outboundproxy. fromdomain and host are only there because the provider requires that domain in the INVITE message. if that domain is not in the INVITE message the sip trunk does not register.
My issue is that if i enable qualify=yes i can see the PBX sending traffic to du.ae because its defined on the host, of which there is no valid host there. i want the qualify packets to be sent to the device defined in the outboundproxy. how can i achieve this bearing in mind that i cannot remove the fromdomain and host parameters.
What do you mean by “sent to the host”. I would expect them to be sent in the same way as an INVITE, i.e. sent to the proxy, with the request URI to be set to the host. I would expect the proxy to also route them in the same way as an invite.
However, if chan_sip is treating them differently from INVITEs, that is most unlikely to change given that it is in the process of being withdrawn.
It doesn’t. I use non-existent (no DNS) FQDNs for my user domains and I have no issues with any requests getting from Asterisk to the endpoints with the use of an outbound proxy. Keep in mind that with chan_pjsip you need an outbound proxy on both the endpoint and aor.
Much like DNS, this is one of the things that a standards driven sip driver gets you. Much more improved handling of everything overall than a kludge like chan_sip.
But if the problem is that chan_sip is looking up the final destination, before sending OPTIONS, via the proxy, rather than that it is trying to directly send to the final destination, I’d expect it to fail, in the same way, for the INVITE, so changing behaviour just for qualify (OPTIONS) wouldn’t help.
In fact, I seem to remember a topic on this about INVITEs, which, almost certainly, should be merged with this topic, as it looks like another case where lots of topics are being created for a single problem, forgetting that most readers don’t track individual posters, to put the pieces together.
My impression, here, though was that the OP wanted a one hop qualification of the “proxy”, rather than an end to end qualification of an over the DNS horizon endpoint, via the proxy, although that may be the result of stabbing at solutions to a problem of unnecessary DNS lookups. “proxy” in quotations marks, as it would be final destination, and therefore UAS, in the context of the qualify.
I did think about defining a dummy peer for the proxy, but if the qualify was done for Asterisk’s benefit, rather than to keep a dynamic router rule open, that wouldn’t help (unless you explicitly tested the state in the dialplan) because it would not be recorded against the endpoint. Also if the OPTIONS can’t reach final endpoint, then I’ expect an INVITE to fail, so proving the proxy was up would not be useful.