[OpenSIPS-Users] Second Contact when sending 302 Redirect using async avp_db_query
Calvin Ellison
calvin.ellison at voxox.com
Mon Mar 9 16:37:43 EST 2020
Thanks, Jon. Confirmed, updating $ru and not using append_to_reply solved
the problem.
After a moment of contemplation, I realized it makes sense that a 3xx
response Contact would be based on the request URI
Regards,
*Calvin Ellison*
Senior Voice Operations Engineer
calvin.ellison at voxox.com
+1 (213) 285-0555
-----------------------------------------------
*voxox.com <http://www.voxox.com/> *
5825 Oberlin Drive, Suite 5
San Diego, CA 92121
[image: Voxox]
On Fri, Mar 6, 2020 at 5:58 PM Jon Abrams <ffshoh at gmail.com> wrote:
> OpenSIPs is using the contents of the RURI for the contact header in the
> response.
>
> I seem to recall this working in 2.2 as well:
>
> $ru = "";
> append_to_reply( "<sip:" + $rU + "@" + $si + ":" + $sp + ";npdi+">");
>
> If you set the package and/or shared memory larger you can delay the
> fragmentation. In my scenario we were using the userblacklist feature and
> updating several large lists multiple times an hour. This was triggering
> the problem eventually.
> You may never run into it with the caching depending on the volume and
> allocation patterns. But if you start having response time spikes after a
> long uptime, check the logs for memory related messages.
>
> - Jon Abrams
>
> On Fri, Mar 6, 2020 at 5:57 PM Calvin Ellison <calvin.ellison at voxox.com>
> wrote:
>
>>
>> On Fri, Mar 6, 2020 at 2:56 PM Jon Abrams <ffshoh at gmail.com> wrote:
>>
>>> Async does indeed trigger the transaction creation. You may need to
>>> update the $ru variable and not use the append_to_reply. Or at least that's
>>> how I solved this in the past.
>>>
>>
>> What's the connection between the request's URI and a reply's Contact? I
>> saw $ru mentioned regarding a similar issue back in 2009 but didn't
>> understand how it solves the problem.
>>
>>
>>> I would caution somewhat about using the caching (and possibly the
>>> async), as memory fragmentation may become a problem after sustained usage.
>>>
>>
>> Is there any guidance available for how to deal with this? Is this
>> addressed via opensips things like hash size or linux things like shared
>> memory configuration?
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://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/20200309/a6b9a7d2/attachment.html>
More information about the Users
mailing list