[SR-Users] handling of locally generated 478 errors
Daniel-Constantin Mierla
miconda at gmail.com
Fri Nov 27 14:08:06 CET 2020
On 27.11.20 14:05, Daniel-Constantin Mierla wrote:
>
> Hello,
>
> you should be able to disable sending internal replies inside tm in
> case of t_relay() failure with:
>
> *
> https://www.kamailio.org/docs/modules/stable/modules/tm.html#tm.f.t_set_disable_internal_reply
>
> The to handling in the IF branch of t_relay() execution if it returns
> false. There is no need to use event_route from sl module in this case.
>
^^^ above, somehow, parts got removed, was supposed to be:
Then do error handling in the ...
> Cheers,
> Daniel
>
> On 27.11.20 09:41, Henning Westerholt wrote:
>>
>> Hello,
>>
>>
>>
>> any comment on this topic? Would be great to get an opinion at least
>> on the first question, then I could document it or open an issue for it.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Henning
>>
>>
>>
>> --
>>
>> Henning Westerholt – https://skalatan.de/blog/
>> <https://skalatan.de/blog/>
>>
>> Kamailio services – https://gilawa.com <https://gilawa.com/>
>>
>>
>>
>> *From:*Henning Westerholt
>> *Sent:* Wednesday, November 25, 2020 6:53 PM
>> *To:* Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
>> *Cc:* Kamailio (SER) - Development Mailing List
>> <sr-dev at lists.kamailio.org>
>> *Subject:* handling of locally generated 478 errors
>>
>>
>>
>> Hello,
>>
>>
>>
>> I want to ask for your opinion on the best approach regarding the
>> handling of locally generated 478 errors.
>>
>>
>>
>> To give an example, like the ones generated from TM during t_relay()
>> on an unresolvable destination.
>>
>>
>>
>> Nov 25 17:40:13 kamailio[19345]: ERROR: {28607414 INVITE
>> bba500ac-a9df-1239-6693-00505682c04d} tm [ut.h:286]: uri2dst2():
>> failed to resolve "invalid.skalatan.de" :unresolvable A or AAAA
>> request (-7)
>> Nov 25 17:40:13 kamailio[19345]: ERROR: {28607414 INVITE
>> bba500ac-a9df-1239-6693-00505682c04d} tm [t_fwd.c:1738]:
>> t_forward_nonack(): failure to add branches
>> Nov 25 17:40:13 kamailio[19345]: CRITICAL: {28607414 INVITE
>> bba500ac-a9df-1239-6693-00505682c04d} rtpengine
>> [../../core/parser/../ip_addr.h:658]: ip_addr2sbuf(): unknown address
>> family 0
>>
>>
>>
>> These errors will not show up in onreply or failure_route. A long
>> time ago this was discussed on the list [1], as some functionality
>> were phased out out that support these scenarios.
>>
>>
>>
>> Kamailio will try to generate a 478 with TM, this will obviously fail
>> as well, and then generate a 478 with SL.
>>
>>
>>
>> Question 1)
>>
>>
>>
>> Is this intentional that the internally generated 478 is not showing
>> up in the failure_route, like for for 408? This has been tested
>> several times, but it is a complicated configuration.
>>
>>
>>
>> Question 2)
>>
>>
>>
>> Are there any other (better) ideas how to handle that besides using a
>> “event_route[sl:local-response]” to catch this, e.g. to tear down
>> otherwise stale rtpengine sessions etc..? As a side note,
>> event_route[tm:local-response] seems not to work as well because of
>> the tm failure.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Henning
>>
>>
>>
>> [1]
>> https://lists.kamailio.org/pipermail/sr-users/2011-June/069020.html
>> <https://lists.kamailio.org/pipermail/sr-users/2011-June/069020.html>
>>
>>
>>
>> --
>>
>> Henning Westerholt – https://skalatan.de/blog/
>> <https://skalatan.de/blog/>
>>
>> Kamailio services – https://gilawa.com <https://gilawa.com/>
>>
>>
>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201127/fd8792a3/attachment.htm>
More information about the sr-users
mailing list