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

Ian asterisk at iancoetzee.za.net
Sun Feb 24 23:39:10 CST 2008


Mojo with Horan & Company, LLC said the following on 22-Feb-08 07:58 PM:
> 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 :)
>   
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?

Thanks
Ian
> 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:
>   
>> Are you using buttons on your phone to effect the transfer, or are you 
>> using codes defined in features.conf?
>>
>> Moj
>> Ian wrote:
>>   
>>     
>>> Hi,
>>>
>>> Mojo with Horan & Company, LLC said the following on 20-Feb-08 09:31 PM:
>>>     
>>>       
>>>> 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
>>>     
>>>       
>>>> Ian wrote:
>>>>   
>>>>       
>>>>         
>>>>> 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
>>>>>     
>>>>>         
>>>>>           
>>>> _______________________________________________
>>>> -- 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
>>>     
>>>       
>> _______________________________________________
>> -- 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
>
>
>
>   

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


More information about the asterisk-users mailing list