|Summary:||ASTERISK-20183: Intermittent audio|
|Reporter:||Jonn Taylor (jonnt)||Labels:|
|Date Opened:||2012-07-30 12:08:31||Date Closed:||2013-08-12 03:22:27|
|Environment:||CentOS 5 i386 HP DL380 G3||Attachments:||( 0) eth0.pcap|
( 1) Nortel.txt
( 2) one-way2.pcap
( 3) one-way6.pcap
( 4) one-way7.pcap
( 5) oneway-audio6.txt
( 6) oneway-audio-sip-ustm_debug.txt
|Description:||Intermittent audio on incoming and out going calls.|
|Comments:||By: Jonn Taylor (jonnt) 2012-07-30 12:13:09.788-0500|
The attached files are for a SIP to USTM incoming call that the caller could not hear audio from the USTM phone.
By: Matt Jordan (mjordan) 2012-07-30 13:12:10.165-0500
Do you have this problem with SIP to SIP calls?
By: Jonn Taylor (jonnt) 2012-07-30 14:08:09.435-0500
Yes, but it happens way less.
By: Jonn Taylor (jonnt) 2012-07-30 15:15:30.801-0500
One more thing. This started after the new ICE protocol was added to chan_sip. This started after revision 362497.
By: Matt Jordan (mjordan) 2012-07-30 15:48:57.346-0500
I'd like to rule out chan_unistim as a culprit here. It received a *lot* of updates as well in Asterisk 11, and it could muddy this issue quite a lot.
Can you produce a pcap and a DEBUG log of a SIP to SIP call that illustrates the problem?
By: Jonn Taylor (jonnt) 2012-07-30 16:15:36.247-0500
I know chan_unistim did as I helped with some of them. We never had audio problems. I will try and get the SIP to SIP PCAP and debug. This was harder to reproduce.
By: Jonn Taylor (jonnt) 2012-08-01 11:11:10.350-0500
I converted some of my 1120e UNISTIM phones to SIP and it looks like the problem is between chan_sip and chan_unistim. Something changed in the chan_sip driver that is not compatible with chan_unistim. We will need to get the chan_unistim developer involved to get this fixed. I will get pcap captures between asterisk and chan_unistim driver.
By: Igor Olhovskiy (samael28) 2012-08-02 06:33:04.408-0500
.pcap with no audio at all
.txt with Core verbose 3 and Unistim Debug on
By: Matt Jordan (mjordan) 2012-08-02 07:27:24.697-0500
Looking at Igor's eth0.pcap:
1. The SIP peers were configured to have ICE support enabled. This can be disabled on a peer by peer basis. That being said, since the UAC negotiated the SIP session successfully in the presence of ICE candidates, I don't think this is causing any problems.
2. The SIP dialog negotiated media for 10.10.11.201:13122, and on 10.10.11.203:12668. I don't know UNISTIM very well, but it appears as if it was sending its media between 10.10.11:203:11582 and 10.10.11.34:10001.
3. For every RTP packet that was sent along the stream negotiated by the UNISTIM channel from 10.10.11.34 to 10.10.11.203, there is a corresponding ICMP packet denoting that the destination port is unreachable. This would be port 11582. Since this is at the network layer and independent of Asterisk, I would guess its either a network configuration error, or an error configuring chan_unistim.
4. I don't see any corresponding ICMP destination unreachable packets for the RTP stream between 10.10.11.201 and 10.10.11.203 (the stream negotiated by SIP).
It appears as if there is something blocking a port in the RTP stream negotiated by chan_unistim, or the port that was negotiated was incorrect.
By: Jonn Taylor (jonnt) 2012-08-02 08:38:38.845-0500
I remember having problems around the time that these changes happened. https://reviewboard.asterisk.org/r/1822/
By: Igor Olhovskiy (samael28) 2012-08-02 10:00:47.245-0500
For p.3 of Matt's post: It all on same network (no firewalls at all between servers and iptables configured to accept all) and error not repeated always. Only after Nortel phones stays with no calls nearly 10-15 min. After first failed call, if redial, all seems ok.
By: Matt Jordan (mjordan) 2012-08-03 08:57:18.106-0500
I still don't see anything here that indicates that Asterisk is not receiving audio or communicating incorrect port information to either the UNISTIM or SIP devices. That isn't to say it isn't happening, but there's no evidence of it that I can see in the pcaps or logs.
If you can try to get a pcap and DEBUG log for two SIP devices where this problem occurs, that might point to where the problem is.
By: Jonn Taylor (jonnt) 2012-08-04 09:45:35.936-0500
No audio IAX to USTM. Put call on hold for 10 sec. then got audio. This is only from the side that face the internet. Not the internal network.
By: Jonn Taylor (jonnt) 2012-08-06 16:51:55.455-0500
Oneway audio between asterisk and unistim phone. Put call on hold for 10 seconds and then picked backup and them had 2way audio.
By: Jonn Taylor (jonnt) 2012-08-06 16:52:55.375-0500
Debug output for oneway2.pcap
By: Jonn Taylor (jonnt) 2012-08-10 09:01:16.173-0500
Look at frame 2133 on file one-way2.pcap. Decode all UDP frames from port 5000 as UNISTIM.
Open Stream Report: Operation failed: Stream already in use (0x03)
By: Jonn Taylor (jonnt) 2012-08-10 09:12:57.352-0500
Same thing with eth0.pcap decoding frame 711. Open Stream Report: Operation failed: Stream already in use (0x03)
Frames 640 and 643 show a codec mismatch.
By: Matt Jordan (mjordan) 2012-08-13 08:02:21.723-0500
Since the underlying culprit here appears to be chan_unistim, I've changed the component to reflect that and acknowledged the issue. I've assigned it to Igor for the time being.
If it looks like this is not a chan_unistim issue, i.e., you can reproduce the behavior without chan_unistim being involved in the call, then let me know.
By: Jonn Taylor (jonnt) 2012-08-13 12:02:26.543-0500
Matt.. I think the problem is in the new RTP code in chan_sip. I set strictrtp=no in the rtp.conf and that did not help either. I also disabled ICE, no go. If the media stream is showing that it is all ready in use but it is not, then how is this a chan_unistim issue?
By: Jonn Taylor (jonnt) 2012-10-17 12:13:43.846-0500
Any update on this issue?
By: Igor Goncharovsky (igorg) 2012-10-17 21:42:47.909-0500
Jonn, I am unable reproduce that issue on my test stand and currently working on fixing issues in Ukraninan setup of chan_unistim (here also audio issues exists). After that, if you'll be able give access to problem setup I'll work on your issues.
By: Jonn Taylor (jonnt) 2012-10-23 11:38:57.027-0500
I can not give you access to the system but I can do all the testing you need. If you need packet captures I can do that too.
By: Igor Goncharovsky (igorg) 2012-12-10 01:14:00.148-0600
Jonn, please retest. I have fixed codecs mismatch in unistim messages. Can you also describe what firmware used in you phones and what rtp_type value used in unistim.conf?
By: Jonn Taylor (jonnt) 2012-12-10 13:01:19.010-0600
By: Jonn Taylor (jonnt) 2012-12-11 09:19:49.253-0600
Looks like that fixed it.
By: Jonn Taylor (jonnt) 2012-12-13 15:31:37.784-0600
Great improvement, but I just had a call with one-way audio.
By: Igor Goncharovsky (igorg) 2012-12-13 20:42:59.460-0600
Can you check by tcpdump, if there is RTP continue coming from Unistim phone after call ended. I have reported one-way audio from several peoples.
By: Jonn Taylor (jonnt) 2012-12-14 09:23:40.304-0600
Yes, I am seeing a constant stream of UDP data from the phone.
By: Igor Goncharovsky (igorg) 2013-06-11 05:26:47.822-0500
John, this issue fixed for now. Please test and check if you still able to see constant UDP from phone after all calls disconnected. If you able to reproduce issue, please let me know operations sequence to reproduce issue.
By: Igor Goncharovsky (igorg) 2013-06-11 05:27:08.847-0500
Note: fixed in brahch/11 and trunk