OK, thanks.
I suppose you have the "failed" flag set in do_accounting() ?
And before ending the INVITE processing, do you change the RURI (you
mentioned it originally has a username) ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit May 2017 Amsterdam
http://www.opensips.org/events/Summit-2017Amsterdam.html
On 04/26/2017 06:33 PM, Jim DeVito wrote:
Yes. And correct the script is rejecting the call at this point and
returning the 600 to my upstream.
On Wed, Apr 26, 2017 at 11:28 AM, Bogdan-Andrei Iancu
<[email protected] <mailto:[email protected]>> wrote:
Again, does the strange text correspond to the to_tn extra value ?
And the call is rejected by you from script ? it not ever proxied
further, right ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com <http://www.opensips-solutions.com>
OpenSIPS Summit May 2017 Amsterdam
http://www.opensips.org/events/Summit-2017Amsterdam.html
<http://www.opensips.org/events/Summit-2017Amsterdam.html>
On 04/26/2017 06:25 PM, Jim DeVito wrote:
Hi Bogdan,
Sorry forgot the mention I am using 2.2.3 the latest stable from
the repo. I put a log line just after send_reply("600","Busy
Everywhere"); and $rU looks good there. Is there another place I
should put a log line to see the value of $rU?
Thanks!!
On Wed, Apr 26, 2017 at 11:16 AM, Bogdan-Andrei Iancu
<[email protected] <mailto:[email protected]>> wrote:
Hi Jim, What OpenSIPS version do you use ? Is the x00 string
corresponding to the to_tn extra field ? If yes, is there any
chance to have the $rU null (no username in RURI) ? Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
<http://www.opensips-solutions.com>
OpenSIPS Summit May 2017 Amsterdam
http://www.opensips.org/events/Summit-2017Amsterdam.html
<http://www.opensips.org/events/Summit-2017Amsterdam.html>
On 04/26/2017 05:43 PM, Jim DeVito wrote:
Hi All,
So I am seeing the below record in the ACC output that is
causing me problems else where. Notice the
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 part.
INVITE|gK0c48d4aa||1464632400_16750753@REDACTED|600|Busy
Everywhere|1493217263|\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00|+1REDACTED|sip-proxy03|from-PSTN|REDACTED||8877||
In every other ACC entry the value is to be the user part of
the request URI as described here...
modparam("acc", "db_extra", "to_tn=$rU; (etc....)
Except when the call goes through the below failure route.
failure_route[orig_load_balance_fail] {
if (t_was_cancelled()) {
exit();
}
if (t_check_status("[56][0-9][0-9]") ||
t_local_replied("all")) {
if (lb_next()) {
t_on_failure("orig_load_balance_fail");
t_relay();
exit();
} else {
send_reply("600","Busy Everywhere");
exit();
}
}
}
Thoughts?
Thanks!!
Jim D.
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
--
-------------
Jim DeVito
Mobile 216.507.9497 <tel:%28216%29%20507-9497>
--
-------------
Jim DeVito
Mobile 216.507.9497
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users