andrewgroup Posted January 7, 2008 Report Share Posted January 7, 2008 A new ITSP says we must use G711U.. They say we are trying 711A first with Wireshark we see the following in the SDP initial packets... we have set the codec options to be 0 only and 0 8 as described as the defaults in the manual, still this descriptor shows as follows.. Media Description, name and address (m): audio 63720 RTP/AVP 8 0 18 2 3 101 the first RTP stream listed is Media Format: ITU-T G.711 PCMA the second is Media Format: ITU-T G.711 PCMU can this be true despite setting 0 in the codec field for the trunl? The problem is we get the following reply Status-Line: SIP/2.0 400 Bad Request this comes immediately after after what appears to be a normally looking request. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 8, 2008 Report Share Posted January 8, 2008 Status-Line: SIP/2.0 400 Bad Request I assume that response comes back to a SDP offer in an outgoing INVITE? If that is the case, the 400 Bad Request response is just an indication that whatever equipment they are using, they don't understand SIP and SDP properly yet... What the PBX says is: "Send me A-law, U-law, G729, G.726 or GSM" and "My first preference would be A-law, my second u-law" and so on. If the PBX would only allow A-law then it would not send the other codecs, right? The correct behavior would be to pick the codec they like and send the answer back to the PBX. Anyway, what you can do it set 0 in the trunk codec list or even better, in the global codec list of the PBX (under the ports section). Then the PBX will only offer u-law, and that provider gets his way! Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 8, 2008 Author Report Share Posted January 8, 2008 The ITSP is using a Cisco BTS10200 Class 5 softswitch. It appears as if they use Ulaw globally on SIP trunks and based upon the packet captures that I have done, altering the codec entries doesn't change the SIP/SDP invite packets. I've compared the packets before and after the codec preference changes and the packets appear the same. If you are a gluten for punishment here is the packet capture. I'll note the area in question. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 8, 2008 Report Share Posted January 8, 2008 The ITSP is using a Cisco BTS10200 Class 5 softswitch. It is difficult for a large organization to offer only excellent products... It appears as if they use Ulaw globally on SIP trunks and based upon the packet captures that I have done, altering the codec entries doesn't change the SIP/SDP invite packets. I've compared the packets before and after the codec preference changes and the packets appear the same. If you are a gluten for punishment here is the packet capture. I'll note the area in question. I am sure there is a configuration that tells the switch that anything except 0 is a bad codec. Probably there is a IOS command somewhere that tells the switch to reject any packet that is not only the specified codec. Unfortunately, I am not a CCSSE so I can't tell you what command is neccessary to make the device SIP-compatible again... Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 9, 2008 Author Report Share Posted January 9, 2008 Progress yes solution no. I did discover the CODEC entries in the global settings overide whatever settings you have in the domain trunk settings. Duh... So I do now have the SDP offering Ulaw first... I read the Cisco BTS10200 manual and found an update for 4.5.1 release allowing SIP trunks to independently support U and A law. Prior to that release only Ulaw appears to be supported. Working with the ITSP, we are discovering perhaps some settings that are wrong on the CISCO. The problem with Codec was our fault as Global settings for a Codec override Domain Settings. So I assume you should have no Codec Entries in Global. The ITSP is having a Cisco BTS10200 problem with REFER statements and Cisco has askcnowledge the problem. Hopefully a patch is forthcoming. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.