Who would ever have thought I would have more issues with the bloody SIP trunk between CME and iiNet?

My CME has been offline for a good 6 months because I had unrelated IOS issues and got lazy fixing the proper config.

Today I dusted off my CME config for SCCP with a SIP trunk and got everything running smoothly. Inbound calls worked perfectly, 2 way audio, happy days. However outbound calls weren’t working. The phone would simply sit trying to call, no ringing tone, but after a minute or two I would get something similar to a fast busy.

After debugging with debug ccsip messages I soon found the reason why outbound wasn’t working. The way the SIP registration process works is inbound calls are determined by CME’s registration status. If you issue a show sip-ua reg stat it will show you if the SIP trunk is registered or not. If it is, great, inbound *should* work. However outbound is slightly different. Upon each call CME issues a INVITE which should acknowledged by a 100 Trying from the SIP provider. The provider will then issue SIP/2.0 401 Unauthorized as a challenge to authenticate in which you must ACK and INVITE again. This second invite will contain the response to the challenge. After you send the INVITE there should be another 100 Trying and then something like 183 Session Progress to say that everything is now working.

My problem was that after my INVITE with the challenge response I would never receive Trying, so CME would spam INVITE over and over again and then eventually time out.

In the middle of the ccsip messages debug is info about RTP and codecs. As it’s running over WAN I’m running G729 and had originally set the codec as g729br8. br8 is an annex B edition with built in VAD (which doesn’t sound too bad). In the debug i noticed: a=fmtp:18 annexb=yes. I figured by stating it there that it might have supported it, but I decided to try g729r8 anyway. As soon as I did this I started receiving the proper 100 and 183. Rock and roll.

SO YOU WOULD THINK IT WAS ALL OVER RIGHT?!?

No.

I then tested to make sure everything was good, inbound and outbound call flows. Now outbound was good, but whenever I tried calling in the call would not ring and hit straight through to iiNet’s voicemail. So I did another debug and now it showed: SIP/2.0 488 Not Acceptable Media. That’s weird right, because I was just using r8 as outbound? No worries, so I tried adding br8 as the second preference codec. Now when I tried to call out I received a message from iiNet saying that “I could not dial out at this time”

So I swapped things back and forwarded a few times and the conclusion I came to was I could only make outbound calls using r8 and receive inbound calls using br8. After messing with dial peers for most of the night with intermittent success I got frustrated with it and just changed everything over to g711alaw. No love on the oubound calls again. g711ulaw however seemd to work perfectly in all scenarios.

I’m so over getting this to work that I can’t be bothered at this stage to find out why 729 would only work in certain directions or when alaw doesn’t when in both situations iiNet say they support both. Maybe something for another day.