Problem with call transfer (Cisco Phone Softkey)

Asterisk Asterisk Support
1

Hi,

I’m having the following problem…

When i get an incomming call on the Zap channel (ISDN Junghanns QuadBRI) to a Cisco 7940 (SIP v8.2) and then subsequently try to transfer the call to another 7940 (SIP v8.2) i get transfer failed on the Cisco screen and the following log in asterisk. I’m also not getting the music on hold to the calling party on the Zap channel - not sure if this is related…

– SIP/16-a389 answered Zap/1-1
– Executing Macro(“SIP/16-53b7”, “stdexten|12|SIP/12”) in new stack
– Executing Dial(“SIP/16-53b7”, “SIP/12|20|wWtTr”) in new stack
– Called 12
– SIP/12-facd answered SIP/16-53b7
– Attempting native bridge of SIP/16-53b7 and SIP/12-facd
– Started music on hold, class ‘default’, on channel ‘SIP/12-facd’
– Stopped music on hold on SIP/12-facd
== Spawn extension (macro-stdexten, s, 1) exited non-zero on ‘SIP/16-53b7’ in macro ‘stdexten’
== Spawn extension (macro-stdexten, s, 1) exited non-zero on ‘SIP/16-53b7’
== Spawn extension (inbound-from-isdn, 642042, 1) exited non-zero on ‘Zap/1-1’
– Hungup ‘Zap/1-1’

This is
1.) Call in from Zap
2.) User on 16 attempts transfer to 12 using cisco transfer softkey
3.) Transfer Fails
4.) User on 16 comes back to incomming Zap call.
5.) Zap user hangs up.

Thanks for any help you can offer! :smile:

2

What do you have set for canreinvite for these 2 sip phones?

3

It’s set to ‘no’.

I can’t get transfer to work with the standard * (*2) either. I don’t know if it’s related or not (eg #1 works but blind transfer on the phone doesn’t either). When i try an *2 transfer the calling party gets hold music (which doesn’t happen on the phone softkey) and the transfer process goes through however the calling party never get’s taken off hold to the person being transfered to and when i hangup the Zap doesn’t get a propper hangup it just keeps the channel open (which locks it for all other incomming calls).

4

Still not managed to resolve this - can anyone help me?

If it’s a bug i’d like to know so it can be rectified.

5

Surely someone must know? :smile:

Another strange thing i’ve found is that it appears to work correctly on the second ISDN line. So if i make a call to tie up the first line and then make a second call everything appears to work. Very strange.