Cisco 7960 Phones, Call Transfer 1 Way Audio Issues

Asterisk Asterisk Support
1

I recently deployed a new system built with Asterisk 1.4.15 to replace a badly built 1.2 version system. Everything seems to be working fine except for transferring calls between some of our Cisco 7960 phones. The case setup is basically call comes in via PSTN, hits our server, is transferred via IAX to our other server, and then to the first phone. First phone answers the call, presses the transfer button, call quality is ok during the consult phases, hangs up or presses transfer again to finish the transfer to phone 2, and the when phone 2 and the original caller are connected the audio from caller to phone 2 is not being transferred but the audio from phone 2 to caller is. The blindxfer function on the Cisco appears to be working and the software blindxfer (press #) appears to be working. We have Polycom phones as well, and they all seem to work perfectly (whether talking to the Ciscos or not).

I’m not seeing a lot in the logs when the issue happens except for this:

WARNING[17516]: chan_sip.c:3634 sip_write: Asked to transmit frame type 64, while native formats is 0x4 (ulaw)(4) read/write = 0x4 (ulaw)(4)/0x4 (ulaw)(4)

This message basically floods in while the call is still connected. No audio should be being transmitted in type 64 (whatever that is). The IAX tunnel is set to only use ulaw:

disallow=all
allow=ulaw

I’m seeing these messages in my debug logs (not necessarily together):

DEBUG[2718] chan_iax2.c: Ooh, voice format changed to 4
DEBUG[3580] chan_iax2.c: Received iseqno 34 not within window 35->35

Here is IAX.conf one (IP’s and names changed to protect the innocent):

[general]
bindport=4569
bindaddr=192.168.0.150
language=en
disallow=all
allow=ulaw
jitterbuffer=no
forcejitterbuffer=no
autokill=yes

[svr2-svr1]
type=user
secret=******
context=pri-inbound
permit=192.168.1.82

[svr1-svr2]
type=peer
username=svr1-svr2
secret=******
host=192.168.1.82
qualify=yes

And this is file two:

[general]
bindport=4569
bindaddr=192.168.1.82
language=en
disallow=all
allow=ulaw
jitterbuffer=no
forcejitterbuffer=no
autokill=yes

[svr1-svr2]
type=user
secret=******
context=outbound
permit=192.168.0.150

[svr2-svr1]
type=peer
username=svr2-svr1
secret=******
host=192.168.0.150
qualify=yes

Any ideas? The warnings in the log make me think maybe this is an IAX problem? Thanks for the help.

2

Hi,

This will give you a clue on 64;

64 (1 << 6) (0x40) audio slin (16 bit Signed Linear PCM)

CLI> core show codecs

Why don’t you allow all codecs to see what it is trying to do , do another test call turn on some debug

3

I tried enabling all the codecs, no change. Interesting is that it seems to fail maybe 50% of the time (alignment of the planets?). I turned on core debug 5 and watched a failed call. Here is a snip of the debug:

[Dec 19 19:53:55] DEBUG[3355] chan_sip.c: SIP response 200 to standard invite
[Dec 19 19:53:55] DEBUG[3355] chan_sip.c: T38 state changed to 0 on channel SIP/2634-08356ce8
[Dec 19 19:53:55] DEBUG[3355] chan_sip.c: We’re settling with these formats: 0x4 (ulaw)
[Dec 19 19:53:55] DEBUG[3355] chan_sip.c: We have an owner, now see if we need to change this call
[Dec 19 19:53:55] DEBUG[3355] chan_sip.c: Updating call counter for outgoing call
[Dec 19 19:53:55] DEBUG[3355] chan_sip.c: build_route: Contact hop: sip:2634@10.10.10.85:5060
[Dec 19 19:53:55] DEBUG[3503] devicestate.c: Notification of state change to be queued on device/channel SIP/2634-08356ce8
[Dec 19 19:53:55] DEBUG[3332] devicestate.c: No provider found, checking channel drivers for SIP - 2634
[Dec 19 19:53:55] DEBUG[3332] chan_sip.c: Checking device state for peer 2634
[Dec 19 19:53:55] VERBOSE[3503] logger.c: – SIP/2634-08356ce8 answered Zap/1-1
[Dec 19 19:53:55] DEBUG[3503] rtp.c: Channel ‘Zap/1-1’ has no RTP, not doing anything
[Dec 19 19:53:55] DEBUG[3503] chan_zap.c: Requested indication -1 on channel Zap/1-1
[Dec 19 19:53:55] DEBUG[3503] channel.c: Set channel SIP/2634-08356ce8 to write format ulaw
[Dec 19 19:53:55] DEBUG[3332] devicestate.c: Changing state for SIP/2634 - state 1 (Not in use)
[Dec 19 19:53:55] DEBUG[3510] app_queue.c: Device ‘SIP/2634’ changed to state ‘1’ (Not in use) but we don’t care because they’re not a member of any queue.

**** OUTPUTS MAYBE 20 OF THE NEXT LINE ****
[Dec 19 19:53:55] WARNING[3503] chan_sip.c: Asked to transmit frame type 64, while native formats is 0x4 (ulaw)(4) read/write = 0x4 (ulaw)(4)/0x4 (ulaw)(4)
*** THEN CONTINUES ***

[Dec 19 19:53:55] DEBUG[3503] channel.c: Internal timing is disabled (option_internal_timing=0 chan->timingfd=67)
[Dec 19 19:53:55] DEBUG[3503] channel.c: Generator got voice, switching to phase locked mode
[Dec 19 19:53:55] DEBUG[3503] channel.c: Scheduling timer at 0 sample intervals
[Dec 19 19:53:55] DEBUG[3503] channel.c: Internal timing is disabled (option_internal_timing=0 chan->timingfd=67)
[Dec 19 19:53:55] DEBUG[3503] channel.c: Internal timing is disabled (option_internal_timing=0 chan->timingfd=67)

**** REPEATS THE FOLLOWING WHILE THE CALL IS STILL ACTIVE
[Dec 19 19:53:55] WARNING[3503] chan_sip.c: Asked to transmit frame type 64, while native formats is 0x4 (ulaw)(4) read/write = 0x4 (ulaw)(4)/0x4 (ulaw)(4)
[Dec 19 19:53:55] DEBUG[3503] channel.c: Internal timing is disabled (option_internal_timing=0 chan->timingfd=67)

I’m curious about this message “Internal timing is disabled”. It floods it quite a bit throughout the log, even with normally working calls. I thought Asterisk used the Zaptel card for timing if one is present, so it would make sense it wouldn’t be trying to use internal software timing. Not sure if that is what this message means or not though.

4

This isn’t really resolved, but downgrading to the latest 1.2 release eliminated the issue. Seems like a 1.4 problem.