Closed #1998.
--
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/1998#event-2457839711___
Kamailio (SER) - Development Mailing List
sr-dev@l
Like mentioned by comments here, the behavior is as expected by specs, the
proxy has to resolve the R-URI address for forwarding. The ACK following 200ok
is independent of INVITE transaction (can have also different path than the
INVITE, a matter of Record-Route headers).
Use other variants if
that's already the case if you use IP addresses in 200 OK => ACK.
The parameter you are speaking can not be implemented in core modules like tm,
because that would mean implementing a tracking between transactions which is
totally out of scope for those modules. Again, mechanisms external extern
yeah right now we are using dialog module for tracking those things but there
should be an option to use same tcp connection across the call if connection is
alive.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://gi
I'm afraid that this is perfectly legitimate proxy behavior as per RFC.
If your 200 OK contact contains a FQDN as domain part, the ACK will have it
in the R-URI and Kamailio will forcefully have to resolve it before
relaying and there is no guarantee that the result will be the same.
Also don't for
### Description
We are converting udp call to tcp call in kamailio. kamailio sending out an
invite to a destination. Before sending, kamailio resolving that destination
domain to IP. After receiving invite request, Destination send 180 and 200 OK .
200 Ok contact contains the domain name of de
