Hello, Everybody.Our company run MTE and we just face with next issue: sometimes after call transfer to another extension remote party lost audio channel (one way audio). It is looks like: someone call from 444777888 on thirdlane. Call came on extension 101. A secretary pickup the call and transfer it to another extension 102 (attendant transfer, not blind), during the transfer remote party listen music on hold. Extensions 101 and 102 speaking normally. After 101 hang up, call transfered to 102. 102 say "Hello" but no one answer, although RTP channel is active in both directions. It is happened occasional, not every time, but quite often. We dumped traffic, investigated it and found that timestamp in the RTP flow sometimes has crazy values. It is very similar to the issue, which I have found on
issues.asterisk.org
The only point that it was asterisk version 1.4 but we run 1.6.2.11. Seems that the problem was not fixed and what I suppose is that remote phone confuses by this crazy values of timestamps and break the call.
Thirdlane was installed from the ISO image. We use Dell PowerEdge R710 and kernel version is 2.6.18. Does anybody faced with such problem and could suggest why it may happens?
its probably the firewall
its probably the firewall where the phones are located. Firewalls can often work for regular calls but break doing transfers, or can drop the call after X number of minutes.
It is exactly the same thing
It is exactly the same thing I usually say to all my customers who complains on this issue. The thing is that we have customers with SCCP phones who never complain on this. And we have good cisco router as firewall, so it doesn't a reason. What I have found that sometimes cisco 7960 (SCCP) stop to play audio because of these crazy timestamps and it is a firmware bug. There are 2 ways to fix it - update phones firmware (which is impossible to do for all phones) or apply the path to asterisk which will fix this issue with timestams. I am pretty sure, that not only ciscophones may broke audio, but some voice gateways as well. The link I mentioned above https://issues.asterisk.org/view.php?id=11491 has the patch for 1.4 version, but not for 1.8. If you know the way how to fix it - let me know, pls. We are ready to pay for this solution.
why are you using SCCP? we
why are you using SCCP? we dont support SCCP.. hell Asterisk doesnt support it, its marked experimental since 2005.
We use SCCP not with
We use SCCP not with asterisk. We have sccp gateway which is connected to asterisk via SIP. I tests with next schema: call from sccp 7960 on asterisk's extension, transfer the call to another asterisk's extension and was able to reproduce a situation when cisco 7960 shows me crazy jitter values after this transfer.
Here you may see it:
http://i54.tinypic.com/2a9nsjc.jpg
Time from time the phone 7960 lost incoming audio. According Cisco audio may be restored if you put call on hold on cisco phone, but usually it is hard to explain to other side, especially when he doesn't hear you.
We may say that it is phone's bug, but from other side it is not a very true behavior from asterisk's side to did such trick with the timestamp which is used for jitter calculation.
My advice is to take the
My advice is to take the route of updating the firmware on the phones. It might be a PITA, but there are some bigger issues at stake here even beyond this bug. I wasn't aware that the 79x0 models were still getting new firmware released. Cisco is such assholes about granting access to firmware. Right now there are some serious vulnerabilities in several devices that are allowing organizations, like Hamas, to embark on a massive scale scam placing unauthorized international calls to TN's that charge anywhere from $0.60/min to $11.23/min (yes eleven dollars). They are finding ways of tricking devices into giving out their credentials or their full configuration files. I have had a recent rash of new consulting business as a result of people suffering tens of thousands of dollars in damages in a very short time. They are desperate to educate themselves on better 'best practices' to avoid this in the future. Keeping up with firmware is the first of many steps required to fight this financial war.
Man, I have updated 7960 to
Man, I have updated 7960 to latest firmware 8.1(2)SR1 which was released 06/APR/2011 - 2 weeks ago (http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtn69362). And I still was able to reproduce this problem with one way audio, although they insist that the problem was fixed. I see only one way and it is fixing this issue with asterisk RTP. Could you recommend someone with experience in asterisk core development or maybe your company able to fix this issue?
Do you think the problem
Do you think the problem might actually be occurring in your SSCP to SIP gateway? Have you tried flashing some phones with the sip software load instead to see if you can reproduce the problem?
it sounds to me like this issue number https://issues.asterisk.org/view.php?id=17007 already adressed the issue. Have you tried all versions of 1.8 to see if it was fixed and then resurfaced?
No one complain on SIP phones
No one complain on SIP phones with this issue and I suppose that SIP phones ignore timestamp or just doesn't have such bug. I think that it is not a SIP-SCCP gateway problem, because of I have captured the traffic just in front of SCCP phone and audio actually is ok - it's a phone issue. And gateway doesn't touch RTP flow.
Will test different versions of asterisk 1.8. I have tested only 1.8.3.2. Don't want to move to version 1.4, especially because of the feature with CallerID update during the transfer which is very convenient. Thanks for the idea and the link.
I have found that this problem not disappeared in asterisk version 1.8.