I am using the bye_on_timeout_flag within the Dialog module to limit the
maximum duration for a call.
When it is triggered I am having problems cleaning up - i.e. accounting the end
of call correctly and
ending the mediaproxy session. I am not using engage_media_proxy() function,
instead preferring to
have more control with use_media_proxy() and end_media_session().
>From a search of the archived questions on this forum I found the trick is to
>create a local_route
section and use a check based on is_method("BYE") to determine when to execute
acc_aaa_request().
This works ok, but it is triggered twice at the end of the call - once for the
BYE sent upstream and
again for the BYE sent downstream. The only solution I could find (I've spent
many hours testing ideas
for this) is the use of a global flag that is toggled each time the local_route
block gets a BYE
method. Then the code only calls acc_aaa_request() when the global flag is set
- i.e. only one in
every two times.
if (is_gflag("1")) {
acc_aaa_request("Internal BYE");
}
# Use Global flag 1 to avoid double reporting/accounting of timeout BYE's
if (is_gflag("1")) {
reset_gflag("1");
} else {
set_gflag("1");
}
This is not a very elegant or satisfactory solution but it should just about
work and hopefully not
many timeouts will occur anyway. Any suggestions for a better solution would be
welcome. I have tried
Dialog values and transaction flags - they don't work.
The other problem is how to end the media proxy session. The transaction flags
set for the Invite are
not visible in the local_route block when it is handling the internally
generated BYE's so I cannot
try the normal checks that would be used in the main route block for BYE.
Perhaps I should just call
end_media_session(), but will it even work from local_route? If I change my
script to start using
engage_media_proxy() will I lose the flexibility of being able to check which
calls need media proxy
and which don't? I don't want them all using it - only those with far-end NAT.
John Quick
Smartvox Limited
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
