[OpenSIPS-Users] ACK in failover for call setup

[Seth Schultz]

Liviu,

At some point we will most likely be upgrading to the latest LTS, but this
isn't scheduled anytime in the near future.

I applied the patch, but this didn't resolve the issue.

The problem, in a nutshell, appears to be that the local ACK/CANCEL is
created based on the initial INVITE (Internal->Internal), not the branch
INVITE (Internal->External).  This works great if all branches are
Internal->Internal, however it doesn't work in an N-branch scenario where
the other branches might be communicating with an External device.  The end
result is that the internal address is placed in the Via1 header for the
local ACK/CANCEL to the external gateway.

After making the modification to t_msgbuilder.c line 153 below, all ACKs
function correctly to all branches because we have a reply with the correct
external address (or internal address), however CANCEL from the internal
UAC to the External device is still broken because we don't have a reply.
 Is there a way to access the INVITE for the current branch and pull out
the Via1->host/port?  I apologize in advance if anything I am saying is
incorrect, this is really the first time I've ever looked at the source.

    set_hostport(&hp, (is_local(Trans))?0:req);

To

    if (rpl && rpl->via1)
    {
        hp.host = &rpl->via1->host;
        hp.port = &rpl->via1->port_str;
    }
    else
    {
        set_hostport(&hp, (is_local(Trans))?0:req);
    }

Thanks,
Seth

On Wed, Aug 27, 2014 at 5:31 AM, Liviu Chircu <liviu at opensips.org> wrote:

>  Hello Seth,
>
> Earlier this year, there were some important fixes related to
> set_advertised_address() which solved some memory corruption issues and
> fixed the IP used when creating multiple branches [1]. Unfortunately, they
> did not get backported to 1.9, since it was not supported anymore. If
> upgrading to 1.11 is not a possibility (although we highly recommend you do
> so), I've backported the patch for 1.9 [2].
>
> [1]: https://github.com/OpenSIPS/opensips/commit/ad92fa6ff6
> [2]: https://gist.github.com/liviuchircu/a72478ecd9a40588023d
>
> Best regards,
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 08/26/2014 01:51 AM, Seth Schultz wrote:
>
>   Răzvan,
>
>  After digging through the source code, I found the line of code causing
> my issues.  In the opensips_1_9 branch in t_msgbuilder.c on line 152 we have
>
>  ...
>          *set_hostport(&hp, (is_local(Trans))?0:req);*
>  via=via_builder(&via_len, Trans->uac[branch].request.dst.send_sock,
>  &branch_str, 0, Trans->uac[branch].request.dst.proto, &hp );
>  if (!via){
>  LM_ERR("no via header got from builder\n");
>  goto error;
>  }
>  *len+= via_len;
>  ...
>
>  Would it be incredibly stupid to modify it to always base the via on the
> reply?
>
>  ...
>      *hp.host=&rpl->via1->host;*
> *    hp.port=&rpl->via1->port_str;*
>     via=via_builder(&via_len, Trans->uac[branch].request.dst.send_sock,
>         &branch_str, 0, Trans->uac[branch].request.dst.proto, &hp );
>     if (!via){
>         LM_ERR("no via header got from builder\n");
>         goto error;
>     }
>     *len+= via_len;
>  ...
>
>  After making this modification it does have the correct Via address for
> all failure ACK replies.
>
>  Thanks,
> Seth
>
>
> On Fri, Aug 22, 2014 at 10:26 AM, Seth Schultz <sschultz at scholarchip.com>
> wrote:
>
>> Răzvan,
>>
>>  Unfortunately in my setup OpenSIPS is only using a single interface
>> 172.16.1.115.  The external IP NATing is handled by the firewall, so I
>> can't use force_send_socket, because it would still be 172.16.1.115.
>>
>>  Thanks,
>> Seth
>>
>> On Fri, Aug 22, 2014 at 5:07 AM, Răzvan Crainea <razvan at opensips.org>
>> wrote:
>>
>>>  Hi, Seth!
>>>
>>> So basically you want to change the outgoing interface for the second
>>> leg of the call, right? Instead of record_route_preset() function, have you
>>> considered using the force_send_socket() function? This forces OpenSIPS to
>>> switch the interfaces and should change the VIA headers properly without
>>> any issues. Let me know your answer
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20140827/c40330be/attachment.htm>