Translate "486 Busy Here" to "600 Busy Everwhere"

[geoffreymina]

Hello,
I have a need to translate a 486 from my asterisk server to a 600 when sending upstream to my carrier. The problem I am seeing is that when I return 486, the carrier re-presents the call to my next server in the SRV rotation... I really want the 486 to be a final disposition, so I am assuming sending a 600 would solve my issue.

I am not sure how to go about forwarding the message, but modifying the SIP code... is that even allowed?

This would be something like what I'm trying to do:

failure_route[1]{
if(t_check_status("
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Alex Balashov]

geoffreymina@... wrote:

> Hello,
> I have a need to translate a 486 from my asterisk server to a 600 when
> sending upstream to my carrier. The problem I am seeing is that when I
> return 486, the carrier re-presents the call to my next server in the
> SRV rotation... I really want the 486 to be a final disposition, so I am
> assuming sending a 600 would solve my issue.
>
> I am not sure how to go about forwarding the message, but modifying the
> SIP code... is that even allowed?
>
> This would be something like what I'm trying to do:
>
> failure_route[1]{
> if(t_check_status("

Sure, you can do that.  It is not a good idea to do so in principle
because it violates how proxies should behave;  proxies are very thin
interoperation layers that are designed to statefully pass requests and
replies back and forth more or less strictly as intended by the
endpoints involved, and a B2BUA would more ideally fit your goal.
Nevertheless, it is possible.

failure_route[1] {

         if(t_was_cancelled())
                 exit;

         if(t_check_status("486")) {
                 t_reply("603", "Declined");
                 exit;
         }
}


--
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) [phone]
Direct  : (+1) [phone]

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[geoffreymina]

Apologies... sent directly to Alex and not the list.

On Tue, Nov 10, 2009 at 12:02 PM, Geoffrey Mina <geoffreymina@...> wrote:

> Alex,
> Thanks for the info.  We are on the same page about what a proxy
> should, and should not do... however, I am strugging with my ITSP
> (Level3) a bit on this.  Unfortunately, Asterisk is my media end-point
> here and there is no mechanism in Asterisk to send back a 600.  Level3
> is exhibiting very odd behaivor, and I have a ticket open with them,
> but who knows if it will ever go anywhere.
>
> CallID: 1627795841_10332@...
> Level3 --> INVITE --> Kamailio --> Asterisk
> Asterisk --> 183 Progress --> Kamailio --> Level3
> Asterisk --> 486 Busy --> Kamailio --> Level3
> Level3 --> ACK --> Kamailio --> Asterisk
>
> [at this point Level3 IMMEDIATELY sends me another presentation of the
> call with a different CallID and the process repeats]
>
> CallID: 604627041_120490736@...
> Level3 --> INVITE --> Kamailio --> Asterisk
> Asterisk --> 183 Progress --> Kamailio --> Level3
> Asterisk --> 486 Busy --> Kamailio --> Level3
> Level3 --> ACK --> Kamailio --> Asterisk
>
>
> I am pretty sure I am in the right here, and Level3 shouldn't be
> failing over in a 486 scenario... unfortunately my customer doesn't
> care why our systems aren't talking properly :)
>
> Thanks!
>
>
>
> On Tue, Nov 10, 2009 at 10:38 AM, Alex Balashov
> <abalashov@...> wrote:
>> geoffreymina@... wrote:
>>>
>>> Hello,
>>> I have a need to translate a 486 from my asterisk server to a 600 when
>>> sending upstream to my carrier. The problem I am seeing is that when I
>>> return 486, the carrier re-presents the call to my next server in the SRV
>>> rotation... I really want the 486 to be a final disposition, so I am
>>> assuming sending a 600 would solve my issue.
>>>
>>> I am not sure how to go about forwarding the message, but modifying the
>>> SIP code... is that even allowed?
>>>
>>> This would be something like what I'm trying to do:
>>>
>>> failure_route[1]{
>>> if(t_check_status("
>>
>> Sure, you can do that.  It is not a good idea to do so in principle because
>> it violates how proxies should behave;  proxies are very thin interoperation
>> layers that are designed to statefully pass requests and replies back and
>> forth more or less strictly as intended by the endpoints involved, and a
>> B2BUA would more ideally fit your goal. Nevertheless, it is possible.
>>
>> failure_route[1] {
>>
>>        if(t_was_cancelled())
>>                exit;
>>
>>        if(t_check_status("486")) {
>>                t_reply("603", "Declined");
>>                exit;
>>        }
>> }
>>
>>
>> --
>> Alex Balashov - Principal
>> Evariste Systems
>> Web     : http://www.evaristesys.com/
>> Tel     : (+1) [phone]
>> Direct  : (+1) [phone]
>>
>

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Alex Balashov]

Geoffrey Mina wrote:

> CallID: 604627041_120490736@...
> Level3 --> INVITE --> Kamailio --> Asterisk
> Asterisk --> 183 Progress --> Kamailio --> Level3
> Asterisk --> 486 Busy --> Kamailio --> Level3
> Level3 --> ACK --> Kamailio --> Asterisk

I can't explain the presentation of a new and different Caller ID;
that's bizarre.

As far as failing over on response codes that really, logically should
not be failed on, well, that's a fairly standard bit of idiocy on the
part of virtually all the Tier 1s and/or nationwide CLECs and/or big
origination carriers.  Their gear is just configured to roll over on any
4xx/5xx class errors.

I'll tell you what my solution is to this problem:

Since many of these origination providers don't properly map SIP replies
to ISUP in ways that result in correspondingly meaningful messages being
played to callers by originating switches[1], I take matters into my own
hands - at the risk of burning up some trunks.  I have my customers run
SEMS (media server) with their own recordings of busy signals and other
messages they want played and have the proxy serially fork/branch to it
when such a media rsource is needed, e.g.

    append_branch();

    $rU = "busy";
    $rd = "mediaserver.ip";

    t_relay();

Perhaps you should investigate that as a solution to your problem;  if
the callee is busy, "trap" the initial call leg and send it to your own
feature box.

Of course, this can burn up trunks in perpetuity if the caller doesn't
hang up.  It is also quite undesirable if you're paying usage on inbound.

-- Alex

[1] One big Level3 reseller - it rhymes with candbidth.zom - reacts to
all negative SIP replies with the propogation of a "this number is out
of service" reply on the ISUP layer regardless of what the SIP reply
code actually was, including 486 Busy!

--
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) [phone]
Direct  : (+1) [phone]

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[geoffreymina]

I am actually having the issue with this Level3 reseller
(candbith.zom).  They have said they are forwarding the 486 upstream
and Level3 is acting on it strangely.

I guess my search continues.  I'll wait to hear what Level3 has to say
for themselves.


On Tue, Nov 10, 2009 at 12:27 PM, Alex Balashov
<abalashov@...> wrote:

> Geoffrey Mina wrote:
>
>> CallID: 604627041_120490736@...
>> Level3 --> INVITE --> Kamailio --> Asterisk
>> Asterisk --> 183 Progress --> Kamailio --> Level3
>> Asterisk --> 486 Busy --> Kamailio --> Level3
>> Level3 --> ACK --> Kamailio --> Asterisk
>
> I can't explain the presentation of a new and different Caller ID; that's
> bizarre.
>
> As far as failing over on response codes that really, logically should not
> be failed on, well, that's a fairly standard bit of idiocy on the part of
> virtually all the Tier 1s and/or nationwide CLECs and/or big origination
> carriers.  Their gear is just configured to roll over on any 4xx/5xx class
> errors.
>
> I'll tell you what my solution is to this problem:
>
> Since many of these origination providers don't properly map SIP replies to
> ISUP in ways that result in correspondingly meaningful messages being played
> to callers by originating switches[1], I take matters into my own hands - at
> the risk of burning up some trunks.  I have my customers run SEMS (media
> server) with their own recordings of busy signals and other messages they
> want played and have the proxy serially fork/branch to it when such a media
> rsource is needed, e.g.
>
>   append_branch();
>
>   $rU = "busy";
>   $rd = "mediaserver.ip";
>
>   t_relay();
>
> Perhaps you should investigate that as a solution to your problem;  if the
> callee is busy, "trap" the initial call leg and send it to your own feature
> box.
>
> Of course, this can burn up trunks in perpetuity if the caller doesn't hang
> up.  It is also quite undesirable if you're paying usage on inbound.
>
> -- Alex
>
> [1] One big Level3 reseller - it rhymes with candbidth.zom - reacts to all
> negative SIP replies with the propogation of a "this number is out of
> service" reply on the ISUP layer regardless of what the SIP reply code
> actually was, including 486 Busy!
>
> --
> Alex Balashov - Principal
> Evariste Systems
> Web     : http://www.evaristesys.com/
> Tel     : (+1) [phone]
> Direct  : (+1) [phone]
>

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[geoffreymina]

One question on this...

In my scenario, would using t_reply in failure_route send the response
to the party who sent the INVITE or the party who sent a message which
caused Kamailio to end up in failure_route?

On Tue, Nov 10, 2009 at 10:38 AM, Alex Balashov
<abalashov@...> wrote:

> geoffreymina@... wrote:
>>
>> Hello,
>> I have a need to translate a 486 from my asterisk server to a 600 when
>> sending upstream to my carrier. The problem I am seeing is that when I
>> return 486, the carrier re-presents the call to my next server in the SRV
>> rotation... I really want the 486 to be a final disposition, so I am
>> assuming sending a 600 would solve my issue.
>>
>> I am not sure how to go about forwarding the message, but modifying the
>> SIP code... is that even allowed?
>>
>> This would be something like what I'm trying to do:
>>
>> failure_route[1]{
>> if(t_check_status("
>
> Sure, you can do that.  It is not a good idea to do so in principle because
> it violates how proxies should behave;  proxies are very thin interoperation
> layers that are designed to statefully pass requests and replies back and
> forth more or less strictly as intended by the endpoints involved, and a
> B2BUA would more ideally fit your goal. Nevertheless, it is possible.
>
> failure_route[1] {
>
>        if(t_was_cancelled())
>                exit;
>
>        if(t_check_status("486")) {
>                t_reply("603", "Declined");
>                exit;
>        }
> }
>
>
> --
> Alex Balashov - Principal
> Evariste Systems
> Web     : http://www.evaristesys.com/
> Tel     : (+1) [phone]
> Direct  : (+1) [phone]
>

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Alex Balashov]

My understanding is that it would be the former - you can't really  
reply to a reply.  :-) Besides, this technique is used in other  
contexts;  for example, final failure is signaled out of failure  
routes to the calling party when dispatcher rollover runs out of  
gateways to serially fork across.

--
Sent from mobile device

On Nov 10, 2009, at 8:49 PM, Geoffrey Mina <geoffreymina@...>  
wrote:

> One question on this...
>
> In my scenario, would using t_reply in failure_route send the response
> to the party who sent the INVITE or the party who sent a message which
> caused Kamailio to end up in failure_route?
>
> On Tue, Nov 10, 2009 at 10:38 AM, Alex Balashov
> <abalashov@...> wrote:
>> geoffreymina@... wrote:
>>>
>>> Hello,
>>> I have a need to translate a 486 from my asterisk server to a 600  
>>> when
>>> sending upstream to my carrier. The problem I am seeing is that  
>>> when I
>>> return 486, the carrier re-presents the call to my next server in  
>>> the SRV
>>> rotation... I really want the 486 to be a final disposition, so I am
>>> assuming sending a 600 would solve my issue.
>>>
>>> I am not sure how to go about forwarding the message, but  
>>> modifying the
>>> SIP code... is that even allowed?
>>>
>>> This would be something like what I'm trying to do:
>>>
>>> failure_route[1]{
>>> if(t_check_status("
>>
>> Sure, you can do that.  It is not a good idea to do so in principle  
>> because
>> it violates how proxies should behave;  proxies are very thin  
>> interoperation
>> layers that are designed to statefully pass requests and replies  
>> back and
>> forth more or less strictly as intended by the endpoints involved,  
>> and a
>> B2BUA would more ideally fit your goal. Nevertheless, it is possible.
>>
>> failure_route[1] {
>>
>>        if(t_was_cancelled())
>>                exit;
>>
>>        if(t_check_status("486")) {
>>                t_reply("603", "Declined");
>>                exit;
>>        }
>> }
>>
>>
>> --
>> Alex Balashov - Principal
>> Evariste Systems
>> Web     : http://www.evaristesys.com/
>> Tel     : (+1) [phone]
>> Direct  : (+1) [phone]
>>

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users