[SR-Users] Last negative 5XX reply not getting relayed
Federico Cabiddu
federico.cabiddu at gmail.com
Tue May 15 09:48:11 CEST 2018
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 <pojogas at gmail.com> 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 <abalashov at evaristesys.com
> > 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: "514XXXXXXX" <sip: 514XXXXXXX @205.xx.xx.221>;tag=tXj0NHrje9jNS
>> > To: <sip:450XXXXXXX at 65.xx.xx.167>;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;receive
>> d=205.xx.xx.221
>> > From: "514XXXXXXX" <sip:514XXXXXXX at 205.xx.xx.221>;tag=tXj0NHrje9jNS
>> > To: <sip:450XXXXXXX at 65.xx.xx.167>;tag=31a2c69b5d434ef4a60796e26f
>> 568bf0-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 at 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 at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180515/02bae5fa/attachment.html>
More information about the sr-users
mailing list