10 Nov
2009
10 Nov
'09
6:03 p.m.
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
10 Nov
10 Nov
6:27 p.m.
New subject: [Kamailio-Users] Translate "486 Busy Here" to "600 Busy Everwhere"
Geoffrey Mina wrote:
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 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
8:23 p.m.
New subject: [Kamailio-Users] Translate "486 Busy Here" to "600 Busy Everwhere"
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(a)evaristesys.com> wrote:
Geoffrey Mina wrote:
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 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
5305
days inactive
5305
days old
2 comments
2 participants
participants (2)
-
Alex Balashov -
Geoffrey Mina