G729 trunk question - attended transfers always fail

Hi guys

We have a G729 trunk that sends us incoming calls, and takes our outgoing calls.

Our asterisk server does NOT have the Digium G729 licenses loaded.

We have ATCOM-AT-610-PR phones that list G729 as a supported codec.

Incoming calls over the G729 SIP trunk work fine, as does outgoing calls over the G729 SIP trunk.

We were previously on a Xorcom that handled incoming / outgoing calls via DAHDI.

When we still had the Xorcom, attended transfers of incoming calls worked fine.

However, attended transfers once we got the G729 trunk (and dropped the Xorcom / DAHDI) have stopped working completely. An incoming caller will be transferred to a target party, the receptionist will go on hook with her set. Then the calling party cannot hear the called party.

These error messages then scroll up over the CLI the moment the receptionist goes on hook and the calling party is transferred to the target party:

WARNING[20391]: chan_sip.c:5365 sip_write: Asked to transmit frame type 64, while native formats is 0x100 (g729)(256) read/write = 0x40 (slin)(64)/0x100 (g729)(256)

My questions:

  1. Does the above mean that we need to get a G729 license?

  2. Since we do NOT have a G729 license, how is ANY calls possible at all? Straight G729 -> G729 pass through always? Why does a SIP show channels show ulaw is being used:

poloasterisk*CLI> sip show channels

Peer             User/ANR    Call ID          Format           Hold     Last
Message    Expiry

172.23.4.20      (None)      23951607820475-  0x0 (nothing)    No       Rx:
REGISTER
172.23.4.19      (None)      10282387932037-  0x0 (nothing)    No       Rx:
REGISTER
172.23.4.18      3010        185f1e9a2130ed2  0x40 (slin)      No
Init: INVITE
172.23.4.29      3003        78a2660061daf68  0x4 (ulaw)       No       Tx:
ACK
172.23.4.23      3005        13a7b7964e3f86e  0x4 (ulaw)       No       Tx:
ACK
41.21.120.65     2783481204  2cdbd06f622bc13  0x100 (g729)     No       Tx:
ACK
41.21.120.65     2778486869  50c66b077d0d3ff  0x100 (g729)     No
Init: INVITE
172.23.4.12      (None)      133822339542-32  0x0 (nothing)    No       Rx:
REGISTER
172.23.4.29      (None)      229952441326659  0x0 (nothing)    No       Rx:
REGISTER
172.23.4.23      (None)      306961754325698  0x0 (nothing)    No       Rx:
REGISTER
172.23.4.27      (None)      64363264211946-  0x0 (nothing)    No       Rx:
REGISTER
172.23.4.25      (None)      18894424214103-  0x0 (nothing)    No       Rx:
REGISTER
172.23.4.34      (None)      159832421925288  0x0 (nothing)    No       Rx:
REGISTER
172.23.4.26      3020        184bd5237accced  0x4 (ulaw)       No       Tx:
ACK
172.23.4.27      3013        2d894e07618468b  0x4 (ulaw)       No       Tx:
ACK
10.17.121.66     2782337764  4e48368169039c9  0x100 (g729)     No
Init: INVITE
172.23.4.22      (None)      6452166322474-1  0x0 (nothing)    No       Rx:
REGISTER
172.23.4.16      (None)      261221145623711  0x0 (nothing)    No       Rx:
REGISTER
172.23.4.30      (None)      2483197138820-3  0x0 (nothing)    No       Rx:
REGISTER
172.23.4.24      (None)      65013486268-283  0x0 (nothing)    No       Rx:
REGISTER
172.23.4.25      3018        5fcf11465b5ec36  0x4 (ulaw)       No       Tx:
ACK
172.23.4.37      (None)      28995138666527-  0x0 (nothing)    No       Rx:
REGISTER
172.23.4.21      3007        42250c7a536bd93  0x4 (ulaw)       No       Tx:
ACK
23 active SIP dialogs

poloasterisk*CLI>

if our Asterisk server cannot do G729 -> ulaw transcoding, since it does not have a G729 license loaded? Shouldn’t the entire list then only show G729?

Thank you very much.

Stefan

There are two ways of doing attended transfers on SIP, the SIP way and the features.conf way. The results may differ.

If you want to ensure that only G.729 is used, you need to make sure that only G.729 is allowed for all SIP devices (also make sure any originate explicitly specifies G.729). Without your sip.conf, one cannot tell what you are actually allowing.

You will probably need to provide SIP traces to be sure of exactly what is being negotiated.

Generally, assuming that you have g729 voice files, etc., Asterisk would want to use slin as a codec if it wanted to play a tone in band, or if you use originate/call files, without specifying a codec. All tones are synthesized in slin format, although some beeps are done as sound files.

Hi David

Thank you very much for replying.

My sip.conf as regards the above:

[sip-out-provider]
type=peer
host=xxx.xxx.xxx.xxx
defaultuser=12345
fromuser=12345
authname=12345
canreinvite=yes
insecure=port,invite
nat=yes
qualify=no
context=from-sip-out-provider
disallow=all
allow=g729
session-timers=accept

[3001]
type=peer
user=3001
secret=mysecret
host=dynamic
disallow=all
allow=g729
context=local
call-limit=1
limitonpeers=yes
pickupgoup=1
callgroup=1

We do have MOH on that channel as you wait for the transfer, but we use gsm for that.

We use the “features.conf” way:

.
.
.
[featuremap]
atxfer => #
.
.
.

Does the above shed any light?

Thanks again.

The codecs on the 3xxx devices are what matter. If the channel is G.729 only, music on hold will need to be G.729 format.

Hi David

Thanks again for your suggestion. I set all my entries in sip.conf to disallow=all, allow=g729.

I also installed the G729 sound pack.

Once I did this the error disappeared form the CLI and I noted that Asterisk started using the G729 audio when playing MOH for an intended transfer in progress.

I can now do attended transfers again, and the calling party can correctly hear the transferred-to party after the receptionist goes on hook with her set and the two parties are connected.

Thank you VERY much for your kind assistance.

Take care.

Stefan