|Summary:||ASTERISK-11418: The L(XXX) option does not work when the call is bridged.|
|Reporter:||Private Name (falves11)||Labels:|
|Date Opened:||2008-02-11 16:10:39.000-0600||Date Closed:||2011-06-07 14:02:51|
|Description:||The original bug id is 0010647. I cannot reopen it since I am not the reporter, The Bug marshall claims that the issue was fixed on revision 103314. I tested it today and still found some calls over 100 minutes when all my calls are supposed to last only 60 mins max. I am using in my sip.conf directrtpsetup=yes|
and canreinvite=nonat. The L() option should work.
|Comments:||By: Joshua C. Colp (jcolp) 2008-02-11 16:13:32.000-0600|
The discussion was about using the L option when native bridging, about how it shouldn't prevent it from happening. It was not to fix this issue you seem to be referring to.
By: Joshua C. Colp (jcolp) 2008-02-11 16:16:05.000-0600
As for the issue in question... directrtpsetup is extremely experimental and could be the cause of the issue itself.
By: Private Name (falves11) 2008-02-11 16:20:37.000-0600
I think that directrtpsetup is the reason I am in business, because I could not possibly proxy the media for hundreds of calls. directrtpsetup is my bread and butter, but the L() option does not work. Can we do something about it? right now I run a script every hour that closes calls that are alive and longer than the limit, but it is really a workaround for a bug.
By: Jeff Peeler (jpeeler) 2008-05-15 11:42:10
Is this problem still occurring for you?
By: Private Name (falves11) 2008-05-15 11:59:02
The problem vanished. But I am still affected by bug 12566. Please look into that one. I basically cannot sell to anybody who is behind a NAT.
By: Jeff Peeler (jpeeler) 2008-05-15 14:14:17
Suspending this issue since problem can no longer be reproduced with current version. If this is still a problem in the future, please reopen.