Re: [SR-Users] Last negative 5XX reply not getting relayed

2018-05-15 Thread Sergiu Pojoga 
Thanks Federico, that did the trick!

On Tue, May 15, 2018 at 3:51 AM, Alex Balashov 
wrote:

> On Tue, May 15, 2018 at 09:48:11AM +0200, Federico Cabiddu wrote:
>
> > Hi,
> > rfc 3261 (the one and only) states at section16.7
> >
> > "
> >  A proxy which receives a 503 (Service Unavailable) response
> >  SHOULD NOT forward it upstream unless it can determine that any
> >  subsequent requests it might proxy will also generate a 503.
> >  In other words, forwarding a 503 means that the proxy knows it
> >  cannot service any requests, not just the one for the Request-
> >  URI in the request which generated the 503.  If the only
> >  response that was received is a 503, the proxy SHOULD generate
> >  a 500 response and forward that upstream.
> > "
> >
> > So Kamailio behavior is absolutely legitimate. If you want to change it
> you
> > have to use the following tm parameter: http://www.
> > kamailio.org/docs/modules/devel/modules/tm.html#remap_503_500.
>
> Oh yeah. How about that! (Re)learn something new every day. Cheers
> Federico! :-)
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Last negative 5XX reply not getting relayed

2018-05-15 Thread Alex Balashov 
On Tue, May 15, 2018 at 09:48:11AM +0200, Federico Cabiddu wrote:

> Hi,
> rfc 3261 (the one and only) states at section16.7
> 
> "
>  A proxy which receives a 503 (Service Unavailable) response
>  SHOULD NOT forward it upstream unless it can determine that any
>  subsequent requests it might proxy will also generate a 503.
>  In other words, forwarding a 503 means that the proxy knows it
>  cannot service any requests, not just the one for the Request-
>  URI in the request which generated the 503.  If the only
>  response that was received is a 503, the proxy SHOULD generate
>  a 500 response and forward that upstream.
> "
> 
> So Kamailio behavior is absolutely legitimate. If you want to change it you
> have to use the following tm parameter: http://www.
> kamailio.org/docs/modules/devel/modules/tm.html#remap_503_500.

Oh yeah. How about that! (Re)learn something new every day. Cheers
Federico! :-)

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Last negative 5XX reply not getting relayed

2018-05-15 Thread Federico Cabiddu 
Hi,
rfc 3261 (the one and only) states at section16.7

"
 A proxy which receives a 503 (Service Unavailable) response
 SHOULD NOT forward it upstream unless it can determine that any
 subsequent requests it might proxy will also generate a 503.
 In other words, forwarding a 503 means that the proxy knows it
 cannot service any requests, not just the one for the Request-
 URI in the request which generated the 503.  If the only
 response that was received is a 503, the proxy SHOULD generate
 a 500 response and forward that upstream.
"

So Kamailio behavior is absolutely legitimate. If you want to change it you
have to use the following tm parameter: http://www.
kamailio.org/docs/modules/devel/modules/tm.html#remap_503_500.

Best regards,

Federico

On Mon, May 14, 2018 at 6:29 PM, Sergiu Pojoga  wrote:

> Hi Alex,
>
> # - tm params -
> modparam("tm", "failure_reply_mode", 3)
>
> I use drouting, here's the main logic.
>
> request_route {
>
>  ...
>
> if (is_method("INVITE") && !has_totag()) {
> ...
>
> # handle DR failure
> t_on_failure("MANAGE_DR_FAILURE");
>
> if (!do_routing("$avp(drgroup)")) {
>   sl_reply("503", "Unknown destination");
>   exit;
>  }
>
> # Relay the request to gateway
> route(DR_RELAY);
> }
>
> }
>
> # DR relay
> route[DR_RELAY] {
>
> if (!route(RELAY)) {
> sl_reply_error();
> };
> exit;
> }
>
> # DRouting failure route
> failure_route[MANAGE_DR_FAILURE] {
>
> if (t_is_canceled()) {
> exit;
> }
>
> if (t_check_status("486|600")) {
> xlog("L_INFO", "received BUSY, stop trying");  # --
> curious, 486 gets relayed fine
> exit;
> }
>
> # try next GW
> if (use_next_gw()) {
> t_on_failure("MANAGE_DR_FAILURE");
>
> xlog("L_INFO", "MANAGE_DR_FAILURE: Call from <$fu> with
> username <$fU> going to <$ru>\n");
> route(RELAY);
> exit;
>
> # -- Trunk failover to PSTN number
> } else if (is_avp_set("$avp(s:failover)") && $avp(direction) ==
> "in") {
> $ru="sip:" + $avp(s:failover) + "@someothergateway.com";
> # -- basic routing, to improve by sending back to DRouting with updated $rU
> xlog("L_INFO", "MANAGE_DR_FAILURE: No more gateways,
> sending call to trunk failover destination <$ru>...\n");
> route(RELAY);
>
> } else {
> xlog("L_WARN", "No more routes available\n");
> #t_reply ("503", "Service Unavailable");# -- why
> do we have to force a reply instead of proxy relaying whatever it is
> exit;
> }
> }
>
>
>
> On Mon, May 14, 2018 at 11:34 AM, Alex Balashov  > wrote:
>
>> Hi,
>>
>> 1. Do you have a failure_route for this transaction? If so, can you
>> provide it?
>>
>> 2. Make sure the `failure_reply_mode` modparam for TM is set to 3, which
>> is default anyway:
>>
>> https://kamailio.org/docs/modules/5.1.x/modules/tm.html#tm.p
>> .failure_reply_mode
>>
>> -- Alex
>>
>> On Mon, May 14, 2018 at 11:33:15AM -0400, Sergiu Pojoga wrote:
>>
>> > Not sure if it's a default Kamailio behavior or something I'm doing
>> wrong...
>> >
>> > When receiving a negative reply for an INVITE (more like in the 5xx
>> range),
>> > proxy doesn't relay the message to the originator but instead issues
>> it's
>> > own "500 Service Unavailable".
>> >
>> > That doesn't happen, from observations so far, to "603 Declined" or "486
>> > Busy Here" or "404 Not Found" or "200 OK" replies.
>> >
>> > *For example, here's the negative reply proxy receives from the callee:*
>> >
>> > 2018/05/14 10:52:37.716627 65.XX.XX.166:5060 -> 65.XX.XX.167:5060
>> > SIP/2.0 503 Service Unavailable
>> > Via: SIP/2.0/UDP
>> > 65.xx.xx.167;branch=z9hG4bK9223.00b4f3143d245a895c4bb6a107ad
>> d258.0;received=65.xx.xx.167;rport=5060
>> > Via: SIP/2.0/UDP
>> > 205.xx.xx.221;received=205.xx.xx.221;rport=5060;branch=z9hG4
>> bKQ4XpXga0vgZ8B
>> > From: "514XXX" ;tag=tXj0NHrje9jNS
>> > To: ;tag=as18e452b7
>> > Call-ID: 48eac296-d229-1236-a685-005056a149a4
>> > CSeq: 122818714 INVITE
>> > Server: Asterisk
>> > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>> INFO,
>> > PUBLISH, MESSAGE
>> > Supported: replaces, timer
>> > Session-Expires: 1800;refresher=uas
>> > X-Asterisk-HangupCause: Subscriber absent
>> > X-Asterisk-HangupCauseCode: 20
>> > Content-Length: 0
>> >
>> > *Here's what the originator gets in the final message:*
>> >
>> > 2018/05/14 10:52:37.718143 65.xx.xx.167:5060 -> 205.xx.xx.221:5060
>> > SIP/2.0 500 Service Unavailable
>> > Via: SIP/2.0/UDP
>> >

Re: [SR-Users] Last negative 5XX reply not getting relayed

2018-05-14 Thread Alex Balashov 
Hi,

1. Do you have a failure_route for this transaction? If so, can you provide it?

2. Make sure the `failure_reply_mode` modparam for TM is set to 3, which
is default anyway:

https://kamailio.org/docs/modules/5.1.x/modules/tm.html#tm.p.failure_reply_mode

-- Alex

On Mon, May 14, 2018 at 11:33:15AM -0400, Sergiu Pojoga wrote:

> Not sure if it's a default Kamailio behavior or something I'm doing wrong...
> 
> When receiving a negative reply for an INVITE (more like in the 5xx range),
> proxy doesn't relay the message to the originator but instead issues it's
> own "500 Service Unavailable".
> 
> That doesn't happen, from observations so far, to "603 Declined" or "486
> Busy Here" or "404 Not Found" or "200 OK" replies.
> 
> *For example, here's the negative reply proxy receives from the callee:*
> 
> 2018/05/14 10:52:37.716627 65.XX.XX.166:5060 -> 65.XX.XX.167:5060
> SIP/2.0 503 Service Unavailable
> Via: SIP/2.0/UDP
> 65.xx.xx.167;branch=z9hG4bK9223.00b4f3143d245a895c4bb6a107add258.0;received=65.xx.xx.167;rport=5060
> Via: SIP/2.0/UDP
> 205.xx.xx.221;received=205.xx.xx.221;rport=5060;branch=z9hG4bKQ4XpXga0vgZ8B
> From: "514XXX" ;tag=tXj0NHrje9jNS
> To: ;tag=as18e452b7
> Call-ID: 48eac296-d229-1236-a685-005056a149a4
> CSeq: 122818714 INVITE
> Server: Asterisk
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> X-Asterisk-HangupCause: Subscriber absent
> X-Asterisk-HangupCauseCode: 20
> Content-Length: 0
> 
> *Here's what the originator gets in the final message:*
> 
> 2018/05/14 10:52:37.718143 65.xx.xx.167:5060 -> 205.xx.xx.221:5060
> SIP/2.0 500 Service Unavailable
> Via: SIP/2.0/UDP
> 205.xx.xx.221;rport=5060;branch=z9hG4bKQ4XpXga0vgZ8B;received=205.xx.xx.221
> From: "514XXX" ;tag=tXj0NHrje9jNS
> To: ;tag=31a2c69b5d434ef4a60796e26f568bf0-9343
> Call-ID: 48eac296-d229-1236-a685-005056a149a4
> CSeq: 122818714 INVITE
> Server: Kamailio 5.1
> Content-Length: 0
> 
> I'd like any reply to be relayed back as is, unless I do some
> t_check_status() => t_reply() for specific reasons (which I have none at
> this point).
> 
> Thanks
> Sergiu

> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Last negative 5XX reply not getting relayed

2018-05-14 Thread Sergiu Pojoga 
Not sure if it's a default Kamailio behavior or something I'm doing wrong...

When receiving a negative reply for an INVITE (more like in the 5xx range),
proxy doesn't relay the message to the originator but instead issues it's
own "500 Service Unavailable".

That doesn't happen, from observations so far, to "603 Declined" or "486
Busy Here" or "404 Not Found" or "200 OK" replies.

*For example, here's the negative reply proxy receives from the callee:*

2018/05/14 10:52:37.716627 65.XX.XX.166:5060 -> 65.XX.XX.167:5060
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP
65.xx.xx.167;branch=z9hG4bK9223.00b4f3143d245a895c4bb6a107add258.0;received=65.xx.xx.167;rport=5060
Via: SIP/2.0/UDP
205.xx.xx.221;received=205.xx.xx.221;rport=5060;branch=z9hG4bKQ4XpXga0vgZ8B
From: "514XXX" ;tag=tXj0NHrje9jNS
To: ;tag=as18e452b7
Call-ID: 48eac296-d229-1236-a685-005056a149a4
CSeq: 122818714 INVITE
Server: Asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
X-Asterisk-HangupCause: Subscriber absent
X-Asterisk-HangupCauseCode: 20
Content-Length: 0

*Here's what the originator gets in the final message:*

2018/05/14 10:52:37.718143 65.xx.xx.167:5060 -> 205.xx.xx.221:5060
SIP/2.0 500 Service Unavailable
Via: SIP/2.0/UDP
205.xx.xx.221;rport=5060;branch=z9hG4bKQ4XpXga0vgZ8B;received=205.xx.xx.221
From: "514XXX" ;tag=tXj0NHrje9jNS
To: ;tag=31a2c69b5d434ef4a60796e26f568bf0-9343
Call-ID: 48eac296-d229-1236-a685-005056a149a4
CSeq: 122818714 INVITE
Server: Kamailio 5.1
Content-Length: 0

I'd like any reply to be relayed back as is, unless I do some
t_check_status() => t_reply() for specific reasons (which I have none at
this point).

Thanks
Sergiu
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users