Apologies... sent directly to Alex and not the list.
On Tue, Nov 10, 2009 at 12:02 PM, Geoffrey Mina geoffreymina@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@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@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@evaristesys.com wrote:
geoffreymina@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