Apologies... sent directly to Alex and not the list.
On Tue, Nov 10, 2009 at 12:02 PM, Geoffrey Mina <geoffreymina(a)gmail.com> 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(a)4.55.4.227
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(a)4.55.20.99
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(a)evaristesys.com> wrote:
geoffreymina(a)gmail.com 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) (678) 954-0670
Direct : (+1) (678) 954-0671