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!