[Home]

Summary:ASTERISK-02007: cannot transfer calls placed on PSTN trunk
Reporter:Lee Howard (faxguy)Labels:
Date Opened:2004-07-13 13:37:49Date Closed:2011-06-07 14:10:26
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When a call is placed on the PSTN trunk:

Executing Dial("SIP/office-6f50", "Zap/g1/4010110|70|T") in new stack

I cannot transfer that call (to parking or to another extension).  Pressing "#" just makes the DTMF noise, but I get no "transfer" message.
Comments:By: twisted (twisted) 2004-07-13 13:41:13

Okay.  What version are you running, and what is your DTMF configured to in sip.conf and on the phone?
By: twisted (twisted) 2004-07-13 13:42:22

also, this is not a MAJOR bug.  I have reclassified to MINOR.
By: Lee Howard (faxguy) 2004-07-13 14:01:20

I'm using CVS-HEAD-6/23/04-10:24:09

In sip.conf, dtmfmode=inband

On the phone I have tried both "via RTP" and "in-audio".

I can transfer calls placed from one station to another (SIP-to-SIP) just fine.
By: twisted (twisted) 2004-07-13 14:05:02

since  you are using inband, your codec absolutley HAS to be ulaw from your phone to your asterisk box.  Also, if you use inband dtmf, please be aware this is highly un-reliable.  Try switching to SIP-INFO (dtmfmode=info in sip.conf) and set your phone accordingly.
By: Lee Howard (faxguy) 2004-07-13 14:24:19

I am using ulaw.

I switched to dtmfmode=info and switched the phone to SIP-INFO.

Again, I can transfer station-to-station calls just fine:

Executing Dial("SIP/office-bb93", "SIP/fax|70|T") in new stack

Only the calls placed through the Zaptel trunk cannot be transferred.

The other question that I have, though, is that after it begins working, what happens when I call a number that requires me to "press #" to do something?  How can I "press #" without simultaneously transferring the call?
By: twisted (twisted) 2004-07-13 14:42:42

See my patch on bug ASTERISK-1984 for a workaround ;)
By: Lee Howard (faxguy) 2004-07-13 14:49:32

Thanks.  Does the patch fix the problem with me (still with using SIP-INFO) not being able to transfer calls that are placed on the PSTN through the X100P?
By: twisted (twisted) 2004-07-13 14:50:46

No, that patch has nothing to do with it, but you *COULD* try appplying it and changing the transfer key and see if it makes any difference in your attempt.
By: Mark Spencer (markster) 2004-07-14 06:51:27

When you do "show channels" do they both say they are "UP"?
By: Lee Howard (faxguy) 2004-07-14 09:52:21

In fact, no.

-- Executing Dial("SIP/office-6f50", "Zap/g1/4010110|70|T") in new stack
-- Called g1/4010110
show channels
*CLI> show channels
       Channel  (Context    Extension    Pri )   State Appl.         Data          
       Zap/1-1  (default    s            1   ) Dialing AppDial       (Outgoing Line)
SIP/office-afc7  (default    4010110      1   )    Ring Dial          Zap/g1/4010110|70|T
2 active channel(s)

Which tells me that, although there is no ringing heard on SIP/office, and I can talk back and forth happily over that connection, Asterisk still thinks that it is waiting for the called person to pick up and it still thinks that it is playing ringing noises to SIP/office.  So, if the conversation runs more than 70 seconds...

   -- Nobody picked up in 70000 ms
   -- Hungup 'Zap/1-1'
   -- Executing Congestion("SIP/office-afc7", "") in new stack
 == Spawn extension (default, 4010110, 2) exited non-zero on 'SIP/office-afc7'

The interesting thing here is that although the called person's phone detected a disconnection, SIP/office did not and remained "off hook" (so to speak) and did not play the "busy" noise (there was just silence, and I had to place the phone on hook).  Anyway I changed the config file to eliminate the 70-second dialing restriction...

   -- Executing Dial("SIP/office-83c0", "Zap/g1/4010110||T") in new stack
   -- Called g1/4010110
show channels
       Channel  (Context    Extension    Pri )   State Appl.         Data          
       Zap/1-1  (default    s            1   ) Dialing AppDial       (Outgoing Line)
SIP/office-83c0  (default    4010110      1   )    Ring Dial          Zap/g1/4010110||T
2 active channel(s)

So it looks like the same thing is going on, even without the dialing time limit.  So then I have the called person hang up...

   -- Hungup 'Zap/1-1'
 == No one is available to answer at this time
   -- Executing Congestion("SIP/office-83c0", "") in new stack
 == Spawn extension (default, 4010110, 2) exited non-zero on 'SIP/office-83c0'

SIP/office then gets the "busy" noise until I place the phone on hook.
By: Mark Spencer (markster) 2004-07-14 10:06:23

Out of curiosity, have you considered disabling progress detect?
By: Lee Howard (faxguy) 2004-07-14 10:22:34

Well, I hadn't enabled progress detect deliberately.  Anyway, I just tried disabling it (callprogress=no in zaptel.conf, stopped Asterisk, reloaded zaptel+wcfxo, restarted Asterisk).

The only noticeable effect was that I no longer get the busy signal when the called person hangs up, just silence.  But everything else is the same as far as I can tell.  The transfer does not work still, and 'show channels' reveals the same information.
By: Mark Spencer (markster) 2004-07-14 20:52:00

find me on irc, please.  i still think there's something strange in the configuration.  if you *really* have progress detect disabled, then it's immediately considered up as soon as it finishes dialing.
By: alric (alric) 2004-07-18 10:16:45

Reminder from housekeeping.  Have you attempted to contact Mark over IRC to resolve this bug?
By: Lee Howard (faxguy) 2004-07-18 11:35:31

I have been trying to reach Mark on IRC for several days now.  He seems to be there only late in the evenings for a few hours.  There are only a couple of days per week when I can sit around on IRC at that time, and when I have tried, Mark has not been there.

Mark, if you want to tell me exactly *when* you'll be on IRC, then it would be much easier for me to find you there.
By: Lee Howard (faxguy) 2004-07-24 14:37:27

I did manage to reach Mark on IRC.  However, he was short on time and furthermore insisted that my problems are all self-inflicted configuration issues.  (sigh)

Firstly, I don't know why I was asked (with sarcasm, I might add), "have you considered disabling progress detect" when callprogress *was* disabled.  That should have been somewhat obvious to anyone familiar with callprogress since I did not show any "Zap/1-1 is ringing" lines in my logging.  I don't really understand why it was assumed that callprogress was enabled.  It wasn't, and the log I showed certainly shows no indication of it, either.

I don't know the secret to weeding out the kinds of reports that are invalid bug reports from those that are valid, but since everyone here is keenly interested in the equity in Asterisk, I would certainly hope that those who respond to a bug report would at least try to look at things from the perspective of the reporter before deciding that the report is invalid.

From what I've learned, a call cannot be transferred unless it first is "up" (answered).  Why?  It seems like a silly limitation.  Has nobody else here ever handed off phone they just dialed on to someone else, before the remote answers?  My wife says, "Can you call your mom and ask her this and this and this?"  And since I am not fond of being a go-between and since my wife doesn't know how to use my cell phone, I dial the number for her and then hand it off to her so that she can talk to my mother herself.  This happens at the office, too, where a coworker says, "Can you get so-and-so on the phone for me?  I don't have their number."  And so you call up so-and-so and then transfer the call to the coworker before the receiver answers.  Think about calling a radio station, where they don't answer the ringing phone for several minutes, and you may want to walk around the office and go to another station.  Anyway, needless to say, I can think of several situations where the real "bug" here is in the limitation of only transferring calls that are "up" or answered.  Does nobody else see that?

Okay, so that's one bug, here's another:  when I change callprogress in zapata.conf the setting is not changed in asterisk when I 'reload'.  In order to get the setting to change I must 'stop now' and then restart asterisk fresh.

And, I realize that callprogress is experimental, but here's a bug with it:  when a call is placed, someone has to actually yell into the phone in order to trigger the "Zap/1-1 answered SIP/office-b6a4" message and get the call status to be "up".  Normal talking volumes will not trigger that.  Seems a bug in that if it says "Zap/1-1 is ringing" and then several seconds pass without it detecting a ring, then the call must have been answered.  In this case there's no need to actually listen for voice to know that the call was answered.

And, I will restate the bug that I am reporting here:  if callprogress=no then the channels status never gets to the "up" state.  It continues in "Dialing" and "Ring".  This prevents the caller from transferring the call.
By: twisted (twisted) 2004-07-24 15:33:53

Wow.

Well, first off, if we don't bridge the channels, it makes it difficult to listen for the frames to and from during the call, as we are relying on our bridge as a "pull point".  Quite honestly, if we need to transfer a call before the calling party answers, someone else should really have initiated it; however, you should be able to use the native SIP transfer to transfer this call to another location if needed.

Also, please remain calm with Markster and the rest of us who are trying to help you, since Markster has been quite busy as of late, there are many, many, pending issues that need to be resolved, and simply asking a question about progress detect doesn't warrant a paragraph of strife.

Thanks you.
By: twisted (twisted) 2004-07-24 15:34:32

Oh - we will, btw, check the code, as if we're not enabling progress detect, the call should, by default, be in the "Up" state.
By: Mark Spencer (markster) 2004-07-24 17:44:59

faxguy: Let me try to clarify a few things:

1) "#" transfer is not enabled before the call has been answered.  If you use flashhook or sip transfer, then it will as you expect it to. You can make it a feature request that # transfer be extended that way, but it's not a bug that it doesn't do it now.

2) zapata.conf is not reloaded on a "reload".  Again, this is just a feature that has not yet been implemented -- and is a challenging one at that.

3) The volume setting for progress detection is configurable, so you can make it whatever you want.

4) The reason I asked if you had turned off progress detect (not sarchastically) is because that's the only thing which (by design) changes when the line is considered answered.  Other than that it's always considered answered as soon as dialing is complete.  I even tested that functionality this morning just to be absolutely positive it hadn't broken, both with and without echo training.

5) Not to be too picky here, but remember that you're trying to get support on a fake X100P that you're having trouble with -- sure, you saved the money by not buying a digium card and supporting the project, but now that you have a problem, you're still trying to use Digium resources to solve it.

At this point, I believe your problem to be either a configuration problem, or a bug which is triggered by some obscure combination of settings.  I suggest you purchase a Digium card which will entitle you to technical support which will resolve your issue.

Additionally, you might consider funding some of the development of the features that you want to see added to Asterisk.
By: Lee Howard (faxguy) 2004-07-26 17:10:05

(reopening just to follow up and then closing again)

In case anyone cares...

I was about to fix this in the codebase myself and decided to update to current CVS before doing so, and to my satisfaction the problem (the one where callprogress=no prevents the call status from ever going to "up") is no longer present with today's CVS.  It seems that someone fixed it already.  So this bug is closed in my book also now.

For the record, however, the website says that a purchase of Digium hardware provides the purchaser with *installation* support from Digium.  I knew that I didn't need installation support; I didn't even want installation support.  If Digium had been selling the AMI-IA92/IE92 without installation support for $15 I would have happily purchased it from Digium instead of eebuy.com.  The website does not say that with the purchase of Digium hardware that the purchaser is entitled to Asterisk bugfix support on the bug tracker.  So if that's the case, then it needs to be clarified so that people who may actually want bugfix support from Digium for Asterisk don't get confused into thinking that they have to go as far as purchasing a support contract.

It was not my desire to abuse Digium resources.  In fact, I expected non-Digium staff (bug marshals) to be handling the matter.  Bug marshals aren't paid by Digium, are they?  If the bug tracker is not intended to handle bugs involving non-Digium hardware, then that needs to be stated up-front so that we can find ourselves a different forum and a different set of Asterisk developers, and it would be most ethical if you notified all of the bug marshals that are not on Digium payroll that they are essentially Digium volunteers, and not particularly Asterisk volunteers.  As it is, the bug tracker doesn't make any exclusions with respect to what type of Asterisk bugs may and may not be reported here.
By: Mark Spencer (markster) 2004-07-26 23:45:58

The bug tracker is not officially limited to supporting Digium only hardware.  Most of the bugs that we handle through here are specific to SIP, MGCP, etc. and really have nothing to do with the hardware we sell.

However, technical support and configuration issues, regardless of whether they are for Digium hardware or non-Digium hardware, do not belong in the bug tracker.  The bug tracker must remain focused on actual, real, general software bugs, or it will rapidly become entirely unamanagable.

Digium does take "Installation Support" rather broadly, and if you talk to other Digium customers, you'll find that we support the things that directly touch our hardware very well.

Most Bug Marshals are not paid by Digium, although some of Digium's staff does act in the Bug Marshal capacity.  However, there is only so much that a Bug Marshal can do with a given bug -- and this one is a prime example.  For the most part, much of the burden of the bug tracker eventually falls upon Digium, and upon me personally in order to diagnose, review patches, merge patches, and often create the patches to fix problems that people have, regardless of whether they are or are not Digium customers.

In the future, I suggest you try to treat those who are trying to help you with more respect and genuine appreciation -- and do more to actually contribute to the Asterisk project, one way or another, before you start complaining about the free service you receive.