[Home]

Summary:ASTERISK-18953: Sometimes bridge action fails
Reporter:Abhishek Naidu (abhishek.naidu@gs.com)Labels:
Date Opened:2011-12-01 10:26:25.000-0600Date Closed:2011-12-20 09:05:48.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:1.8.7.1 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:Redhat linux 5.5.2 64 bit Attachments:( 0) asterisk_cli_sipdebugon.txt
( 1) sip_interaction_log.txt
Description:Hi,

This problem is actually seen on 1.8.3 (We cannot report problem on 1.8.3 anymore?)
We see the problem in production, so cannot reproduce the problem immediatly with 1.8.7.x versions

Here is the description of the problem:
Asterisk source 1.8.4.3 (release version) is downloaded from Asterisk.org and compiled on Red Hat Linux 5.5.2 64 bit
We are using Asterisk for click-to-call scenario (SIP only). Asterisk is connected to Cisco Call Manager over SIP trunk. All calls are SIP calls only and Asterisk sip configuration is such that media is always remotely bridged.
There is no NAT involved.

The client click-to-call application is using Asterisk-Java to invoke requests to Asterisk.
A single instance of AsteriskServer connection is used to place calls.
Some scenarios involve delayed offer from Call Manager, during which Asterisk does not invoke the native bridging functionality. (In this scenario Cisco updates the SDP of the destination phone over SIP reinvite). The result is that media is locally bridged on Asterisk (which is not our requirement)

To overcome this, we additionally rely on force bridging on every click-to-call request to ensure that calls are always remotely bridged. However this does not always work. The forced bridging is invoked by
1. creating another connection to Asterisk server using ManagerConnection
2. sending the BridgeAction
3. Logging off the connection
The above steps are done for every click-to-call request

Sample:
managerConnection.login();
BridgeAction bridge = new BridgeAction();
bridge.setChannel1(channel1);
bridge.setChannel2(channel2);
bridge.setTone(false);
managerConnection.sendAction(bridge);

Can you please comment on the work around used to ensure that calls are always remotely bridged?
The effects seen are
1. Calls could get dropped after Bridge Action attempt
2. Failed to break bridge error reported by Asterisk

Please let me know what additional information will help to clarify the scenario
thanks again for you support!


Comments:By: David Woolley (davidw) 2011-12-01 11:29:29.244-0600

Delayed offer was somewhat broken, and I believe still is, so the exact details of the SIP session (which you should have provided) are necessary to see if that would make a difference.  (Delayed offer was/is treated as a reset to default settings, rather than just an indication that they should be offered, but the internal state only changed when ACK comes in.)

The Bridge action, or application, is sufficiently far above the SIP protocol handling that I don't think there is any guarantee that it will generate a missing re-INVITE.  That action will involve a simultaneous masquerade of both channels, ending up with them both having their original names, which is a high risk operation.


By: Abhishek Naidu (abhishek.naidu@gs.com) 2011-12-02 03:23:46.604-0600

The following SIP trace files are attached:
sip_interaction_log.txt: This only contains the SIP interaction with CallManager
asterisk_cli_sipdebugon.txt: This contains Asterisk CLI messages with SIP debug set to ON


Asterisk: 138.8.237.64
Call Manager: 172.25.18.188
From Extension: 18366 (physical SCCP extension on Call Manager)
To Extension:89991000 (SIPp endpoint which is connected to call manager over SIP trunk)
Issue timestamp: 02:32:22.266316
Here Asterisk sends BYE when BridgeAction was attempted. The Bridge action is attempted 5 seconds after both the call legs are established.


By: Abhishek Naidu (abhishek.naidu@gs.com) 2011-12-02 03:27:14.741-0600

If BridgeAction is not recommended can you please suggest any other workaround that could help ensure that the calls are always remotly bridged?

Thanks again for your time!

By: David Woolley (davidw) 2011-12-02 05:59:46.441-0600

This issues is marked feedback.  You shouldn't ask follow-on questions until you have taken it out of feedback.  (I had to cheat to produce this response.  Note to JIRA: maintainers, there should be a canned response for this case, as this mechanism doesn't seem well understood.)

The traces you have included show the Cisco using early offer, not delayed offer.

Questions about workarounds should be asked on support forums.

I do remember seeing reports about RTP optimisation not working Asterisk to Asterisk, when there are multiple systems in a chain.  You may find that this bug is fixed in the current release.

On the other hand, without the configuration, it could well be that your configuration or dialplan is incompatible with directmedia.

It does sound like there are bugs in Bridge() as well, but you are asking it to do something quite difficult, so I am not particularly surprised. You should not rely on any early fix, but should update to a current version in case it is already fixed.



By: Leif Madsen (lmadsen) 2011-12-20 09:05:39.451-0600

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines