[Home]

Summary:ASTERISK-04004: [patch] transcode via sln breaks chan_local
Reporter:jerjer (jerjer)Labels:
Date Opened:2005-04-27 15:19:37Date Closed:2006-09-26 14:18:49
Priority:TrivialRegression?No
Status:Closed/CompleteComponents:Channels/chan_local
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bug4101_09-25-05_sip_debug.txt
( 1) make-compatible-after-forward2.patch
Description:-- Accepting call from 'XXXXX' to '3008' on channel 0/1, span 1
   -- Executing Wait("Zap/1-1", ".5") in new stack
   -- Executing Goto("Zap/1-1", "walton|290|1") in new stack
   -- Goto (walton,290,1)
   -- Executing Dial("Zap/1-1", "SIP/2901|25") in new stack
   -- Called 2901
   -- Got SIP response 302 "Moved Temporarily" back from 1.1.2.2
   -- Now forwarding Zap/1-1 to 'Local/XXXX@scoffice' (thanks to SIP/2901-59ee)
   -- Executing SetCallerID("Local/XXXXX@scoffice-605d,2", "111111") in new stack
   -- Executing Dial("Local/XXXXXX@scoffice-605d,2", "Zap/g1/12345") in new stack
   -- Requested transfer capability: 0x00 - SPEECH
   -- Called g1/XXXXX
Apr 27 11:00:24 NOTICE[26327]: channel.c:1434 ast_read: Dropping incompatible voice frame on Local/XXXXX@scoffice-605d,2 of format ulaw since our native format has changed to slin

****** ADDITIONAL INFORMATION ******

Setting transcode_via_sln=no in asterisk.conf and restarting asterisk works around this issue. Already discussed with kpflemming.  
Comments:By: Serge Vecher (serge-v) 2005-04-27 16:15:47

Hmm, I was struggling with the same beast for months as detailed in bug 2519. I've stopped observing this problem in your (zap->local->sip) scenario in mid-March HEAD. The 04/22/04 HEAD I run currently also fixed the problem in sip->local->zap scenario. Kevin mentioned in closing notes for 2519 that fix is related to duplicate bug (3947), but I doubt that is the case since 3947 has no patches and is still open. Anyway, I hope this information helps. Whatever broke this, must have been applied the past 5 days, unless something else is at play here. BTW, transcode_via_sln is not set in asterisk.conf in my case

serge

By: Kevin P. Fleming (kpfleming) 2005-04-28 11:53:28

transcode_via_sln is the default in CVS HEAD, it only needs to be set in asterisk.conf if you want to disable it.

By: Kevin P. Fleming (kpfleming) 2005-04-28 11:54:45

JerJer: So this call ended up being Zap<->Zap, with ulaw in use on both ends?

By: Mark Spencer (markster) 2005-04-28 13:48:32

I think this is a long standing bug in chan_local and probably has nothing to do with the transcode_via_sln option....

By: Michael Jerris (mikej) 2005-05-23 23:22:35

JerJer, ASTERISK-2478 does seem to be the same or a closely related issue, although confirmed fixed a few days proior to this report.  Can you double check that you can reproduce this with current head?  Also, are there any other paramaters that determine when this error does occour other than if transcode_via_sln is on?



By: Clod Patry (junky) 2005-06-20 18:49:45

Any development here?

/Housekeeping

By: Serge Vecher (serge-v) 2005-06-21 09:30:48

Just to throw some recap and info into the mix: this problem was fixed in 2519 as of HEAD 04/21. JerJer reported the problem again on 04/27. As of current CVS the problem is still there.

By: sivana (sivana) 2005-07-14 12:29:34

7-14-2005 - CVS-HEAD
It is still ocurring when the end user put their phone on forward.

Here is the complete sip debug:
  http://pastebin.ca/17706

I'm calling in on ZAP to a SIP (Polycom 500).  The phone is forwarded to another SIP device.

By: Olle Johansson (oej) 2005-07-27 12:17:01

Any updates? Still a problem? Anyone that wants to start coding, fixing this if it's still an open issue?

/Housekeeping

By: jerjer (jerjer) 2005-07-30 19:07:09

I cannot make this situation happen any more.

By: Michael Jerris (mikej) 2005-07-30 20:49:27

Given that the OP can not duplicate the problem with current head, I am going to close this out.  If anyone is still has this problem, please re-open this bug with full debug logs of the call experiencing the problem.  Thanks.

By: jerjer (jerjer) 2005-09-30 15:50:03

Serge A. Vecher requested this issue be re-opened.

By: Serge Vecher (serge-v) 2005-09-30 15:58:54

Thanks, JerJer.

I've upgraded to HEAD 09/29/05. The problem persists both in SIP->local->zap and SIP->local->SIP scenarios. Attached find the log with sip debug on.

By: sivana (sivana) 2005-09-30 18:44:29

Yes, I can concur that it is in fact not fixed.  I noticed it today with SIP->local->zap and IP phones forwarded to another.

By: Olle Johansson (oej) 2005-10-20 02:21:23

Who looks at this problem?

/O

By: Serge Vecher (serge-v) 2005-10-20 08:35:06

oej, I don't know if anybody is looking at fixing this problem, but it still exists. I will try a fresh CVS checkout to see if Mark's patch to chan_local yesterday affects this problem and report back.

P.S. Can a marshall please establish a relationship to 2519? Thanks.

By: Serge Vecher (serge-v) 2005-10-24 18:18:50

HEAD 10/24/2005 -- The problems is still there

By: Kevin P. Fleming (kpfleming) 2005-10-31 17:45:41.000-0600

What is the actual breakage here?

I set up a test where I called via a Zap channel into Local() and out to a SIP phone. Yes, I saw this message occur on my console, but the call set up correctly and there was two-way audio.

By: Serge Vecher (serge-v) 2005-10-31 23:08:26.000-0600

kpflemming:

Besides the annoyance of spammed console, the ringing tone is garbled when doing sip->local->zap (more problematic with cellphone rather than landline).

By: Kevin P. Fleming (kpfleming) 2005-11-08 21:22:24.000-0600

I still cannot reproduce any problem here; I've tried SIP->local->Zap and Zap->local->SIP and I don't see anything unexpected, nor is there any audio problem.

Can someone provide an _exact_ configuration that reproduces this problem reliably?

By: Serge Vecher (serge-v) 2005-11-09 09:24:37.000-0600

Kevin, here is the setup we use that reproduces this reliably:
1) CVS HEAD, wct100p (E&M Wink) to PSTN
2) Cisco 7940 SIP 7.4(A), CFwdAll to a cellphone number.
3) Call phone A from another Cisco phone --> get Notices on console (always), as well as the garbled ringing tone on phone B (sometimes).

Note, the garbled ringing tone is an intermittent problem (can't tie it to one specific event or sequence thereof). However, the Notices are very annoying and fill up the console very quickly. Perhaps, at the least, this problem can be fixed by hiding them at a deeper debug level: they are not useful for Asterisk's admin doing day-to-day stuff.

By: Olle Johansson (oej) 2006-01-04 03:06:39.000-0600

Time to restart this issue - where are we? Is Kevin still not convinced? How do you prove it to him?

/Housekeeping

By: Serge Vecher (serge-v) 2006-01-04 14:14:31.000-0600

Well, I'm running r7498 (12/17/2005) now and the problem is still there. As described in note 0036094, the only "real problem" is garbled ringing tone produced when a sip device call-forwards to a pstn #. Intermittently, the garlbing is extreme and results in hi-pitched (cover-your-ears) whistling.

By: Tilghman Lesher (tilghman) 2006-03-01 16:01:10.000-0600

We recently changed some code in trunk related to codec translation to SLN.  Is this still an issue?

By: jerjer (jerjer) 2006-03-01 23:46:02.000-0600

Not sure exactly if there is a problem here or not - When I call forward from my ata/ip phone I get the following output, but audio still does get passed.

I have seen a few times where the 'dropping incompatible' messages flood until call is tore down.



   -- Got SIP response 302 "Moved Temporarily" back from 66.225.202.76
   -- Now forwarding Zap/4-1 to 'Local/12487249999@NANPA' (thanks to SIP/proxy-1.nufone.net-bdec)
   -- Executing Goto("Local/12487249999@NANPA-88ec,2", "E164|12487249999|1") in new stack
   -- Goto (E164,12487249999,1)
   -- Executing Dial("Local/12487249999@NANPA-88ec,2", "Zap/G1/2487249999") in new stack
   -- Requested transfer capability: 0x00 - SPEECH
   -- Called G1/2487249999
Mar  2 00:43:37 NOTICE[596]: channel.c:1941 __ast_read: Dropping incompatible voice frame on Local/12487249999@NANPA-88ec,2 of format ulaw since our native format has changed to slin
   -- Zap/23-1 is proceeding passing it to Local/12487249999@NANPA-88ec,2
   -- Local/12487249999@NANPA-88ec,1 is proceeding passing it to Zap/4-1
Mar  2 00:43:37 NOTICE[596]: channel.c:1941 __ast_read: Dropping incompatible voice frame on Local/12487249999@NANPA-88ec,2 of format ulaw since our native format has changed to slin

By: Serge Vecher (serge-v) 2006-03-02 10:28:59.000-0600

I will try to upgrade our server to the latest trunk version within a week to see whether the ringing tone is still garbled. Given JerJer's report of the same console notices, I bet the problem is still there.

By: jharragi (jharragi) 2006-03-03 15:47:54.000-0600

I svn updated 3/2/6 and am getting the slin message loop. It seems (but I'm not sure) that this is occurring with certain incoming calls - arriving on a national pri. Can a remote system be requesting this codec via pri?

John

By: Serge Vecher (serge-v) 2006-03-03 15:54:31.000-0600

john: is chan_local involved in routing of incoming calls when you see those messages? Because that's what the problem is in our and apparently JerJer's case

By: jharragi (jharragi) 2006-03-04 00:05:18.000-0600

No, chan_local is not used in the dial plan that these calls can access. The calls  that have the problem are mostly from a couple of extensions (of over 100 cisco 7960s - which I have been taking a dislike to as its my impression that cisco is intentionally withholding functionality from the sip image, which costs plenty. These are all on the 7.5 image). It could be something peculiar about those phones  but I think it is who they are calling. Also I said looping, but should have said it looks like the remote end transmits slin with each new packet. But this is just ideas at this point - I expect to collect better info on monday as I am also getting an occational crash which seems to occur after an slin incident. If so, I may have a dump.

By: jharragi (jharragi) 2006-03-06 12:05:36.000-0600

OK, seems most of my impressions were wrong. The slin occurances are similar to yours. macro Local must be called internally on calls that are forwarded by a sip phone (that arrive on a zap channel). Also the slin message appears during ringing - rather than during actual speech.

And some cli where the forward occurs. This call is originated on a cisco 7960 ext 6265 and dialing out and back in on our pri. DID 4604776 gets routed to 6277 which is forwarded to 6254.

   -- Executing Dial("SIP/6265-368d", "Zap/g1/4606276") in new stack
   -- Requested transfer capability: 0x00 - SPEECH
   -- Called g1/4606276
   -- Zap/6-1 is proceeding passing it to SIP/6265-368d
   -- Executing Goto("Zap/8-1", "ec_sip_phones|6277|1") in new stack
   -- Goto (ec_sip_phones,6277,1)
   -- Executing Macro("Zap/8-1", "sip_phone|6277") in new stack
   -- Executing Dial("Zap/8-1", "SIP/6277|20") in new stack
   -- Called 6277
   -- Accepting call from '8454606200' to '8454606276' on channel 0/8, span 1
   -- Got SIP response 302 "Moved Temporarily" back from 10.0.34.253
   -- Now forwarding Zap/8-1 to 'Local/6254@from-sip' (thanks to SIP/6277-0f2a)
   -- Executing Macro("Local/6254@from-sip-19b7,2", "sip_phone|6254") in new stack
   -- Executing Dial("Local/6254@from-sip-19b7,2", "SIP/6254|20") in new stack
   -- Called 6254
Mar  6 10:51:03 NOTICE[19449]: channel.c:1941 __ast_read: Dropping incompatible voice frame on Local/6254@from-sip-19b7,2 of format ulaw since our native format has changed to slin
...
till picked up or timed out.

By: Shaun (sdaigle) 2006-03-20 12:43:59.000-0600

We're running the latest version of Asterisk and seeing this bahaviour as well.  It only occurs when we utilize the "Call Forward" functionality from our IP phones.

I've sen this happen in these two scenarios:

1) SIP1 --> SIP2 (SIP2 Cfwd to SIP3)
2) SIP1 --> SIP2 (SIP2 Cfwd to ZAP/Pri)

Here's a sample from the CLI:
Mar 20 14:03:44 NOTICE[4835]: channel.c:1906 ast_read: Dropping incompatible voice frame on Local/9XXXXXXXXXXX@ld_allowed-97cb,2 of format slin since our native format has changed to ulaw

Shaun

By: nenadr (nenadr) 2006-03-20 13:08:20.000-0600

I can confirm behavior from previous 2 notes on 1.2.4 also

By: Sebastian Torf (storf) 2006-03-27 19:42:34.000-0600

I have the same issue on 1.2.1 with a Cisco 79xx on SIP 7.5 using its "CFwdAll" function.

The call is as follows:
Zap -> local -> Zap

I put Ethereal on this transaction and it looks like Asterisk invites the Cisco phone, but the Cisco phone answers Asterisk with a "Status: 302 Moved Temporarily" msg. Could it be that Asterisk is not truly acknowledging that this portion of the call leg should not be retried (Asterisk -> SIP phone), when the PBX already attempts to forward the call to another destination?

I tried deactivating the CFwdAll feature on the Cisco phone while calling it from my cell, but it would not start ringing in spite of the 2970 notices mentioned above continuing on in the PBX console. The spam'ed 2970 notices stop as soon as the call is answered on the forwarded number.

There's only 3 packets exchanged:
PBX -> SIP ... Request: Invite
SIP -> PBX ... Status: 302
PBX -> SIP ... Request: ACK

Timestamps are: 0, 0.130858, 0.131079 for those 3 packets



By: Dr. W.A. Slaby (was) 2006-04-09 04:30:04

"Setting transcode_via_sln=no in asterisk.conf and restarting asterisk works around this issue. " :

Although I included this setting in asterisk.conf the problem is still remaining. Are there any other workarounds? Many thanks in advance for any help.

By: Michael Neuhauser (mneuhauser) 2006-04-13 14:21:24

Results of some tests I did:
SIP phone A calls SIP phone B. B is forwarded (in the phone) to an external number (ZAP channel). sip.conf has allow=alaw,ulaw for A and allow=g729,alaw,ulaw for B. I get
   Dropping ... on Local/...,2 of format slin ... changed to alaw
messages during the time the external number rings and the ringing tones are garbled. When I set transcode_via_sln=no the messages change to
  Dropping ... on Local/...,2 of format g729 ... changed to slin
and the ringing tones are OK.
Both cases are OK (no messages, ringing tones fine) after I've modified app_dial.c:wait_for_answer() like this:
 if (!ast_strlen_zero(o->chan->call_forward)) {
   ...
   /* Setup parameters */
   o->chan = ast_request(tech, in->nativeformats, stuff, &cause, NULL);
   if (!o->chan)
     ast_log(LOG_NOTICE, "Unable to create local channel for call forward ...
   else
     ast_channel_make_compatible(in, o->chan); /* ADDED */
I'm sure that this is not a complete fix, e.g. I have no idea how it would affect forwarded ZAP phones (can't test, got ISDN). Maybe someone else can use this observations.

By: Serge Vecher (serge-v) 2006-05-02 10:57:54

Since all feedback is received, setting appropriate status to 'acknowledge' the problem.

By: Denis Smirnov (mithraen) 2006-05-02 11:44:02

Is this issue fixed by 4825?

By: Serge Vecher (serge-v) 2006-05-10 12:52:01

Mithraen: I doubt it. The bug is within chan_local.

By: Denis Smirnov (mithraen) 2006-05-11 09:35:49

I know, but 4825 may be workaround.
It transcode on read frames, not write as now.

By: John Lange (johnlange) 2006-05-26 14:20:43

In 1.2.7.1 this bug still exists.

ZAP -> local -> SIP

The SIP phone is a Polycom 600 set to call-forward to another group of SIP phones attached to the same asterisk box.

It generates a flood of NOTICE messages but does not seem to prevent the call from working or cause ill effects at least in our limited testing. Here is a paste of teh actual call flow.

== Spawn extension (exten-stdA, s, 2) exited non-zero on 'Zap/19-1'
   -- Hungup 'Zap/19-1'
   -- Accepting call from '1234567890' to '1231234567' on channel 0/5, span 1
   -- Executing Goto("Zap/5-1", "reception|s|1") in new stack
   -- Goto (reception,s,1)
   -- Executing GotoIf("Zap/5-1", "0?from-pstn-reghours|s|1") in new stack
   -- Executing GotoIf("Zap/5-1", "0?from-pstn-afthours|s|1") in new stack
   -- Executing GotoIfTime("Zap/5-1", "7:55-17:35|mon-fri|*|*?from-pstn-reghours|s|1") in new stack
   -- Goto (from-pstn-reghours,s,1)
   -- Executing NoOp("Zap/5-1", "RegHours") in new stack
   -- Executing Macro("Zap/5-1", "reception|200") in new stack
   -- Executing SetVar("Zap/5-1", "CXTEN=200") in new stack
   -- Executing Dial("Zap/5-1", "SIP/200x1|17") in new stack
   -- Called 200x1
   -- Got SIP response 302 "Moved Temporarily" back from 204.16.145.130
   -- Now forwarding Zap/5-1 to 'Local/205@internal' (thanks to SIP/200x1-3add)
   -- Executing Goto("Local/205@internal-1107,2", "support|205|1") in new stack
   -- Goto (support,205,1)
   -- Executing SetVar("Local/205@internal-1107,2", "_ALERT_INFO=Bellcore-r3") in new stack
   -- Executing Dial("Local/205@internal-1107,2", "SIP/220x1&SIP/223x1&SIP/225x1&SIP/226x1|17") in new stack
   -- Called 220x1
   -- Called 223x1
   -- Called 225x1
   -- Called 226x1
May 26 13:50:08 NOTICE[13853]: channel.c:1904 ast_read: Dropping incompatible voice frame on Local/205@internal-1107,2 of format ulaw since our native format has changed to slin
May 26 13:50:08 NOTICE[13853]: channel.c:1904 ast_read: Dropping incompatible voice frame on Local/205@internal-1107,2 of format ulaw since our native format has changed to slin
May 26 13:50:08 NOTICE[13853]: channel.c:1904 ast_read: Dropping incompatible voice frame on Local/205@internal-1107,2 of format ulaw since our native format has changed to slin
May 26 13:50:08 NOTICE[13853]: channel.c:1904 ast_read: Dropping incompatible voice frame on Local/205@internal-1107,2 of format ulaw since our native format has changed to slin
May 26 13:50:08 NOTICE[13853]: channel.c:1904 ast_read: Dropping incompatible voice frame on Local/205@internal-1107,2 of format ulaw since our native format has changed to slin
May 26 13:50:08 NOTICE[13853]: channel.c:1904 ast_read: Dropping incompatible voice frame on Local/205@internal-1107,2 of format ulaw since our native format has changed to slin                                                                                            

..... this continues forever until something changes the call flow e.g. someone answers or it goes to voicemail.



By: Serge Vecher (serge-v) 2006-06-06 15:23:25

FWIW, this is still the case in trunk 32281

By: Serge Vecher (serge-v) 2006-06-27 11:15:01

hmm, looks like I'm no longer able to reproduce this in trunk r36176. I was trying to narrow down the revision that fixed it since the last reported problematic r32281 and had difficulty, because chan_sip was broken several times and that's what I test with. Can anybody else confirm that this is fixed in the latest trunk?

By: Serge Vecher (serge-v) 2006-06-27 11:51:15

also, I've tested 1.2.9.1 and could not reproduce this problem in a SIP_A->Cfwd'all->SIP_B scenario. Can't test SIP->cfwd'all->Zap on this system, so it would be helpful if anybody that has 1.2.9.1 running please test this. Thanks.

By: Michael Neuhauser (mneuhauser) 2006-06-27 13:21:55

I've just check 1.2.9.1 for the case described by me above (0044294):
When I disable the call to ast_channel_make_compatible() in app_dial.c that I have added the problem is there (I've made 5 test calls and every time it was there). Re-enabling the call to ast_channel_make_compatible() makes the problem disappear (again 5 test calls). (Note: Problem only manifests itself if G.729 is the preferred codec of phone B not only in sip.conf as I've initially stated, but also in the phone's configuration itself.)

By: Serge Vecher (serge-v) 2006-06-27 13:44:31

mneuhauser: can you please upload your change as a patch file and get a disclaimer on file?

By: Michael Neuhauser (mneuhauser) 2006-06-27 15:12:35

vecher:
patch attached as make-compatible-after-forward.patch

re disclaimer: I do not want to go into this discussion here, but the 2 disclaimers provided are not acceptable to me for various reasons.

My understanding is, that this is OK as long as I only provide small fixes (which I already did 2 or 3 times). This is a 2 line fix - hope that is not over the limit.

By: Michael Neuhauser (mneuhauser) 2006-06-27 15:44:25

vecher: make-compatible-after-forward.patch had a small problem, fixed version is make-compatible-after-forward2.patch

By: Serge Vecher (serge-v) 2006-06-27 16:10:49

mneuhauser: thanks for the patch. I will try to test it tomorrow.

By: Jonathan Galpin (jlgdeveloper) 2006-07-03 14:55:30

Ok, I tested this patch, and the issue still exists. I did a fresh install of Libpri 1.2.3, Zaptel 1.2.6 and Asterisk 1.2.9.1, Linux 2.6 kernel, originally Pound Linux flavor. I am using a Digium TMDXXB Card. I applied the patch, verified the changes were present, re-complied and installed lib,zap & asterisk.

Issue only affects incoming PSTN calls. pstn(ulaw) --> * --> iaxy(iax2) --> (ulaw)analog handset. Outgoing calls the same route are fine as well as sip phones --> * --> iaxy --> handset.

The * server is in one location, port 4569 open, and the iaxy device is behind nat. Not a firewall issue since opening port 4569 to the iaxy or putting the iaxy on the dmz does not change it.

Thanks, Jonathan

Call log follows:

   -- Starting simple switch on 'Zap/1-1'
   -- Executing NoOp("Zap/1-1", "Incoming call --> 813909XXXX") in new stack
   -- Executing Wait("Zap/1-1", "1") in new stack
   -- Executing Set("Zap/1-1", "TIMEOUT(digit)=5") in new stack
   -- Digit timeout set to 5
   -- Executing Set("Zap/1-1", "TIMEOUT(response)=15") in new stack
   -- Response timeout set to 15
   -- Executing BackGround("Zap/1-1", "custom/business-hours-menu") in new stack
   -- Playing 'custom/business-hours-menu' (language 'en')
 == CDR updated on Zap/1-1
   -- Executing Dial("Zap/1-1", "SIP/sip-carmen-desk&SIP/sip-annie-desk&IAX2/annie-home&SIP/sip-jon-desk|30|mt") in new stack
   -- Called sip-carmen-desk
   -- Called sip-annie-desk
   -- Called annie-home
   -- Called sip-jon-desk
   -- Started music on hold, class 'native', on Zap/1-1
   -- SIP/sip-carmen-desk-6b8b is ringing
   -- SIP/sip-jon-desk-f9f6 is ringing
   -- Call accepted by 71.100.16.XXX (format ulaw)
   -- Format for call is ulaw
   -- IAX2/annie-home-6 is ringing
   -- SIP/sip-annie-desk-bb83 is ringing
   -- IAX2/annie-home-6 answered Zap/1-1
   -- Stopped music on hold on Zap/1-1
Jul  3 15:23:49 NOTICE[3058]: channel.c:1904 ast_read: Dropping incompatible voice frame on IAX2/annie-home-6 of format slin since our native format has changed to ulaw
Jul  3 15:23:49 NOTICE[3058]: channel.c:1904 ast_read: Dropping incompatible voice frame on IAX2/annie-home-6 of format slin since our native format has changed to ulaw
Jul  3 15:23:49 NOTICE[3058]: channel.c:1904 ast_read: Dropping incompatible voice frame on IAX2/annie-home-6 of format slin since our native format has changed to ulaw
Jul  3 15:23:49 NOTICE[3058]: channel.c:1904 ast_read: Dropping incompatible voice frame on IAX2/annie-home-6 of format slin since our native format has changed to ulaw
Jul  3 15:23:50 NOTICE[3058]: channel.c:1904 ast_read: Dropping incompatible voice frame on IAX2/annie-home-6 of format slin since our native format has changed to ulaw
   -- Hungup 'IAX2/annie-home-6'
 == Spawn extension (default, 1, 1) exited non-zero on 'Zap/1-1'
   -- Hungup 'Zap/1-1'

By: Jonathan Galpin (jlgdeveloper) 2006-07-03 15:12:00

Setting transcode_via_sln=no and restarting * has no effect, before and after the patch.

To be clear, the audio from the IAXY to the pstn caller is dropped.

Jonathan

load log re chan zap
====================
   -- Reloading module 'chan_zap.so' (Zapata Telephony w/PRI)
 == Parsing '/etc/asterisk/zapata.conf': Found
Jul  3 15:58:52 WARNING[3561]: chan_zap.c:10886 setup_zap: Ignoring signalling
   -- Reconfigured channel 1, FXS Kewlstart signalling
   -- Reconfigured channel 2, FXS Kewlstart signalling
   -- Reloading module 'chan_mgcp.so' (Media Gateway Control Protocol (MGCP))
   -- Reloading module 'app_queue.so' (True Call Queueing)
 == Parsing '/etc/asterisk/queues.conf': Found
   -- Reloading module 'cdr_pgsql.so' (PostgreSQL CDR Backend)
 == Parsing '/etc/asterisk/cdr_pgsql.conf': Found
   -- Reloading module 'cdr_custom.so' (Customizable Comma Separated Values CDR Backend)
 == Parsing '/etc/asterisk/cdr_custom.conf': Found
   -- Reloading module 'codec_adpcm.so' (Adaptive Differential PCM Coder/Decoder)
 == Parsing '/etc/asterisk/codecs.conf': Found
   -- codec_adpcm: using generic PLC
   -- Reloading module 'codec_ulaw.so' (Mu-law Coder/Decoder)
Reloading SIP
 == Parsing '/etc/asterisk/sip.conf': Found
Reloading MGCP
 == Parsing '/etc/asterisk/mgcp.conf': Found
   -- Registered IAX2 to '64.61.93.90', who sees us as 70.124.132.xxx:4569 with no messages waiting

   -- Registered IAX2 to '64.61.93.87', who sees us as 70.124.132.xxx:3405 with no messages waiting

 == Parsing '/etc/asterisk/sip_notify.conf': Found
Jul  3 15:58:52 WARNING[2168]: chan_mgcp.c:4209 reload_config: Unable to get our IP address, MGCP disabled

==================================================

By: Michael Neuhauser (mneuhauser) 2006-07-04 02:36:49

jlgdeveloper: sorry for your wasted time -- my patch can only affect the behaviour of forwarded calls (scenario as described in note 0044294) and as far as I can see, no call forwarding is happening in your case

By: Jonathan Galpin (jlgdeveloper) 2006-07-05 08:45:23

Thanks mneuhauser, I'll report this as a separate bug.

By: Joshua C. Colp (jcolp) 2006-09-09 15:48:47

Okay people - grab the latest 1.2 and tell me if this is still an issue. I *think* I may have solved it.

By: Joshua C. Colp (jcolp) 2006-09-09 15:49:05

1.2 branch that is, not the latest 1.2 release

By: Serge Vecher (serge-v) 2006-09-12 10:34:16

for documentation sake, the potential fix is in r42402 of 1.2 branch, which is now in 1.2.12.1



By: Matt O'Gorman (mogorman) 2006-09-26 14:18:41

glad to hear the problem is solved