I thought I h dseen on here that mybuddy was only offering uLaw. If you have a call trace from sipx, you could verify exactly what mybuddy was offering.If it is not offering aLaw as a codec choice, that would explain a lot. I don't however know if mybuddy is the problem. I would imagine that would need to be looked at, and a jira started (if there is not one already) to allow the admin to specify the codec(s) used by mybuddy when making offers, though this problem is perhaps a little more unique to your itsp, so it probably bears some discussion.
On Tue, May 31, 2011 at 7:05 AM, Irena Dolovčak <[email protected]> wrote: > Hi, > > we have a problem when it comes to making a call via mybuddy. what we are > trying to do is to establish a call between two cell phones through sipxecs. > this should be accomplished through this command in mybuddy: > 'call (cell-number-1) (cell-number-2)', where the first number is the phone > that will be called, and the second number is the phone that should make the > call. as soon as this command is entered in mybuddy, sipxecs tries to make > two calls. first call should go to the caller (second number), and the > second call should go to the callee (first number). > > the problem arises when the first call is made (to the caller). for some > reason, sipxecs always uses PCMU as codec. since our ITSP doesn't support > PCMU, the call doesn't go through (or so that's what our ITSP says is the > problem). now, we have tried making modifications in sip trunking service by > putting PCMA on the first place, thus making it the preferred choice. it > didn't work, which is surprising because our ITSP uses PCMA. then we tried > to remove the PCMU. The result was even worse, because sipxecs didn't even > send the invite from its services to the ITSP's server. we also tried to > delete all default codecs from the sip trunking service, which should enable > all codecs (it should negotiate with the ISTP for the codec), but it again > used PCMU, although our ISTP clearly doesn't support it. > > in the end, we have tried removing the PCMU from the 'media services' > service. it had absolutely no effect, it still used PCMU. > > this problem arises only when we make calls through mybuddy. normal calls > use PCMA without any problem. also, when we used other ITSPs, the call > through mybuddy goes normally and everything is fine (it uses PCMU, but the > international ITSP supports it). the second call (to the callee) was made > through the 'problematic' ITSP, but this time the call was made with PCMA, > hence everything is fine. > > it seems that only the first call that is made through sip trunk (by > mybuddy) always uses PCMU, but the second uses codecs in the order of their > priority. > > does anybody knows how t fix this problem? > > > p.s. > we have also tried making calls between internal extension and a cell phone. > the idea is to find out will the second call (to the callee) have the same > problem, since the first call doesn't go through sip trunk. the problem was > identical. the first call (to the caller) didn't use sip trunk, and > everything was fine until the second call was made (to the cell phone). > since it went through the trunk, the problem repeated.... > > Regards, > -- > Irena Dolovčak > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.326.5325 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Contract Customers: http://support.myitdepartment.net Blog: http://blog.myitdepartment.net Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
