'morning everybody, Here is the setup: 5126800422 called 3035 (3035 is a Cisco 7960). The call is g729. 3035 presses 'Conference' on her phone and calls 8327549222. This call is ulaw. (65.72.107.2 is our Cisco 7206 SIP->PRI gateway.) asterisk*CLI> sip show channels Peer User/ANR Call ID Seq (Tx/Rx) Format 65.72.107.2 8327549222 1758081f67e 00102/00000 ulaw 10.0.0.48 3035 0008a3d2-05 00101/00102 ulaw 10.0.0.48 3035 0feb1c11386 00103/00101 g729 65.72.107.2 5126800422 28D20837-69 00103/00101 g729 4 active SIP channel(s) 5126800422 is still on hold while 3035 talks with 8327549222. 3035 now presses 'Join' on her phone and this happens: asterisk*CLI> sip show channels Peer User/ANR Call ID Seq (Tx/Rx) Format 65.72.107.2 8327549222 1758081f67e 00103/00000 ulaw 10.0.0.48 3035 0008a3d2-05 00102/00102 ulaw 10.0.0.48 3035 0feb1c11386 00103/00102 ulaw 65.72.107.2 5126800422 28D20837-69 00104/00101 ulaw 4 active SIP channel(s) Suddenly, 5126800422's legs are ulaw. What is interesting is that BOTH legs were changed. The leg from Cell->7206 was changed AND the leg from 7206->Asterisk->3035 was changed. Could this be the 7960 that changed the codec? or was it asterisk? Any thoughts? Thanks, Matthew
> Suddenly, 5126800422's legs are ulaw. What is interesting is that BOTH legs > were changed. The leg from Cell->7206 was changed AND the leg from > 7206->Asterisk->3035 was changed.As previously discussed right here on this fancy list <G>, the Cisco 7940/7960 will not 3-way conference when using a low-bandwidth codec. When you attempt to do so, they will attempt to reinvite the original call to G.711, and if the SIP server allows that it will proceed. If the server does not allow that (as ours doesn't), the conference will fail. In fact, in our configuration, when the user presses the Conference key and tries to dial the 3rd party, it will fail because the phone will only allow that call be completed using G.711, and our SIP peers are not allowed to use anything but G.729. As I mentioned to another poster a few days ago, Asterisk is not even aware that this conference is happening (since it just sees the SIP peer/user handling two simultaneous calls), so it cannot be held responsible for making the codec change (nor can it do anything to affect it).