My understanding (possibly faulty) from experiments is this. If I have:
UA1 --> Asterisk --> UA2
and have disallow/allow entries in UA1's stanza in sip.conf, it seems that the first entry in the allow list is all that's used to choose the codec from UA1. Entries in UA2's stanza and SIP responses from UA2 are not used. If it turns out that UA2 can't support the codec that Asterisk chose for UA1, Asterisk attempts a translation. This occurs even if UA1 and UA2 have a supported codec in common which isn't the one Asterisk chose.
If my understanding is correct, this is very inefficient. Worse, if one of the codecs is one it doesn't understand, such as G.729 (without chan_g729a.so) or G.723.1, Asterisk drops the call, even though it could have done pass through.
Is my understanding correct? Is this a weakness in Asterisk? Am I missing something elementary?
-- Alistair Cunningham, Integrics Ltd, +44 (0)7870 699 479 http://integrics.com/
Alistair Cunningham wrote:
All,
I'm working on an Asterisk 1.0.7 system that is acting as a B2BUA SIP gateway. "canreinvite=no" is set in the global section of sip.conf, and it's important that it be there. I have
Cisco ---> Asterisk ---> Multiple destinations
Some destinations support both G711 and G729, but some only support G729, and some do not support G729.
On Cisco, I have:
voice class codec 3 codec preference 1 g711alaw codec preference 2 g711ulaw codec preference 3 g729r8
On Asterisk, I have (irrelevant parts snipped) in sip.conf:
[g729only] type = friend host = 192.168.1.1 disallow = all allow = g729
[g711only] type = friend host = 192.168.1.2 disallow = all allow = alaw allow = ulaw
[cisco] type = friend host = 10.1.1.1 disallow = all allow = alaw allow = ulaw allow = g729
I've also tried without the disallow and allows in [cisco], and with them in [general].
When I call from the Cisco to g711only via Asterisk, the call works. When I call from the Cisco to g729only via Asterisk, I get:
Apr 16 15:56:41 NOTICE[11297]: Unable to find a path from g729 to alaw Apr 16 15:56:41 NOTICE[11297]: Unable to find a path from alaw to g729
In a SIP trace, in the INVITE from Cisco to Asterisk, I see:
a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16.
In the INVITE from Asterisk to g729only:
a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -.
In the 200 OK from g729only:
a=rtpmap:18 G729/8000/1. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15.
When Asterisk gets this message, it replies to g729only with a ACK then a BYE, and sends a 403 Forbidden to the Cisco. At no point does Asterisk send any message to the Cisco suggesting that Alaw is not acceptable or that G729 is allowed.
My question to you, Asterisk-users, is why Asterisk drops the call when both sides have offered G729? It seems to think that the Cisco is Alaw only; this is the default codec on Cisco, but it is offering other codecs as well.
I've tried various settings. I can also make G729 work but G711 fail, but can't do both at the same time. I've also tried the following on Cisco:
voice class codec 2 codec preference 1 g729r8 codec preference 2 g729br8 codec preference 3 g723r63 codec preference 4 g723r53 codec preference 5 g723ar63 codec preference 6 g723ar53 codec preference 9 g711alaw codec preference 10 g711ulaw codec preference 11 gsmfr codec preference 12 gsmefr
With the dial-peer changed to use it, but this doesn't help either.
(Hostnames and IP addresses changed to protect the guilty, i.e. me)
_______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
