No audio after bridging SIP call from Queue to Member on some phones

Hi, I’m having an odd issue with bridging an external SIP call out of a Queue to a Member: if the Member resides on a Cisco endpoint, all is well; if the Member resides on a Grandstream, there’s no audio in either direction. Well, nearly, as …

exten => s,1,NoOp(announce-to-queue-member)
same  => n,Wait(0.5)
same  => n,Flite("Time in Queue: ${QEHOLDTIME} seconds.")
same  => n,MacroExit

… can be heard on both, Grandstream as well as Cisco endpoints.

I can call from the public network to the Grandstream’s DID number without issues, though. The issue seems to be between Queue() and Grandstream, but I cannot figure out what’s causing this. I tried switching the Grandstream’s connection to TCP (as the Ciscos are using TCP), forcing the Grandstream to use Asterisk as a Proxy, … no change.

The Asterisk VM lives behind NAT, the external SIP provider is configured with directmedia=no, as are the Cisco and Grandstream endpoints. (Generic sip.conf setting is “nonat”.)

I’m at loss where to look, since DID works, internal dialing works – so it does not seem to be RTP in general? –, and it doesn’t seem to be a codec issue either (alaw is being used).

FTR: this is on Asterisk 13.13.1-1usecallmanager2 (migration to 18 is on the ToDo list, though), using sip (not pjsip).

Hmm, well … actually … it was.

Looks like Asterisk negotiated alaw with our SIP provider, but out of

Capabilities: us - (alaw|ulaw), peer - audio=(ulaw|alaw)/video=(nothing)/text=(nothing), combined - (alaw|ulaw)

the Grandstream used ulaw (it’s first choice), whereas Asterisk bridged the alaw caller to it?

Asterisk at least states having choosen to use alaw for the call:

    -- Executing [h@ctx-sip-trunk:1] NoOp("SIP/sip-trunk-00014050", "ctx-sip-trunk: r: alaw w: alaw def: (alaw)") in new stack

Forcing Grandstream of offer alaw, then ulaw, enables audio from/to Caller from/to Member. (But why did Flite() work, if Asterisk choose to send the wrong codec to the Grandstream?)

Current ‘solution’ is to only allow ulaw from our SIP provider and the endpoints, but that’s preventing us to use e. g. G722 (as available on the endpoints) :frowning:

It’s difficult to be sure from log fragments, but I see no wrong codec. Asterisk negotiated both G.711 formats. The only questionable thing is why it used its configured preference over the that in the incoming offer, but it is only ever a preference.

RFC 3264, has a may clause for Asterisk’s behaviour on the A leg, so, though discouraged, it isn’t wrong:

Although the answerer MAY list the formats in their desired order of
preference, it is RECOMMENDED that unless there is a specific reason,
the answerer list formats in the same relative order they were
present in the offer. In other words, if a stream in the offer lists
audio codecs 8, 22 and 48, in that order, and the answerer only
supports codecs 8 and 48, it is RECOMMENDED that, if the answerer has
no reason to change it, the ordering of codecs in the answer be 8,
48, and not 48, 8. This helps assure that the same codec is used in
both directions.

A normal asterisk configuration would have no problem transcoding.

As you using unsupported software, things may have changed.

Well, at least others seem to have experienced similar issues with Asterisk 13 and GXP phones in the past.

“Unsupported” because of Asterisk “13.13.1” or because of “usecallmanager2” patches?

Looks like some things have changed post-13 in terms of codec negotiation, so I’ll move to a less outdated version for further testing.

Unsupported because of Asterisk 13 and chan_sip, although I overlooked the patches.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.