[Home]

Summary:ASTERISK-18450: Should there be transcoding after attended transfer
Reporter:call (call)Labels:
Date Opened:2011-09-07 10:03:09Date Closed:2011-11-08 10:06:04.000-0600
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_sip/CodecHandling
Versions:1.8.6.0 Frequency of
Occurrence
Related
Issues:
Environment:CentOS - 5.6, Asterisk-1.6.2.20Attachments:
Description:For example ,we have 3 sip peers 1105, 1102 and 1107.
1105 supports alaw only, 1102 and 1107 - g729 only.

1105 calls 1102 and talks to him (alaw to g729 transcode).
sip show channels:
10.210.12.104 1102 221acda640e4502 0x100 (g729) No Tx: ACK
10.210.12.254 1105 39c1bec2-df881e 0x8 (alaw) No Rx: ACK

Then 1102 presses # to do an asterisk attended feature transfer and dials 1107. Then talks to him using g729.
sip show channels
192.168.1.130 1107 2381c9117db5b81 0x100 (g729) No Tx: ACK
10.210.12.104 1102 221acda640e4502 0x100 (g729) No Tx: ACK
10.210.12.254 1105 39c1bec2-df881e 0x8 (alaw) No Rx: ACK

1102 hangs up. 1105 and 1107 are connected. 1107 can hear 1105, but 1105 hears silence.
And we [Feb 17 12:02:21] WARNING[18867]: chan_sip.c:5342 sip_write: Asked to transmit frame type 64, while native formats is 0x8 (alaw)(8) read/write = 0x40 (slin)(64)/0x8 (alaw)(8)
[Feb 17 12:02:21] WARNING[18867]: chan_sip.c:5342 sip_write: Asked to transmit frame type 64, while native formats is 0x8 (alaw)(8) read/write = 0x40 (slin)(64)/0x8 (alaw)(8) get warnings in asterisk console.
Comments:By: Leif Madsen (lmadsen) 2011-09-08 11:45:24.473-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions.  After testing with Asterisk 1.8, if you find this problem has not been resolved, please open a new issue against Asterisk 1.8.

Can you reproduce this on Asterisk 1.8? The version you've reported against is no longer receiving maintenance support.
By: call (call) 2011-09-12 14:04:37.731-0500

Yes. 1.8 - the same thing! In this case, if you press on the phone 1107 - the problem disappears (in both versions 1.6 and 1.8!)
By: Matt Jordan (mjordan) 2011-11-08 10:05:02.968-0600

I've been unable to reproduce this issue in Asterisk 1.8.  Using a similar setup to yours, I had peers 7001 (g729), 7002 (g729), and 7004 (ulaw).  7004 initially dials 7001:

Peer             User/ANR         Call ID          Format           Hold     Last Message    Expiry     Peer      
x.x.x.x     7001             1b2bf95a0c504e6  0x100 (g729)     No       Tx: ACK                    7001      
x.x.x.x      7004             659c8a72-36762c  0x4 (ulaw)       No       Rx: ACK                    7004      
2 active SIP dialogs

7001 then initiates an attended transfer to 7002.  When MOH is being played and before 7001 has hung up, we have the following:

Peer             User/ANR         Call ID          Format           Hold     Last Message    Expiry     Peer      
x.x.x.x      7004             de4bc00c-2eead8  0x4 (ulaw)       No       Rx: ACK                    7004      
x.x.x.x     7001             65ed171172d3ab5  0x100 (g729)     No       Rx: ACK                    7001      
x.x.x.x     7002             52bb602b0c1c3b7  0x100 (g729)     Yes      Rx: ACK                    7002      
3 active SIP dialogs

Finally when 7001 hangs up and 7002 and 7004 are connected, transcoding occurs without any issues and both 7002 / 7004 can speak and listen to each other.  No warnings are displayed in the Asterisk CLI.

Peer             User/ANR         Call ID          Format           Hold     Last Message    Expiry     Peer      
x.x.x.x     7002             155efcf5160f1b9  0x100 (g729)     No       Rx: ACK                    7002      
x.x.x.x      7004             659c8a72-36762c  0x4 (ulaw)       No       Tx: ACK                    7004      
2 active SIP dialogs

Please ensure the following:
1. Using DEBUG logs, verify that you have transcoding paths between alaw to g729 and g729 to alaw.  I doubt that you would have an issue with this, but you should see this logged when Asterisk first starts up.
2. Verify that you have sufficient licenses to allow for both phones operating simultaneously with g729.

This issue will be closed as we cannot reproduce the bug.  If you are able to reproduce this in 1.8, please reopen and attach DEBUG logs illustrating it.
By: Matt Jordan (mjordan) 2011-11-08 10:06:04.887-0600

Unable to reproduce in 1.8 branch.  Used g729 with sufficient licenses and was able to transcode successfully during attended transfer.  If issue reporter can reproduce in 1.8 and attach logs, issue can be reopened.