As a followup for any who has the same problem, and searches the archives (don't you love finding the problem you have in the archive, but no-one followed it up?), check the following references:

http://lists.digium.com/pipermail/asterisk-dev/2005-April/011291.html

and the status of the updated code:

http://bugs.digium.com/bug_view_page.php?bug_id=0003346

Alistair Cunningham,
Integrics Ltd,
+44 (0)7870 699 479
http://integrics.com/


Alistair Cunningham wrote:
On more testing, I conclude that Asterisk isn't being very clever about codec negotiation.

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?

_______________________________________________
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

Reply via email to