Topic: SME as a SIP Proxy

[seb]

Hi all,

Trying to hook a SIP Trunk into our local IP-PBX been told we need a SIP Proxy in order to solve the NAT issue (We can place calls on Hold/Transfer).

Google found this http://siproxd.sourceforge.net/index.php?op=news that prob solve it.

Anyone installed it on the SME?
We use SME 7.3 as our Gateway.

Any advice?

Thanks.-

[Knuddi]

Haven't tried it out but having a way to automatically setup RTP (and adjust iptables) ports based on the SIP negotiation has been a problem I have struggled with. I have had to use STUN for some time and that has not been ideal for me.

I have managed to compile the two items needed (libosip2 package and siproxd) and now need to experiment.

[arne]

What kind of IP-PBX is it ? It's not Asterisk ? (Have been runing it behind a nat router for a while. No stun server. No problems)

[Knuddi]

Its some Sipura SPA-3000 (now Cisco) boxes I have used.

[arne]

But this is more or less an ordinary sip client ? Why not just install the standard Asterisk solution for the SME server (Sail/Selintra) on the SME server, and everything should work more or less "out of the box".

The local SIP client will then be able to communicate via the Asterisk SIP proxy.

A link to the "thing": http://www.voipuser.org/review_8.html

[seb]

Well my topology is quite different.

We have a local IP-PBX (Mitel) with IP Phones, and need to place calls throw a registered SIP Trunk provider (ex. bradvoice).

Seems that ports are dynamically switched when placing features like Hold/Transfer.

First idea was trying to port forward and play with the SME FW, but with no luck.

Then we found that SIP Proxy ap.

[arne]

I think that sip will usually work trogh nat if you forward all relevant ports.

For the Asterisk server the server itself will have to "know" or to be configured to work trough nat.

To make a default Aterisk server to work trough nat you will also have to forward UDP port 5060 and the whole portrange UDP 10000:20000.

Did the system vendor say that it was not possible to configure the equipment for nat ? Did you try to forward such a broad range of "all possible" UDP ports ? (I hope that I remember it correctely and that the sme gateway can do that.)

By the way I have tryed to use the buildt in SIP proxy server on the Smoothwall gateway, but this did not work, for me. NAT forwarding works without a problem. (Have configured Asterisk to use quite less then the default range of 10000 ports.)

[seb]

Depends on what we call "Work". Forwarding ports make boths systems (Provider Softswitch and Mitel IP-PBX) to place normal calls without a problem.

The issue is present when the feature "Hold" or "Transfer" on the phone is placed. Ports are dynamically changed and no range forward solve this in my case.

[christian]

Well my topology is quite different.

We have a local IP-PBX (Mitel) with IP Phones, and need to place calls throw a registered SIP Trunk provider (ex. bradvoice).

Seems that ports are dynamically switched when placing features like Hold/Transfer.

First idea was trying to port forward and play with the SME FW, but with no luck.

Then we found that SIP Proxy ap.

You shouldn't need to port forward (and it likely won't do anything) and quite frankly the issue will have to do with the fact the RTP stream is actually going directly from the IP phone (or other 3300 gateways as may be the case) to the service provider. The signaling is going through the 3300 (assuming that is what you have). So the problem you have is that the RTP ports have to be opened and resolved to the correct IP phone dynamically on a call by call basis. To add a little fun, when you put a call on hold on the 3300, the RTP stream will  move from the phone to the 3300 because the 3300 can provide things like music on hold. When you return from hold, the stream will move back to the phone. This is part of the fun with SIP!

Most service providers solve this by providing an SBC (Session Border Controller) in their network to adjust the  IP address within the SIP signaling to match. This is why many will simply work (and likely why Arne's is working). Mitel's IP phones know how to deal with the SBC situation through NATs.

If your service provider doesn't have an SBC then you will need to deal with it at your own firewall as you say to be your case. You could put a border gateway in your DMZ or perhaps try using Asterisk or OpenSER to act as your RTP gateway on top of the SME server. In this case you are running the RTP stream through the gateway to force the RTP streams and signaling to be remapped between the two domains (external vs internal).

Mitel also has a number of tech notes on how to configure for various service providers and softswitches. Sadly just about every service provider is a bit different in their implementation for various reasons. I don't know if they have yours done yet. Which service provider are you using?

I would also double check to see if the service provider provides an SBC or if you have to modify some of your SIP settings to get the SBC to act properly.

[seb]

Christian, many thanks for your comments.

Im testing with Broadvoice ITSP (Support isn't good) but i will try to confirm the SBC point.

So you mean by proposing OpenSER that siproxd is not going to solve the SIP over RTC stream?
I'll start looking for at the OpenSER docs and see...

Thanks.-

[christian]

So you mean by proposing OpenSER that siproxd is not going to solve the SIP over RTC stream?
I'll start looking for at the OpenSER docs and see...

I'm not familiar enough with sipproxd but it may do what you want (based on what I read on the web site). I have seen people solve this problem with Asterisk and OpenSER. I am also aware of people playing with Asterisk on the SME server so forum support may be good. However, if you do get sipproxd working and it is simpler to configure than the others (which are somewhat complicated) then it would be wonderful to have this as a contrib/How-to for others.

A commercial option would be to use an InGate gateway which has enjoyed significant interop with Mitel.

More than anything, I wanted you to be fully aware of what was happening under the hood so you know how to attack the problem.

From what I can see, Broadvoice uses the Broadsoft switch which I know has had interop with the 3300 and for which a technical note exists (your reseller should have access to this).

According to Broadvoice, I can see they must have an SBC (but I can't tell which). I think you are probably making and receiving calls properly but the problem is when you go on hold or transfer, correct? If so then you may be able to solve this through some configuration options. However this may depend on how the provider has provisioned his side on both the softswitch and SBC.

Christian

[jrsReign]

Most account providers break this by accouterment an SBC (Session Bound Controller) in their arrangement to acclimatize the IP abode aural the SIP signaling to match. This is why abounding will artlessly plan (and acceptable why Arne's is working). Mitel's IP phones apperceive how to accord with the SBC bearings through NATs.

If your account provider doesn't accept an SBC again you will charge to accord with it at your own firewall as you say to be your case. You could put a bound aperture in your DMZ or conceivably try application Asterisk or OpenSER to act as your RTP aperture on top of the SME server. In this case you are active the RTP beck through the aperture to force the RTP streams and signaling to be remapped amid the two domains (external vs internal).


________________
IP PBX