VoIP Mailing List Archives :: View topic - [asterisk-users] problem transferring calls some of the time

Sponsor: VoiceMeUp - Corporate & Wholesale VoIP Services

VoIP Mailing List Archives
Mailing list archives for the VoIP community

[asterisk-users] problem transferring calls some of the time

VoIP Mailing List Archives Forum Index -> Asterisk Users

View previous topic :: View next topic

Author

Message

Guest

Posted: Wed Feb 20, 2008 2:31 pm Post subject: [asterisk-users] problem transferring calls some of the time

Is it AFTER you have parked a call? Meaning, for example, you transfer
an incoming call to 700. No problem. Later, when it's picked up from
701, can it NOT be transferred again?

Moj

Ian wrote:

Quote:

Hi All

Sorry to be a bother again but seems like I just cant get away from
the problems.

This time my problem is that *sometimes* a user cant transfer a call
from one extension to another, I have narrowed down the problem to it
only happening to calls from outside the internal system.

The wierd thing about the problem is that it comes and goes one moment
the user can transfer, and the next call he can't.

I am running:

* Asterisk 1.4.17
* Zaptel 1.4.7.1
* Libpri 1.4.3

Using the following phones and firmware

* Grandstream GXP2000 (with ext pad) : 1.1.4.14
* Grandstream BT200 : 1.1.4.18

I have set up the phones to log debug logs to a syslog server, I am
still trying to figure out what exactly the log says.

Is it an * problem, or Grandstream problem

Does anyone know if I am able to see the keysequence the user types
into the phone (just in case it might even be a user made problem), I
have tried scanning though the logs of a failed call, but could not
see any lines that can be a keypress, or maybe I am looking in the
incorrect spot?

Your help will be greatly appreciated.

Let me know if, in any way, I can shed some more light on the subject.

Thanks in advance
Ian
--
www.vddi.co.za <http://www.vddi.co.za/>
I Coetzee
IT Tegnikus
Telefoon : 012 664 2300
Selfoon : 079 522 6519
Faks : 012 644 2902
E-pos : ian at vddi.co.za
Skype : vddb_igcoetzee

------------------------------------------------------------------------

_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

Guest

Posted: Fri Feb 22, 2008 12:30 pm Post subject: [asterisk-users] problem transferring calls some of the time

Are you using buttons on your phone to effect the transfer, or are you
using codes defined in features.conf?

Moj
Ian wrote:

Quote:

Hi,

Mojo with Horan & Company, LLC said the following on 20-Feb-08 09:31 PM:

Quote:

Is it AFTER you have parked a call? Meaning, for example, you transfer
an incoming call to 700. No problem. Later, when it's picked up from
701, can it NOT be transferred again?

Moj

No I don't park the call.

The call comes in, and gets redirected to our receptionists phone,
from there it gets transferred to another extension (the bosses
secratary) and then gets transferred (to the boss). now the problem,
sometimes that transfer fails, other times the call dont even want to
leave the receptionists phone.

The big thing about this problem is that it comes and goes, like
yesterday we didn't have a problem, and I did not change a thing.

Ian

Quote:

Ian wrote:

Quote:

_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

------------------------------------------------------------------------

_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

Guest

Posted: Fri Feb 22, 2008 12:58 pm Post subject: [asterisk-users] problem transferring calls some of the time

Sorry, I jut got your other message stating the steps your boss'
secretary uses to transfer calls, so this question's time is past.

I'm curious if the 'flash' button is the only way those phones can do a
transfer. Do they have any other transfer keys, or could you try the
featuremap codes? Our polycom transfer buttons have always just worked,
but my users, for some reason, all felt more comfortable using DTMF
keypresses... dunno why Smile

So we all press ## to do a blind transfer now, or ** to auto-park to
first parking space.

Moj

Mojo with Horan & Company, LLC wrote:

Quote:

Are you using buttons on your phone to effect the transfer, or are you
using codes defined in features.conf?

Moj
Ian wrote:

Quote:

Hi,

Mojo with Horan & Company, LLC said the following on 20-Feb-08 09:31 PM:

Quote:

Is it AFTER you have parked a call? Meaning, for example, you transfer
an incoming call to 700. No problem. Later, when it's picked up from
701, can it NOT be transferred again?

Moj

Quote:

Ian wrote:

Quote:

gordon+asterisk at dro...
Guest

Posted: Mon Feb 25, 2008 3:26 am Post subject: [asterisk-users] problem transferring calls some of the time

On Mon, 25 Feb 2008, Ian wrote:

Quote:

Mojo with Horan & Company, LLC said the following on 22-Feb-08 07:58 PM:

Quote:

Sorry, I jut got your other message stating the steps your boss' secretary
uses to transfer calls, so this question's time is past.

I'm curious if the 'flash' button is the only way those phones can do a
transfer. Do they have any other transfer keys, or could you try the
featuremap codes? Our polycom transfer buttons have always just worked,
but my users, for some reason, all felt more comfortable using DTMF
keypresses... dunno why Smile

I have tested the phones in numerous ways as well as studied the user manuals
of the phones, and the 'flash' key is the only way to do an attended
transfer, I will try the keys defined in features.conf today to see if it
makes a huge difference, is there any funny configurations I should be aware
of before I start playing around with the features.conf?

This thread has gotten a bit weird for my mailer, anyway, however, if
we're talking about GXP2000's, then you don't need to use a "flash" type
event to do a transfer (The GXP2000 doesn't have a flash button anyway).

On the GXP2000, to do an attended transfer, you first pick an unused
"line" and push the key. Eg. You have a call on "line 1", so push the
"line 2" key. This puts the caller on-hold, and gives you a dial-tone. You
dial the number and when it answers you can speak to them. If you then
want to transfer, push the TRNF key, THEN the "line" key corresponding to
the original call (usually "line 1") and there you go. To simple get back
to the caller, just push the original line key without the TRNF key.

GXP2100's work in the same way.

BT200's work slightly differently and they do have a "flash" button.

Attended Transfer:

1. Inform the caller you are going to transfer them.
2. Push the FLASH key. The caller will be put on hold and you will get a dial-tone.
3. Dial the extension of the 3rd party. (Remember to push the SEND key)
4. When they answer, announce the caller, and if they want to take the
call, then press the TRANSFER key and the call will be transfered and you
can hang-up.

* If you dial a wrong number, or the number is unavailable, you will
be connected back to the original caller.
* If the 3rd party doesn't answer, or the call goes into voicemail,
use the FLASH key to re-connect to the original caller.
* If the 3rd party doesn't want the call, then ask them to hang up
(you will hear a pulsed tone), then press the FLASH key to re-connect to
the original caller.
Hope this helps...

Gordon

Quote:

Thanks
Ian

Quote:

So we all press ## to do a blind transfer now, or ** to auto-park to first
parking space.

Moj

Mojo with Horan & Company, LLC wrote:

Quote:

Are you using buttons on your phone to effect the transfer, or are you
using codes defined in features.conf?

Moj
Ian wrote:

Quote:

Hi,

Mojo with Horan & Company, LLC said the following on 20-Feb-08 09:31 PM:

Quote:

Is it AFTER you have parked a call? Meaning, for example, you transfer
an incoming call to 700. No problem. Later, when it's picked up from
701, can it NOT be transferred again?
Moj

No I don't park the call.

The call comes in, and gets redirected to our receptionists phone, from
there it gets transferred to another extension (the bosses secratary) and
then gets transferred (to the boss). now the problem, sometimes that
transfer fails, other times the call dont even want to leave the
receptionists phone.

The big thing about this problem is that it comes and goes, like
yesterday we didn't have a problem, and I did not change a thing.

Ian

Quote:

Ian wrote:

Quote:

Hi All

Sorry to be a bother again but seems like I just cant get away from the
problems.

This time my problem is that *sometimes* a user cant transfer a call
from one extension to another, I have narrowed down the problem to it
only happening to calls from outside the internal system.

The wierd thing about the problem is that it comes and goes one moment
the user can transfer, and the next call he can't.

I am running:

* Asterisk 1.4.17
* Zaptel 1.4.7.1
* Libpri 1.4.3

Using the following phones and firmware

* Grandstream GXP2000 (with ext pad) : 1.1.4.14
* Grandstream BT200 : 1.1.4.18

I have set up the phones to log debug logs to a syslog server, I am
still trying to figure out what exactly the log says.

Is it an * problem, or Grandstream problem

Does anyone know if I am able to see the keysequence the user types
into the phone (just in case it might even be a user made problem), I
have tried scanning though the logs of a failed call, but could not see
any lines that can be a keypress, or maybe I am looking in the
incorrect spot?

Your help will be greatly appreciated.

Let me know if, in any way, I can shed some more light on the subject.

Thanks in advance
Ian
--
www.vddi.co.za <http://www.vddi.co.za/>
I Coetzee
IT Tegnikus
Telefoon : 012 664 2300
Selfoon : 079 522 6519
Faks : 012 644 2902
E-pos : ian at vddi.co.za
Skype : vddb_igcoetzee

------------------------------------------------------------------------

_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

nachogomez at gmail.com
Guest

Posted: Tue Feb 26, 2008 10:29 am Post subject: [asterisk-users] problem transferring calls some of the time

Ian, I'm having THE SAME PROBLEM and I've noticed that when a transfer fail (only happens when receptionist dial an external number) the call is marker as "NO ANSWER" in the CDR, even when the call HAS BEEN ANSWERED by the other party (the callee). See my previous post below. http://lists.digium.com/pipermail/asterisk-users/2008-February/206228.html http://lists.digium.com/pipermail/asterisk-users/2008-February/206533.html So I think Asterisk doesn't want to transfer calls that hasn't been answered, OR maybe are the phone itself (since I have the EXACT phones you have GXP-2000), that is causing the problem. BTW: I have the same Asterisk, Zaptel and Libpri versions as you have. Please check your CDR and look if the calls that has failed to transfer are marked as "NO ANSWER". Thanks, I hope we can solve this anytime soon... -- Nacho Linux Counter #156439 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080227/d0f083dc/attachment.htm

asterisk at iancoetzee...
Guest

Posted: Wed Feb 27, 2008 2:27 am Post subject: [asterisk-users] problem transferring calls some of the time

Hi Ra?l

It would seem that we might have the same problem here. As I also get
"No Answer" records in the cdr database for the calls that failed. I
just checked against a tester I did yesterday that failed.

See the extract of the call from the CDR database, does it look anything
like yours?

calldate
<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60calldate%60+ASC>
clid
<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60clid%60+ASC>
src
<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60src%60+ASC>
dst
<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60dst%60+ASC>
dcontext
<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60dcontext%60+ASC>
channel
<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60channel%60+ASC>
dstchannel
<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60dstchannel%60+ASC>
lastapp
<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60lastapp%60+ASC>
lastdata
<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60lastdata%60+ASC>
duration
<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60duration%60+ASC>
billsec
<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60billsec%60+ASC>
disposition
<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60disposition%60+ASC>
amaflags
<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60amaflags%60+ASC>
accountcode
<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60accountcode%60+ASC>
uniqueid
<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60uniqueid%60+ASC>
userfield
<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60userfield%60+ASC>

2008-02-26 14:11:59 s incoming_calls Zap/4-1
SIP/300-009218b0 Dial SIP/300 116 106 ANSWERED 3
2008-02-26 14:14:12 "Luzaan lyn 1" <300> 300 301 internal
SIP/300-00835200 SIP/301-00843750 Dial SIP/301|30 19 9
ANSWERED 3
2008-02-26 14:18:09 301 301 s internal SIP/316-00919110
4 0 NO ANSWER 3

Ra?l G?mez C. said the following on 26-Feb-08 05:29 PM:

Quote:

Ian,

I'm having *THE SAME PROBLEM* and I've noticed that when a transfer
fail (only happens when receptionist dial an external number) the call
is marker as "NO ANSWER" in the CDR, even when the call *HAS BEEN
ANSWERED* by the other party (the callee). See my previous post below.

http://lists.digium.com/pipermail/asterisk-users/2008-February/206228.html

http://lists.digium.com/pipermail/asterisk-users/2008-February/206533.html

So I think Asterisk doesn't want to transfer calls that hasn't been
answered, *OR* maybe are the phone itself (since I have the EXACT
phones you have GXP-2000), that is causing the problem.

My testing and log whatching got me believing its a problem with
"Zombie" calls becuase of reregistering on the Grandstream phones. Dont
know if you have noticed it as well, almost always happens at the top of
the hour.

Quote:

BTW: I have the same Asterisk, Zaptel and Libpri versions as you have.

I downgraded from 1.4.8 to 1.4.7.1 in favour of being able to dial using
DTMF.

Quote:

Please check your CDR and look if the calls that has failed to
transfer are marked as "NO ANSWER".

You are spot on here.

Quote:

Thanks, I hope we can solve this anytime soon...

So do I, I am glad that there is someone else with this problem, I think
we can help each other in this matter.

Regards
Ian

Quote:

--
Nacho
Linux Counter #156439
------------------------------------------------------------------------

_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080227/29f12310/attachment.htm

nachogomez at gmail.com
Guest

Posted: Wed Feb 27, 2008 8:53 am Post subject: [asterisk-users] problem transferring calls some of the time

Hi Ian,

I'm out of the office for the day, but as soon as I can I'll check my logs
looking for Zombie calls, although my GXP-2000 are configured with static IP
so there's no (re)registry in my case (host=PhoneIPaddr in sip.conf).

On Thu, Feb 28, 2008 at 2:57 AM, Ian <asterisk at iancoetzee.za.net> wrote:

Quote:

See the extract of the call from the CDR database, does it look anything
like yours?

calldate<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60calldate%60+ASC>
clid<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60clid%60+ASC>
src<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60src%60+ASC>
dst<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60dst%60+ASC>
dcontext<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60dcontext%60+ASC>
channel<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60channel%60+ASC>
dstchannel<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60dstchannel%60+ASC>
lastapp<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60lastapp%60+ASC>
lastdata<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60lastdata%60+ASC>
duration<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60duration%60+ASC>
billsec<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60billsec%60+ASC>
disposition<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60disposition%60+ASC>
amaflags<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60amaflags%60+ASC>
accountcode<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60accountcode%60+ASC>
uniqueid<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60uniqueid%60+ASC>
userfield<http://phpmyadmin.vddi.co.za/sql.php?db=asterisk&table=cdr&token=b9559eee360f2461b1d1670e60aca5fe&sql_query=SELECT+%2AFROM+%60cdr%60++ORDER+BY+%60cdr%60.%60userfield%60+ASC> 2008-02-26
14:11:59 s incoming_calls Zap/4-1 SIP/300-009218b0 Dial SIP/300 116
106 ANSWERED 3 2008-02-26 14:14:12 "Luzaan lyn 1" <300> 300 301
internal SIP/300-00835200 SIP/301-00843750 Dial SIP/301|30 19 9 ANSWERED 3
2008-02-26 14:18:09 301 301 s internal SIP/316-00919110 4 0 NO
ANSWER 3

Just curiosity, but in this failed call, are you calling to an external
number of your PBX??? (I see a 's' in dst field, or it's just an obfuscated
field in order to get privacy? which is very valid BTW)

Another thing is, do you know for certain if your telco provider offer any
method of answer/disconnection supervision on your lines (like polarity
reversal)???
I downgraded from 1.4.8 to 1.4.7.1 in favour of being able to dial using

Quote:

DTMF.

This mean that Zaptel 1.4.8 doesn't support DTMF Dial??? I didn't know that
:s

So do I, I am glad that there is someone else with this problem, I think we

Quote:

can help each other in this matter.

I'm glad too, at least I'm not the only one struggling with this, as soon I
can get to the office I'll be working on that again!!!

BTW: What hardware do you have??? I'm using a Sangoma Remora A400D (2 FXS /
10 FXO) with EC.

Best Regards

--
Ra?l (Nacho) G?mez
Linux Counter #156439
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080228/6614f26e/attachment.htm

nachogomez at gmail.com
Guest

Posted: Mon Mar 03, 2008 1:04 pm Post subject: [asterisk-users] problem transferring calls some of the time

Ian (and the rest of the list), I've found something in order to resolve this issue... In the config file (sample) "features.conf" are some commented lines that said: "; Note that the DTMF features listed below only work when two channels have answered and are bridged together. ; They can not be used while the remote party is ringing or in progress. If you require this feature you can use ; chan_local in combination with Answer to accomplish it." I will try this and let you know anything new about this issue, If you (or anyone) can try it too and if this fix the issue a post with the config is really appreciated. -- Raul Linux Counter #156439 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080304/6dddbaa6/attachment.htm

nachogomez at gmail.com
Guest

Posted: Mon Mar 03, 2008 1:34 pm Post subject: [asterisk-users] problem transferring calls some of the time

Quote:

In the config file (sample) "features.conf" are some commented lines that
said:

*"; Note that the DTMF features listed below only work when two channels
have answered and are bridged together.
; They can not be used while the remote party is ringing or in progress.
If you require this feature you can use
; chan_local in combination with Answer to accomplish it."*

BTW: I don't have a clue how "*can I use chan_local in combination with
Answer to accomplish it."*, so if anyone knows please give some help!

Thanks in advance...

--
Raul
Linux Counter #156439
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080304/77c9fcbd/attachment.htm

nachogomez at gmail.com
Guest

Posted: Wed Mar 05, 2008 12:40 pm Post subject: [asterisk-users] problem transferring calls some of the time

Ian, I'm unable to transfer calls using 2, I'm not sure why. Here's my configs: sip.conf* [User1] type=friend username=111 context=default callerid=User Name <111> host=10.10.1.111 nat=no canreinvite=no dtmfmode=info call-limit=4 mailbox=111 at default disallow=all allow=ulaw allow=alaw ;allow=gsm ;callgroup=1,3-4 ;pickupgroup=1,3-5 ;callingpres=allowed_passed_screen features.conf: [general] transferdigittimeout => 3 xfersound = beep xferfailsound = beeperr pickupexten = 8 featuredigittimeout = 500 atxfernoanswertimeout = 15 [featuremap] blindxfer => #2 disconnect => 0 ;automon => 1 atxfer => 2 ;parkcall => #72 In the phones the "Send DTMF:" is set to "in-audio" and "via SIP INFO" What I'm missing here?? -- Raul Linux Counter #156439 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080306/7a390d3d/attachment.htm

Display posts from previous:

	VoIP Mailing List Archives Forum Index -> Asterisk Users	All times are GMT - 5 Hours
Page 1 of 1

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum