[asterisk-dev] RTP Native Bridge Codec Change Handling - Appears to compare immediately after setting equal

[Dave WOOLLEY]

We are, unfortunately, locked into an old version of Asterisk, and modelling this on a current version may be difficult, but we noticed that when the response to a native bridge re-invite changed the codecs, Asterisk didn't seem to react, even though the resulting codecs were incompatible with the other side.

On looking through the code (rtp.c / rtp_engine.c), it looks like the basic RTP native  bridge loop has a structure like this (and this has survived several reworks between 1.6.1 and 11, although I have yet to find the equivalent code in trunk):

<<<<
If codecs or addresses have changed
Do actions (which may trigger new re-invites)
Set old codecs and addresses to current ones.
endif

Wait for some frames and digest them,  possibly breaking out of the loop, but I'm not interested in that case.

Unconditionally set old codecs and addresses to current ones.
>>>>

To me this seems me to make it very difficult for a codec change to actually be detected, as when you unroll the loop, the unconditional set precedes the test for changes!

Am I reading the code correctly?   If so, could someone explain why it is doing this?





--
David Woolley
BTS Holdings Plc
Tel: +44 (0)20 8401 9000 Fax: +44 (0)20 8401 9100
http://www.bts.co.uk<http://www.bts.co.uk/>


BTS Holdings PLC - Registered office: BTS House, Manor Road, Wallington, SM6 0DD - Registered in England: 1517630
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130530/109c7025/attachment-0001.htm>