I ended up doing this right before the call to loose_route():
if ((is_method("ACK") || is_method("BYE")) &&
!isdsturiset()) {
handle_ruri_alias();
if ($du != $null) {
$ru = $du;
$du = $null;
On Thu, Aug 29, 2013 at 3:53 AM, Daniel-Constantin Mierla wrote:
> what device is at 701? The 200ok receved from it has the contact address
> with the IP of kamailio:
>
SFLPhone
> It seems there is a NAT between your kamailio and 701, as kamailio adds
> alias parameter to Contact in 200ok. T
Hello,
On 8/28/13 8:22 PM, Marc Soda wrote:
Thanks, I appreciate it.
In this setup the there are 2 endpoints (700 and 701) peered up to an
Asterisk server (172.16.60.6) via a Kamailio proxy (172.16.60.20).
700 (172.16.60.28) is calling 701 (172.16.3.65). When 701 answers
the OK is sent to
Thanks, I appreciate it.
In this setup the there are 2 endpoints (700 and 701) peered up to an
Asterisk server (172.16.60.6) via a Kamailio proxy (172.16.60.20). 700
(172.16.60.28) is calling 701 (172.16.3.65). When 701 answers the OK is
sent to the proxy and then to Asterisk. Asterisk is then
If it is eth0 of the same server, then is the kernel sending via
loopback interface at it detects the destination is itself.
You should paste here ngrep with the sip traffic from invite to bye in
order to give more hints about what is going wrong there.
Cheers,
Daniel
On 8/28/13 3:09 PM, Mar
I think I found my missing ACKs! Can anyone tell me why they work be
being sent to the loopback interface? The destination address is
still the external (eth0) IP.
--
Marc Soda, Sr. Systems Engineer
*CoreDial, LLC* | www.coredial.com
1787 Sentry Parkway West, Building 16, Suite 100, Blue Be
