MBG and SIP

[Mattmayn]

I am trying to get a SIP device to connect to MBG 7.1 and I cannot get it to register. I can get the device to register will I tell it go straight to the 3300 but not externally. I run the TNA and it shows 5060 open, but when I use the Diagnostics/SIP connectivity test on the MBG I get rport missing from Via header - cannot test. What does that mean?

[dilkie]

MBG running in Server-Gateway mode or in a DMZ? If the latter, does the DMZ have a SIP-aware ALG running? (it shouldn't).

You've configured your SIP device with the same set-side username and password as your've done on MBG? It's pointing to the right IP?

Try a register and then take a look in the "tug" logs, /var/log/tug.log, these will show how MBG is processing the registration request. You might be able to make sense of it.

[Navarre]

but when I use the Diagnostics/SIP connectivity test on the MBG I get rport missing from Via header - cannot test. What does that mean?

It means that the MCD is old enough that it cannot test for port mapping problems, but it is responding so you don't have a connectivity problem.

What settings did you configure in the Devices tab for this SIP device?

[Mattmayn]

The MBG is in Server-Gateway mode and yes the user info matches.

The tug logs look like a timeout is occurring.

I programmed the set-side and ICP-side user info, gave it a description, checked the enabled box and chose my local controller as the configure ICP. Everything else is "Use master setting." Is this what you are asking for?

[Navarre]

The tug logs look like a timeout is occurring.

On which side? Is the device registering with MBG, and then the timeout is on the MCD side, or is the timeout on the device-side? You can cut and paste a log snippet...

Was product support not helpful?

[brentond]

Did you ever get this sorted? I am having a very similar issue at the moment.

MBG is server gateway, no firewall in place. MBG is registering with provider, and everything appears to be working correctly. However there is a timeout between the MBG and the MCD. MCD keeps dropping the SIP link due to an options timeout, but a packet trace shows MBG requesting and receiving options from the provider. Incoming call is picked up by the MBG, but does appear to pass onto the MCD.

[dilkie]

does a packet trace show the options working between mcd and mbg? That's where it sounds like your problem is, mbg thinks mcd is down.

[brentond]

I've completed some further tracing and this is what I've found:

MCD sends option request. MBG receives option request and forwards to SIP trunk provider. SIP trunk sends response which is received by MBG. MBG doesn't forward onto MCD.

MBG sends it's own option request periodically to the MCD and this transaction completes. MBG reports that the SIP trunk is up both on the Trunk-side and Icp-side.

I can't see MBG trying to send the response to the MCD out on any interface, so it appears that it is dropping this response.

I have checked routing rule as i believe this is where the problem lies. I only have one entry in which is * request forward to MCD.

Any other suggestions?

[Navarre]

I'd have to see the trace myself.

Any chance the response from the provider has an incorrect hostname, port, etc? Any complaint in the tug.log at the moment the response is not forwarded on?

[brentond]

Provider rebuilt there end and all is up and running - nothing wrong with MBG at all 

[Navarre]

Provider rebuilt there end and all is up and running - nothing wrong with MBG at all 

Yeah, pretty common. MBG is in the middle so it's often blamed for everything.