Has anyone had any experience of these phones on Trixbox, particularly
has anyone managed to get call transfers working?
My phones have firmware 020610000000 / 041.00 and EEPROM version 93.
I have followed instructions found on various forums / newsgroups, and
have done the following:
Made sure chan_local.so is loaded
made sure the siemens send DTMF over SIP
made sure the dialplan options include T and t for all routes
(including internal)
Edited features.conf like so:
[general]
featuredigittimeout => 999 ; The default of 500 was too short
transferdigittimeout => 8 ; again, default too short
[featuremap]
blindxfer => ## ; Blind transfer
atxfer => #1 ; Attended transfer
disconnect => #0 ; Disconnect
The problem is, the trixbox seems to disregard the ##, #0 or #1 whilst
in a call from the seimens,
and does not allow me to input an extension number or transfer a call.
In article <1183550436.818310.232940@57g2000hsv.googlegroups. com>,
Alister <alister.gcs@hotmail.co.uk> wrote:
>Hi,
>
>Has anyone had any experience of these phones on Trixbox, particularly
>has anyone managed to get call transfers working?
I have many C460IP's on asterisk boxes - not trixbox and call transfers
are working just fine.
>made sure the dialplan options include T and t for all routes
>(including internal)
>
>Edited features.conf like so:
>
>[general]
>featuredigittimeout => 999 ; The default of 500 was too short
>transferdigittimeout => 8 ; again, default too short
>
>[featuremap]
>blindxfer => ## ; Blind transfer
>atxfer => #1 ; Attended transfer
>disconnect => #0 ; Disconnect
Looks very familiar
>The problem is, the trixbox seems to disregard the ##, #0 or #1 whilst
>in a call from the seimens,
>and does not allow me to input an extension number or transfer a call.
>
>Anyone got any suggestions?
I'd go in and manually check the extensions.conf file(s) generated by
trixbox to make sure they really do have the Tt options in the dial
instructions. (I don't use trixbox, so not much more help than this
though)
I'd also set the C460's to use rfc2833 for tones, and have this in the
sip.conf file. I had to un-check the "in audio" option, but I've no idea
if the config for the c450's are similar.
If you have another SIP phone (not a C450), you can see if the ##
is working on that first - that would make sure the trixobx system is
actually listening out for the ## code - at least if that worked (or
didn't) it would give you a closer pointer to look at .. (ie. elimiate
the trixbox if it worked, or point the finger at trixbox if it didn't!)
On 4 Jul, 13:26, Gordon Henderson <gordon+use...@drogon.net> wrote:
> In article <1183550436.818310.232...@57g2000hsv.googlegroups. com>,
>
> Alister <alister....@hotmail.co.uk> wrote:
<snip>
> Looks very familiar
>
> >The problem is, the trixbox seems to disregard the ##, #0 or #1 whilst
> >in a call from the seimens,
> >and does not allow me to input an extension number or transfer a call.
>
> >Anyone got any suggestions?
>
> I'd go in and manually check the extensions.conf file(s) generated by
> trixbox to make sure they really do have the Tt options in the dial
> instructions. (I don't use trixbox, so not much more help than this
> though)
>
> I'd also set the C460's to use rfc2833 for tones, and have this in the
> sip.conf file. I had to un-check the "in audio" option, but I've no idea
> if the config for the c450's are similar.
>
> If you have another SIP phone (not a C450), you can see if the ##
> is working on that first - that would make sure the trixobx system is
> actually listening out for the ## code - at least if that worked (or
> didn't) it would give you a closer pointer to look at .. (ie. elimiate
> the trixbox if it worked, or point the finger at trixbox if it didn't!)
>
> Gordon
Thanks Gordon,
Forgot to say that with our desktop phones (Atcom AT-530) although
they normally transfer
calls using their built in FWD key, they will work using ## <number>
so the Trixbox bit seems to
work ok for them.
Looking through the trixbox logs, when using an AT-530 you see the
line
'DTMF received on channel SIP/blah' followed by the usual code as it
translates the specified
extension number and sets up the call. When you use the Siemens,
nothing.
I might add that it is not just one handset that has this problem. We
are running 20 or so desktop
phones and 12 Seimens handsets, using 4 base stations, and we have the
same problem with any
of the Siemens.
After serious thinking Tim wrote :
> Alister wrote:
>> Hi,
>>
>> Has anyone had any experience of these phones on Trixbox, particularly
>> has anyone managed to get call transfers working?
>
>
> Have you changed the DTMF type to RFC2833? Untick where it says Audio.
>
> Tim
Hmm.
Call transfer works fine on inbound calls to the handset, albeit using
the # key, rather than R.
Unfortunately, there seems no way to transfer a call that has been
initiated on the handset.
Pressing R does nothing.
Pressing #, I can hear the tone which seems to echo back repeatedly.
Any tips Tim?
At this point, I think I may be better off with normal cordless phones
plugged into an SPA or PAP2.....
In article <mn.7b847d77248baa49.77298@blueyonder.invalid>,
Jono <nothanks@blueyonder.invalid> wrote:
>After serious thinking Tim wrote :
>> Alister wrote:
>>> Hi,
>>>
>>> Has anyone had any experience of these phones on Trixbox, particularly
>>> has anyone managed to get call transfers working?
>>
>>
>> Have you changed the DTMF type to RFC2833? Untick where it says Audio.
>>
>> Tim
>
>Hmm.
>
>Call transfer works fine on inbound calls to the handset, albeit using
>the # key, rather than R.
>
>Unfortunately, there seems no way to transfer a call that has been
>initiated on the handset.
>
>Pressing R does nothing.
>
>Pressing #, I can hear the tone which seems to echo back repeatedly.
>
>Any tips Tim?
>
>At this point, I think I may be better off with normal cordless phones
>plugged into an SPA or PAP2.....
You need both t and T in the Dial() command in the dialplan.
I've no idea how you implement this in Trixbox though.
In article <mn.85567d77592cc87f.48968@blueyonder.invalid>,
Jono <nothanks@blueyonder.invalid> wrote:
>Gordon Henderson explained on 15/07/2007 :
>
>>
>> You need both t and T in the Dial() command in the dialplan.
>>
>> I've no idea how you implement this in Trixbox though.
>>
>> Gordon
>
>Yes, thanks. I had considered that, however, any IVRs that require a #
>to be dialled result in the transfer process commencing.
>
>I wish the Siemens' R key worked.
Me too )-: It works in the analogue side of things, but not yet on the
SIP side.
You can change the codes if features.conf (or however trixbox lets you
edit that file), but it still might not be 100% and the Siemens don't
like passing on a * either - although I've never tried it once the
call is established - any trailling * when dialling is interpreted as
"switch to the non default port" (ie. if VoIP is the default, then the
number will be dialled over the PSTN connection)
Jono wrote:
> Gordon Henderson explained on 15/07/2007 :
>
>>
>> You need both t and T in the Dial() command in the dialplan.
>>
>> I've no idea how you implement this in Trixbox though.
>>
>> Gordon
>
> Yes, thanks. I had considered that, however, any IVRs that require a #
> to be dialled result in the transfer process commencing.
>
> I wish the Siemens' R key worked.
>
>
The Siemens "R" key does work, Asterisk doesn't know how to handle the
flash-hook signal that the R key sends. The actual signal depends on
your selected DTMF method, rfc2833 sends an RTP DTMF Event message with
a value of 16. SIP Info sends a SIP INFO message with event value 16
but you can change this in the Siemens config because there is currently
no standardised way of sending a flash hook in SIP Info.
Paul Hayes wrote on 17/07/2007 :
> Jono wrote:
>> Gordon Henderson explained on 15/07/2007 :
>>
>>>
>>> You need both t and T in the Dial() command in the dialplan.
>>>
>>> I've no idea how you implement this in Trixbox though.
>>>
>>> Gordon
>>
>> Yes, thanks. I had considered that, however, any IVRs that require a # to
>> be dialled result in the transfer process commencing.
>>
>> I wish the Siemens' R key worked.
>>
>>
>
> The Siemens "R" key does work, Asterisk doesn't know how to handle the
> flash-hook signal that the R key sends.
Righty-Oh. Perhaps I could've worded what I said slight differently: "I
wish the Siemens' R key worked in a way that Asterisk understood"
> The actual signal depends on your
> selected DTMF method, rfc2833 sends an RTP DTMF Event message with a value of
> 16. SIP Info sends a SIP INFO message with event value 16 but you can change
> this in the Siemens config because there is currently no standardised way of
> sending a flash hook in SIP Info.
Paul, ....if I read you correctly, the R key /will/ work with Asterisk,
if the Siemens config is set correctly.......I'm fairly sure I tried
all three choices, individually & combined, however, I don't think I
used all possible combinations....
Jono wrote:
> Paul Hayes wrote on 17/07/2007 :
>> Jono wrote:
>>> Gordon Henderson explained on 15/07/2007 :
>>>
>>>>
>>>> You need both t and T in the Dial() command in the dialplan.
>>>>
>>>> I've no idea how you implement this in Trixbox though.
>>>>
>>>> Gordon
>>>
>>> Yes, thanks. I had considered that, however, any IVRs that require a
>>> # to be dialled result in the transfer process commencing.
>>>
>>> I wish the Siemens' R key worked.
>>>
>>>
>>
>> The Siemens "R" key does work, Asterisk doesn't know how to handle the
>> flash-hook signal that the R key sends.
>
> Righty-Oh. Perhaps I could've worded what I said slight differently: "I
> wish the Siemens' R key worked in a way that Asterisk understood"
>
>> The actual signal depends on your selected DTMF method, rfc2833 sends
>> an RTP DTMF Event message with a value of 16. SIP Info sends a SIP
>> INFO message with event value 16 but you can change this in the
>> Siemens config because there is currently no standardised way of
>> sending a flash hook in SIP Info.
>
> Paul, ....if I read you correctly, the R key /will/ work with Asterisk,
> if the Siemens config is set correctly.......I'm fairly sure I tried all
> three choices, individually & combined, however, I don't think I used
> all possible combinations....
>
>
I don't think so at the moment. I've been searching around for a while
for a way to get Asterisk to act on receiving either a SIP INFO Hook
Flash message or (probably more likely) an RFC2833 RTP Hook Flash
message. Sadly there doesn't seem to be anything, all I can find is
articles relating to generating/reading hook flashes through analogue
channels, not SIP. I guess Asterisk developers just expect the SIP
phone to deal with transfers. If I find anything else out I'll post it
here.
> I don't think so at the moment. I've been searching around for a while
> for a way to get Asterisk to act on receiving either a SIP INFO Hook
> Flash message or (probably more likely) an RFC2833 RTP Hook Flash
> message. Sadly there doesn't seem to be anything, all I can find is
> articles relating to generating/reading hook flashes through analogue
> channels, not SIP. I guess Asterisk developers just expect the SIP
> phone to deal with transfers. If I find anything else out I'll post it
> here.
Have you tried posting or searching at bugs.digium.com?
alexd wrote:
> Paul Hayes wrote:
>
>> I don't think so at the moment. I've been searching around for a while
>> for a way to get Asterisk to act on receiving either a SIP INFO Hook
>> Flash message or (probably more likely) an RFC2833 RTP Hook Flash
>> message. Sadly there doesn't seem to be anything, all I can find is
>> articles relating to generating/reading hook flashes through analogue
>> channels, not SIP. I guess Asterisk developers just expect the SIP
>> phone to deal with transfers. If I find anything else out I'll post it
>> here.
>
> Have you tried posting or searching at bugs.digium.com?
>
No but I've asked on the Asterisk-users mailing list and got a response
from a bloke a Digium basically saying that chan_sip doesn't need to
deal with hook flashes because "has its own (more reliable) methods of
signaling." Which basically means they expect phones to deal with
transfers and call hold rather than Asterisk dealing with it.
All is not lost however, proper hold and transfer support is coming to
the S450IP with a firmware release which will hopefully happen in the
next month. I'll post up on this newsgroup when it's available.
On 17 Jul, 13:05, Paul Hayes <nomailfo...@polog40.org.uk> wrote:
> Jono wrote:
> > Gordon Henderson explained on 15/07/2007 :
>
> >> You need both t and T in the Dial() command in the dialplan.
>
> >> I've no idea how you implement this in Trixbox though.
>
> >> Gordon
>
> > Yes, thanks. I had considered that, however, any IVRs that require a #
> > to be dialled result in the transfer process commencing.
>
> > I wish the Siemens' R key worked.
>
> The Siemens "R" key does work, Asterisk doesn't know how to handle the
> flash-hook signal that the R key sends. The actual signal depends on
> your selected DTMF method, rfc2833 sends an RTP DTMF Event message with
> a value of 16. SIP Info sends a SIP INFO message with event value 16
> but you can change this in the Siemens config because there is currently
> no standardised way of sending a flash hook in SIP Info.
>
> --
> Working Email:
>
> paul-at-polog40-dot-org-dot-uk- Hide quoted text -
>
> - Show quoted text -
Now, this is interesting, 'cos from my (very limited) knowledge of
DTMF, I would have thought
that you could send a DTMF value of 12 (which is the #) when you press
R. so I programmed a
Seimens to try this: In the advanced telephony settings I changed the
value of "Application Signal" to 12.
Result:
Nope, the phone just makes a pathetic whining noise if you press the R
key in a SIP call, from
which I deduce that Seimens have actively disabled this key in some
way for VOIP calls.
Alister wrote:
>
> Nope, the phone just makes a pathetic whining noise if you press the R
> key in a SIP call, from
> which I deduce that Seimens have actively disabled this key in some
> way for VOIP calls.
It happens that mymail@hotmail.com formulated :
> On Thu, 26 Jul 2007 20:04:51 +0100, Jono <nothanks@blueyonder.invalid>
> wrote:
>
>> Alister was thinking very hard :
>>> In the advanced telephony settings I changed the
>>> value of "Application Signal" to 12.
>>
>> I never noticed the Advanced Telephony settings.....
>>
> Just bought one of these on Monday still finding my way around it
> but must say they are a very nice piece of kit .
It would be nicer if the phone book could be configured through the web
interface....unless it can & I've missed it!
On 26 Jul, 19:50, Tim <nutn...@kooky.org> wrote:
>
> Did you tick the RFC2833 box?
>
Yep. :-)
I have noticed, BTW, that when the phone is set to use RFC2833 it
appears to
send every DTMF tone twice - so I can get the "transfer call" prompt
if I set
features.conf to use ## but only press the # key once on the phone.
Unfortunately,
it also sends the numbers twice so if I want to transfer to ext 1234 I
end up sending
11223344 to trixbox - which of course goes "WHAT???" or similar.
I have checked, and the only box I have got ticked is RFC2833, Audio
and Sip info are unchecked.
Investigating further, I have found the same behaviour with just SIP
info ticked, and nothing seems to
happen if just Audio is ticked.
I wonder if any of you can confirm this behaviour?
Alister wrote:
> On 26 Jul, 19:50, Tim <nutn...@kooky.org> wrote:
>> Did you tick the RFC2833 box?
>>
>
> Yep. :-)
>
> I have noticed, BTW, that when the phone is set to use RFC2833 it
> appears to
> send every DTMF tone twice - so I can get the "transfer call" prompt
> if I set
> features.conf to use ## but only press the # key once on the phone.
> Unfortunately,
> it also sends the numbers twice so if I want to transfer to ext 1234 I
> end up sending
> 11223344 to trixbox - which of course goes "WHAT???" or similar.
>
> I have checked, and the only box I have got ticked is RFC2833, Audio
> and Sip info are unchecked.
>
> Investigating further, I have found the same behaviour with just SIP
> info ticked, and nothing seems to
> happen if just Audio is ticked.
>
> I wonder if any of you can confirm this behaviour?
>
> Alister
>
What firmware version have you got on it? You should only hear one tone
if only one of the DTMF mode boxes is ticked, what you are describing
sounds like what happens if you've got "Audio" ticked as well as one of
the other modes.
On 30 Jul, 13:04, Paul Hayes <nomailfo...@polog40.org.uk> wrote:
> Alister wrote:
> > On 26 Jul, 19:50, Tim <nutn...@kooky.org> wrote:
> >> Did you tick the RFC2833 box?
>
> > Yep. :-)
>
> > I have noticed, BTW, that when the phone is set to use RFC2833 it
> > appears to
> > send every DTMF tone twice - so I can get the "transfer call" prompt
> > if I set
> > features.conf to use ## but only press the # key once on the phone.
> > Unfortunately,
> > it also sends the numbers twice so if I want to transfer to ext 1234 I
> > end up sending
> > 11223344 to trixbox - which of course goes "WHAT???" or similar.
>
> > I have checked, and the only box I have got ticked is RFC2833, Audio
> > and Sip info are unchecked.
>
> > Investigating further, I have found the same behaviour with just SIP
> > info ticked, and nothing seems to
> > happen if just Audio is ticked.
>
> > I wonder if any of you can confirm this behaviour?
>
> > Alister
>
> What firmware version have you got on it? You should only hear one tone
> if only one of the DTMF mode boxes is ticked, what you are describing
> sounds like what happens if you've got "Audio" ticked as well as one of
> the other modes.
My phones have firmware 020610000000 / 041.00 and EEPROM version 93.
But it helps if you change the settings on the base station the phone
is attached too!!!
Having investigated further I found I was logged into one base station
and using a phone connected
to another base station - please feel free to go DUH
If I change the settings on the /correct/ base station it works - and
yes you were right, it had Audio and RFC2833
both ticked.
>
> Having investigated further I found I was logged into one base station
> and using a phone connected
> to another base station - please feel free to go DUH
>
> If I change the settings on the /correct/ base station it works - and
> yes you were right, it had Audio and RFC2833
> both ticked.
>
> I will now get my coat...
>
>
> What firmware version have you got on it? You should only hear one tone if
> only one of the DTMF mode boxes is ticked, what you are describing sounds
> like what happens if you've got "Audio" ticked as well as one of the other
> modes.
Hello again, Paul. Any news on the updated firmware that will allow the
R key to function on a SIP call?
Jono wrote:
> Paul Hayes presented the following explanation :
>
>>
>> What firmware version have you got on it? You should only hear one
>> tone if only one of the DTMF mode boxes is ticked, what you are
>> describing sounds like what happens if you've got "Audio" ticked as
>> well as one of the other modes.
>
> Hello again, Paul. Any news on the updated firmware that will allow the
> R key to function on a SIP call?
>
>
Not yet Jono, you'll be the first to know when I do!
Paul Hayes formulated the question :
>> Hello again, Paul. Any news on the updated firmware that will allow the R
>> key to function on a SIP call?
>>
>>
> Not yet Jono, you'll be the first to know when I do!
Paul Hayes was thinking very hard :
> Jono wrote:
>> Paul Hayes presented the following explanation :
>>
>>>
>>> What firmware version have you got on it? You should only hear one tone
>>> if only one of the DTMF mode boxes is ticked, what you are describing
>>> sounds like what happens if you've got "Audio" ticked as well as one of
>>> the other modes.
>>
>> Hello again, Paul. Any news on the updated firmware that will allow the R
>> key to function on a SIP call?
>>
>>
> Not yet Jono, you'll be the first to know when I do!
Siemens S450IP and trixbox 
Linear Mode
