| Summary: | ASTERISK-06320: SIP to SIP calls randomly result in one-way calls | ||
| Reporter: | Christian Müller (christianmueller) | Labels: | |
| Date Opened: | 2006-02-15 06:40:48.000-0600 | Date Closed: | 2011-06-07 14:10:28 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) oneway2-asterisklog.txt ( 1) oneway2-syslog.txt ( 2) oneway3-asterisklog.txt ( 3) oneway3-asterisklog.zip | |
| Description: | Sometimes we get calls that are one-way, meaning person A can hear and talk to person B, person B cannot hear A, but can talk to A. So far this has happened randomly for incoming, outgoing and internal calls. However there is a pattern: The originator of a one-way call can hear and talk to the callee, the callee himself can be heard by the caller, but cannot hear the caller. I've already posted about this in the bugtracking system for mISDN, but since mISDN isn't involved with SIP to SIP calls at all I thought I should post this here as well as it might be an Asterisk issue. Attached you find excerpts from the Asterisk full log and syslog for a confirmed one-way call. In this case SIP/161 called SIP/116. 116 accepted the call, but was unable to hear anything 161 said. I'm at the end of my rope here because I can't see any difference from the logs between a normal call and a one-way call. ****** ADDITIONAL INFORMATION ****** Asterisk version: 1.2.4 Zaptel Version 1.2.3 Libpri Version 1.2.2 Addons Version 1.2.1 Sounds Version 1.2.1 all taken from www.asterisk.org Base system: Asterisk@home 2.1 running Centos 4.1, Asterisk and mISDN manually upgraded. Setup: One Asterisk box with 8xBRI ISDN card connected to 4 PTP ISDN lines. On the network side a 100MBit/s 24 port switch with 10 Snom 360 and 10 Sipura 2002. The Sipuras are on firmware version 3.1.5 and the Snoms on 5.3 The VoIP switch as one uplink to our router for internet connectivity. Asterisk server is 192.168.4.2, Snom phones are 192.168.4.160 to 192.168.4.169, Sipura boxes start with 192.168.4.105 skipping even numbers up to 192.168.4.125. /etc/asterisk/sip.conf: ; Note: If your SIP devices are behind a NAT and your Asterisk ; server isn't, try adding "nat=1" to each peer definition to ; solve translation problems. [general] port = 5060 ; Port to bind to (SIP is 5060) bindaddr = 0.0.0.0 ; Address to bind to (all addresses on machine) disallow=all ;allow=ulaw allow=alaw ;allow=alaw,g729,g723,g726,gsm,speex,adpcm,ulaw context = from-sip-external ; Send unknown SIP callers to this context callerid = Unknown language=de subscribecontext=ext-local fromdomain=192.168.4.2 vmexten=*97 call-limit=999 qualify=500 notifyringing=yes dtmfmode=info #include sip_nat.conf #include sip_custom.conf #include sip_additional.conf | ||
| Comments: | By: Matt O'Gorman (mogorman) 2006-02-15 10:21:53.000-0600 http://www.digium.com/index.php?menu=bugguidelines please folllow bug guidelines with out a sip debug of this call going through it would be nearly impossible to tell if this is a real error or a misconfiguration By: Christian Müller (christianmueller) 2006-02-17 03:58:51.000-0600 Disregard above call description please. Here is one with SIP debug output. SIP/164 called SIP/119. SIP/164 was able to hear SIP/119, SIP/119 wasn't able to hear SIP/164. File: oneway3-asterisklog.zip By: Christian Müller (christianmueller) 2006-02-22 07:46:11.000-0600 Am I still missing something? By: Olle Johansson (oej) 2006-03-29 16:31:47.000-0600 Feb 17 09:05:33 VERBOSE[7076] logger.c: -- SIP/119-6897 answered Local/164@from-internal-e1cb,2 Feb 17 09:05:33 DEBUG[7025] channel.c: Got a FRAME_CONTROL (-1) frame on channel Local/164@from-internal-e1cb,1 Feb 17 09:05:33 DEBUG[7025] channel.c: Bridge stops bridging channels mISDN/8-1 and Local/164@from-internal-e1cb,1 There's a problem with misdn and chan_local that hangs up the call. Otherwise, i can't find anything in the log file, but it includes so much irrelevant stuff so it's hard to know which call to follow, really. By: Christian Müller (christianmueller) 2006-04-06 01:34:06 Thank you for the information. In the meantime I managed to work around this issue by not using chan_local and have posted this issue to the chan_misdn bugtracker. By: Olle Johansson (oej) 2006-04-06 01:58:33 Ok, let's see what happens there. Suspending this bug report meanwhile. | ||