SIP Trunking

[bluewhite4]

Setting up SIP trunking using a MBG as the proxy.

Inbound call will come in.
The MBG will send the provider a 100 Trying.
The MBG will then send the invite to the 3300. (The DID is routed directly to voicemail pilot)
3300 will reply to the MBG with a 100 Trying.

Everything will wait, and then the provider will time-out and send a Cancel.

They say its timing out because they're not receiving the 180 Ringing. And indeed, the trace does not show a 180 ringing coming from the 3300 to the MBG or the MBG to the provider.

This is the same setup that I've used previously, with the same COS, and SIP config. What am I missing that the phones aren't sending the 180 Ringing? (The only thing I can think of is that this customer is running MCD 5.X instead of 6.X)

[martyn]

MCD version wont make a difference here, as the 100 trying, 180 ringing, etc is part of the SIP RFC standards, so versions of software wont be the cause.

You mention that the MBG is returning a 100 trying. Is this what the provider is seeing, or are you seeing it on the MBG?

If you run a tcpdump on the MBG and the 3300 what is seen on each? Also assuming that the voicemail pilot answers when it is called internally, and that the same happens with DID calls in to normal handsets as well?

[bluewhite4]

Correction, I'm seeing the MBG receive the 100 trying from the 3300. I'm seeing it via tcpdump trace on the MBG server.

I tried it tonight with a teleworker phone, and when I call the SIP DID, the teleworker will ring, and I can answer it, but I never get any audio.

Which led me to try test calling the voicemail HG from the Teleworker. I didn't get any audio. So I'm thinking that I've actually got bigger problems than I originally realized.

[martyn]

Is the teleworker handset registered to the same MBG as the SIP trunk is going through?

I wouldn't rule it out being the issue there. I'd be double checking it to an actual handset registered on the site, as I have seen some funny things happen with MBG when it hairpins a call.

[bluewhite4]

Yes the handset is registered to the same MBG as the trunks.

[127.0.0.1]

This is bigger than SIP if TW has issues on IC calls.  A couple of thoughts.


Is MBG part of MAS?
Does MAS host NP as well or are you using embedded?
If VM is not on same MSL as MBG, is the VM, regardless of type in the same subnet as eth0 on MBG?


Make sure the MBG blade network profile is set to server-gateway, and that the set-side IP and ICP-side IP are set properly.


If you didn't, when you do your tcpdump from MBG's MSL, use '-i any' to capture on both eth0 & eth1 at once.  Your trace will show the big picture.

[bluewhite4]

MBG is actually a vMBG, so its standalone.

Not in server-gateway, but in DMZ. I have confirmed that all ports are forwarded via the TNA tool.

[127.0.0.1]

Make sure the MBG blade network profile is set to server-gateway, and that the set-side IP and ICP-side IP are set properly.

^^^ What about this?  Server-only will set both ICP-side and set-side IP to the ICP.  Try overriding the set-side to the public IP. 

[bluewhite4]

Your right 127, I did ahve to put it in Custom mode, but reverse of how you said.

In order to get 2-way audio, I had to put the IP of the vMBG in the RTP ICP-side, and the external ip into the RTP Set-side.

So now I have two way audio between MiNet and sip phones through the MBG.

But still one-way with the SIP trunks.

[127.0.0.1]

OK good, so back to tcpdump then.  Get a trace and see where the RTP is streaming to/from.

[bluewhite4]

And actually I've got two-way audio now for the trunks as well.

[127.0.0.1]

Sweet!  It's BEER:30

[JasonTL]

I am having a similar issue. I have tried the suggestions above and continue to have one-way audio. I have two customer sites, two vMBG, and two SIP trunks to the same carrier. Both controllers, vMBG, and trunks are set up the same way. One works fine and one gets the one-way audio.

The originator hears 4 rings and then immediately a fast busy. The terminating end hears two rings, answers but cannot hear the caller speaking.

I can attach a wireshark capture if needed.

J

[martyn]

That sounds like a codec mismatch, but yes, a wireshark trace show that up. If you do a tcpdump on the controller and from the command line of the vMBG then that should explain the story.

[JasonTL]

I did get the one way audio corrected. I am now getting 2 way audio, but a disconnect after about 10 seconds.


J