Hello,
RFC 3261 gives (by way of example) an ACK that is sent directly to a remote phone via its Contact: header address. Is this the _only_ way of doing this, or may ACK also be passed through a SIP proxy?
I found that my Kamailio setup does not forward ACK, and I wonder why; whether that is a common refusal, or my fault in modifying the proxy script.
I am working on an IPv4-only to IPv6-only translation proxy, and would like to leave the DNS-related work to a more advanced SIP proxy. The translator is supposed to be small/simple, so it can be integrated into home routers. I would like to avoid DNS resolution (and its delays) for Contact: URIs.
Proxy script, https://gitlab.com/arpa2/mkroot/-/blob/master/contrib/sip-trunk/etc/kamailio...
SIPproxy64 translator, https://gitlab.com/0cpm/sipproxy64
Thanks, -Rick
Rick van Rein writes:
RFC 3261 gives (by way of example) an ACK that is sent directly to a remote phone via its Contact: header address. Is this the _only_ way of doing this, or may ACK also be passed through a SIP proxy?
If your Kamailio adds Route header to INVITE, ACK will be routed based on that instead of Contact URI.
-- Juha
Thanks Juha/list,
For stating clearly what the expected behaviour was...
If your Kamailio adds Record-Route header to INVITE, ACK will be routed based on that instead of Contact URI.
...because I had an error in my routing code. I was stripping 2 entire Route: headers instead of 2 Route: URIs from such headers. That solved my problem.
(And it was not a Kamailio problem, but in my own SIPproxy64 code.)
Cheers, -Rick
Sorry about the typo, Kamailio needs to add Record-Route header to INVITE and then it will route ACK based on Route header.
-- Juha
Thanks Juha,
Sorry about the typo, Kamailio needs to add Record-Route header to INVITE and then it will route ACK based on Route header.
Of course. It does mean that I am dependent on the proxy; and so, that I might also choose to route any ACK messages with !uri==myself. I'll play with these options a little. Clearly, you are suggesting that a proxy may well relay ACK messages.
Meanwhile, I'm wondering if Contact: headers as stored for follow-ups like ACK and REFER shouldn't always point to a SIP host (phone), so that I might need to add DNS for host-resolution only (no SRV). That would be a mild complication (mostly adding concurrency) that I could consider.
-Rick