CUBE need help with SDP header manipulation

[mrvoipstuff]

have setup direct routing recently with CUBE .. My ITSP (in Australia) appears to accept alaw as 1st preference followed only by ulaw as 2nd choice before sending 180 ringing back ... What I noticed is if i call an external number from Jabber registered to on-prem CUCM then it always works as it sends 711alaw as per audio codec preference list ...In Teams phone system I can't specify codec order so I added the below on the SIP-profile on my ITSP facing outgoing dial peer.

request INVITE sdp-header Audio-Media modify "RTP/AVP 0 8" "RTP/AVP 8 0"

this works for the m=audio port# RTP/AVP 0 8 101 19 and changes it to RTP/AVP 8 0 101 19

but the next 2 line remains unchanged which still have PCMU first followed by PCMA as below

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

.. How can I flip the order so a=rtpmap:8 PCMA/8000 is listed first followed by a=rtpmap:0 PCMU/8000 in next line ??? can't work which SDP-attribute am I modifying to achieve this ??

For ref - when calling from Jabber (working) - outgoing invite from CUBE to ITSP is like this

m=audio 44936 RTP/AVP 8 0 101 19

c=IN IP4 x.x.x.x

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

When calling from Teams invite from CUBE to ITSP is like below

m=audio 42494 RTP/AVP 8 0 101 19

c=IN IP4 x.x.x.x

a=rtpmap:0 PCMU/8000   <== this here is what ITSP having problem with. they want the line below (a=rtpmap:8 PCMA/8000) first.

a=rtpmap:8 PCMA/8000

appreciate any feedback ...

[b.winter]

I have never heard, that a provider has a problem with an incorrect order of codecs. Either he supports the codecs or not.
Wouldn't it be easier to just announce a-law to your provider?
Or use delayed-offer for outgoing calls to the provider, so that the provider announces his codec list first in the 200 OK?

[mrvoipstuff]

When I call some of random landlines reported as not working using Jabber which has ALAW preferred then it works .. If I call using Teams client connecting into the same CUBE/ITSP where it's sending ULAW as preferred codec it does not work. I don't get 180 RINGING back instead a RE-INVITE from the far end. I compared the INVITEs sent from CUBE to ITSP for both scenarios (Jabber & Teams) and the only difference I could see was the codec preference order. 

Apologies my wording is misleading - ITSP is processing calls fine for majority of destinations where ULAW is preferred. But there these random landlines when dialled from Teams would not work. Dialling them from Jabber works every time. The only difference between the two SIPs is the codec preference order which is why I wanted to see if possible to swap the order of two lines below ?? appreciate any input on sdp-header manipulation which is what i need ... 

From

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

To

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

I managed to change to RTP/AVP 8 0 101 19 but cannot work out the above ...  

Killing ULAW is not an option because so many system admins leave PABX just have ULAW - not even ALAW in Aus. have personally experienced couple..... so don't want calls to such places fail.  

[b.winter]

Have you checked with the ITSP?
If I don't get an answer from them, I'll ask them. I wouldn't start searching on my end, if the ITSP is not responding.
Without info from them, everything you do on CUBE is just guessing and mind-reading.

[mrvoipstuff]

I haven't yet but I know their argument would be if calls to same number are OK when using another PABX (CUCM) behind CUBE but are not OK when using Teams client that sits behind the same CUBE i.e. Direct Routing then it's our configuration issue. 

[Roger Kallberg]

Can you not change the order of the codecs used for inbound calls in your SBC that is used for the direct routing integration by setting up another codec list, that has alaw as the first listed codec, and then set that to be used for the dial peer(s) from and potentially to Teams?

[mrvoipstuff]

Within Teams phone system we can't change the codec preference so what I receive on CUBE on its incoming Teams Dial-peer is like below 

m=audio 49700 RTP/SAVP 104 9 103 111 18 0 8 97 101 13 118

Are you saying to use a voice class codec here on the Teams incoming DP to prioritize A-law here? I haven't tested but doubt that will work ... I will paste my SIP ladder diagram and logs shortly. 

[Roger Kallberg]

If you use delayed offer for the calls from Teams it would be the response from your SBC that sets the preference of the codec used. With that the codec list on the inbound dial peer would have relevance.

[mrvoipstuff]

Ah ok - good to know. using early offer though but if it doesn't work guess I will try with delayed offer.  

[mrvoipstuff]

I've attached the SIP trace... Weird twist I got a call back from the number I was trying to reach (+61746712077) ... they say it's just missed call & no actual phone ringing on their end. The odd thing in this flow is why ITSP sending re-invite. 

Teams => CUBE Leg Call-ID: b7d681c1d4a1505b81f5b0517ea527c5

CUBE => ITSP Leg Call-ID: F35399C5-E05C11EE-9557A69F-3BB85EF

Number Called: 746712077

[b.winter]

"...Weird twist I got a call back from the number I was trying to reach (+61746712077) ... they say it's just missed call & no actual phone ringing on their end." --> One point more, why to ask the ITSP.

[mrvoipstuff]

agreed - have raised a ticket with ITSP. will post update here. 

[Scott Leport]

When you say it doesn't work, can you be more specific? Have you taken and reviewed any ccsip debugs? 

I am not convinced this is your issue. From my experience, the ITSP supports the codec or they don't. However, it might be worth ensuring that you use a different voice class codec configuration on your dial-peers between CUBE and Teams than you have configured on the dial-peers between CUBE and CUCM.

[aspo73]

Can I ask if this is from TPG? I am facing a similar issue but have no SBC.

[mrvoipstuff]

sure it's Telstra.