NO Audio - SIP Trunk to T/Workers

[danramirez]

We have a 3300 with a SIP trunk. The Firewall does port forwarding 5060 to the 3300. Audio is OK from SIP Trunk to all IP users locally both ways.

Also, we have a MBG connected on the DMZ Port of the Firewall (MBG Server only mode). Audio is OK from Tworker users to all IP phone locally connected. We also have other IP Phones connected over VPNs and Audio is also good from TWorkers to IP Phone at remote locations. Tworker to Tworker OK as well.

The proble is: NO AUDIO When TWorkers receive/make calls over SIP Trunk on the 3300.

Any ideas why?? I'm not an expert on SIP Trunks so I don't know how the audio should behave when SIP trunks involved.

Regards,

Daniel

 

[IrwinMFletcher]

Check to make sure that the endpoints are actually streaming. If they are, then you know that the signaling path is ok, if not, then go from there...

 

[danramirez]

Irwin, I'm new to SIP.

What do you mean by endpoints streaming? How do I check that?

Teleworker phone rings but no audio when answered, also Tworker can dial out through the SIP trunk but no audio...

Regards,

 

[slapin]

It is so undetermined. Traversing firewalls and NATs can introduce whole bunch of side effects. Do you know how to capture traffic on MBG?
Enable SSH access, start any ssh client, putty for example. Log in as root with your admin password.
;This will print information about network interfaces
# ifconfig

;this will capture and display network packets with SIP signaling
# tcpdump -i ethN -X -s 1500 port 5060

N is your active interface
port is SIP port in use (it will catch TCP and UDP)

Pay attention to SDP portion of the messages.

 

[paterson]

I wonder if the SIP provider IP address needs to be put in the local networks form of the MSL.

_______________________________________________________________

If you did not take enough time to get it right the first time...

What makes you think that you have time to fix it?

 

[danramirez]

Slapin, I'll try capturing traffic on MBG and let you know what I get. Thanks for listing those commands.

Paterson, adding SIP Provider IP address as a local network makes a lot of sense, that's what I've done with the rest of local networks that connect to the main site over VPN. I'l give it a try and let you know.

Thanks guys, I'll keep you informed

 

[danramirez]

Paterson, I added SIP Provider IP address to the local networks and it made no diference.

Slapin, I entered:
tcpdump -i eth0 -X -s 1500 port 5060
and saw nothing on the screen after making a call over the sip trunk.

By the way, how do I stop that tcpdump?

Thanks again,

Daniel

 

[IrwinMFletcher]

Daniel, The firewall that you have facing the SIP SP (that you opened port 5060 on) should also show you the UDP data packets going through it for the audio. You need to check that to make sure that the audio is actually being sent.

It's a 'simple' matter of tracking things down. First you need to make sure that the signaling is getting through. You've done that since you can ring the TW set. Now you have to trace the path that the audio takes (which is different than the sip signaling) and verify that it can make it end to end. The easiest way I find to that out is to check the network interfaces of each of the key points in the path and verify that each is letting the data through. So start at one end, the SIP side is as good as any. Check that firewall and see what, if anything it's blocking. 99% of the time, it's a firewall/router issue.

 

[LoopyLou]

is the MBG both your SIP trunk proxy and teleworker server?

The single biggest problem with communications is the illusion that it has taken place.

 

[slapin]

LoopyLou, good catch. I assumed that, but could be different setup. Also a lot of SIP trunking providers use non-standard ports like 5070 and etc.

danramirez,

just press Ctrl+C to interrupt, which is valid for the most of Unix programs.

 

[danramirez]

NO, the MBG is only my teleworker server. SIP trunks connect to the 3300 directly through the firewall, I have forwarded port 5060 UDP from the Public IP Address to the 3300.

I don't have a SIP Proxy server in this configuration.

 

[LoopyLou]

Ok, so if I understand it the call comes in from the SIP provider via the firewall and can reach the 3300 ( since the SIP trunks work ). The 3300 then rings the teleworker but no audio on answer.

When the teleworker answers, the call is from the firewall to the MBG ( i.e RTP voice streams from the teleworker to the SIP trunk provider without involving the 3300 ). Could you have issues in the firewall that would prevent this streaming? The benefit of the proxy server on the MBG would be the SIP trunks would point to it and the teleworkers would work through it. Not an expert on firewalls if I am way off base here.

The single biggest problem with communications is the illusion that it has taken place.

 

[danramirez]

LoopyLou,

The situation here is exactly as you describe it. Let me ask one question to see if I can understand SIP and be able to trace RTP voice packets.

Once the call set up has been established, what route should the RTP packets take?

Option1: From the WAN (SIP Provider) interface of my firewall to the 3300, then from the 3300 to the DMZ of my firewall, and from the DMZ to the WAN (Teleworker). Remember MBG is at DMZ port of firewall as a server only.

Option2: From the WAN (SIP Provider) of my firewall to the DMZ, from the DMZ to the WAN (Teleworker).

Option3: From the WAN (Sip Provider) of my firewall to the WAN (Teleworker).

Option4: From whatever the IP of the SIP Provider is, to whatever the IP of the Teleworker set is.

Regards,

Daniel

 

[IrwinMFletcher]

I won't comment on the options as I don't want to get it wrong and confuse things. However, I will say that there is potentially a difference between what it SHOULD take and what it's TRYING to take.

It should take the path of least resistance, what it's trying to take is whatever is being signaled in the SIP negotiation.

If you really want to know what's going on you need to look at the signaling. It takes some effort to get/setup, but it's the simplest way to solve the problem once you have that information.

 

[danramirez]

Irwin,

How do I find out what path should be taken according to the SIP negotiation?

Ethereal I suppose...

The next question is, where do I have to put my sniffer in order to capture SIP negotiation? The WAN Port of my firewall?

Why is SIP so complicated?? Minet is a lot simpler, don't you think. Any way, what I have is a SIP Trunk and that's what have to work!!

Regards,

Daniel

 

[IrwinMFletcher]

Sniff on the SIP SP side of the firewall. Ethereal will parse the SIP SDP for you so you can easily pick out the port. It will actually trace the entire SIP call for you.

SIP as a protocol is complicated, but in terms of recognizing what is going on it's quite simple. Don't even bother trying to determine the why.

 

[danramirez]

Irwin,

I will sniff the port on my firewall where I receive the SIP Trunk, I will then let you know what I get.

Thanks very much, regards,

Daniel

 

[LoopyLou]

Good questions. Here is what I think.

Sip is only signalling so once the call set up its RTP.

The 3300 is only involved in setup once telework answer its no longer involved ( except to check phone status ). On you LAN once the Minet is done setting up the call all RTP streams from the IP of set A to the IP of set B.

The teleworker sends everything/gets everything from the IP of the MBG. So it would stream from its IP to the routable IP of the MBG. The SIP trunks only talk to the 3300 for setup and once thats done I would think RTP from the porvider would need to be able to stream to the MBG in the DMZ. Therefore I think option 1 is no because the 3300 in not involved in streaming, option 4 is no because the teleworker sends everything via the MBG. Therefore its either option 2 or 3. I am not positive of which however. I think its option 2 which is WAN of firewall to DMZ. If I am correct you would see RTP from the IP of the WAN IP to the DMZ IP of the MBG. Again I am no firewall expert, just trying to help.

If you want to see SIP negotiation, you need to Sniff the 3300 port. If you want to see the resulting RTP sniff a internal phone making/receiving a SIP call.

I would also sniff a phone making a call to a teleworker phone call to see the RTP interaction to the MBG.

The single biggest problem with communications is the illusion that it has taken place.