Re: [SR-Users] How Kamailio processes SIP ACK on local 4XX reply?

2020-05-11 Thread Daniel-Constantin Mierla
Hello,

the problem here is that the ACK has Route headers and looks like the
ACK inside dialog.

The 407 is for a re-INVITE, so the To-tag is present, it is not
generated by sl module to be able to filter it out. It gets to config
where the requests are routed using loose_route() like a request part of
a dialog.

I haven't checked the specs right not for a 100% accurate answer, but
ACK for a failure code is hop-by-hop, it should have no Route headers,
being intended for next hop only, and I expect most UA implementation do
it like this, not having similar reports in more or less 20 years.

If the ACK will be without Route headers, it should be stopped locally.
You can try to play with the order of checks for transaction and use of
other tm functions to detect such case (eventually combined with htable)
and drop the ACK.

Cheers,
Daniel

On 07.05.20 17:10, Denys Pozniak wrote:
> Hello!
>
> I have some misunderstanding regarding the processing of SIP ACK on
> local Kamailio 4xx reply (eg 407 Proxy Authentication Required).
> In the picture below you can see that such a message just goes through
> the proxy and moreover gets into the *request_route* section.
> I expect this SIP ACK to be consumed by the sl module without hitting
> script logic.
>
>
>
> I put the part below to the very top of the *request_route* section:
>
> *request_route* {
>
> if ( is_method("ACK") ) {
>         t_check_trans();
>         $var(error) = $rc;
>         xlog("L_ERR", "[CATCH_ACK] m=$rm cseq=$cs ru=$ru
> err=$var(error) [$ci]");
> }
> 
>
>
> And as a result, I detected in syslog:
>
> May  7 16:15:34 test-edge /usr/sbin/kamailio[11642]: ERROR:
> 

[SR-Users] How Kamailio processes SIP ACK on local 4XX reply?

2020-05-07 Thread Denys Pozniak
Hello!

I have some misunderstanding regarding the processing of SIP ACK on local
Kamailio 4xx reply (eg 407 Proxy Authentication Required).
In the picture below you can see that such a message just goes through the
proxy and moreover gets into the *request_route* section.
I expect this SIP ACK to be consumed by the sl module without hitting
script logic.

[image: image.png]

I put the part below to the very top of the *request_route* section:

*request_route* {

if ( is_method("ACK") ) {
t_check_trans();
$var(error) = $rc;
xlog("L_ERR", "[CATCH_ACK] m=$rm cseq=$cs ru=$ru err=$var(error)
[$ci]");
}



And as a result, I detected in syslog:

May  7 16:15:34 test-edge /usr/sbin/kamailio[11642]: ERROR: