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
Geoffrey Mina wrote:
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 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!
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@evaristesys.com wrote:
Geoffrey Mina wrote:
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 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) (678) 954-0670 Direct : (+1) (678) 954-0671
-
Alex Balashov -
Geoffrey Mina