Important nat question

I am new in ser .
I try to figure how the ser & rtpproxy work , and that is my big question

Lets say that I have ser server with rtpproxy and public ip with 96 k upload

I have 2 client , both behind 2 different nat with x-lite ( g711 codec ) , and high internet speed.
If client 1 call to client 2 and the call establish , do they can talk? , does the rtp go direct between them or the rtp must through via the server? And if its via the server I believe that they cant hear because the low upload ?

That should work:

Client 1(privet ip 10.0.0.1) ------------- ser server (public ip ) ---------------- client 2 (privet ip 192.168.0.1)

But after they have connect that can work? :

Client 1(privet ip 10.0.0.1) ------------------------------- client 2 (privet ip 192.168.0.1)

Thanks

if both clients are behind nat, you must use rtpproxy. openser only handles the signaling and session parameters. it can set the session up so that it uses rtpproxy. with 96k upload you are unlikely to get good quality audio, even if that bandwidth is not contended (which it probably will be.. esp. if you are running the rtpproxy on the same server as your openser instance).

so we must use rtpproxy for that case , that ok , but if i understand u right, the rtpproxy handle the media via eimself?
in other wards - all the media traffic ( if use nat ) are via the rtpproxy ?
its mean that if i have 100 users in diferent nat i need to calculat how many calls the same time and that is the bandwidth for the rtpproxy ?
i was thinking the rtpproxy take care the nat by telling the users where to go , connect them and let tham talk alon by using theirs internet conection , and this way i dont need high internet conection at ser % rtpproxy site

someone know any machine that can do it ?
thanks

Quote:

all the media traffic ( if use nat ) are via the rtpproxy ?

yep

Quote:

if i have 100 users in diferent nat i need to calculat how many calls the same time and that is the bandwidth for the rtpproxy ?

yep

Quote:

i was thinking the rtpproxy take care the nat by telling the users where to go

nope, openser tells them 'where to go' in this sense. rtpproxy becomes the source/destination of that directed traffic

Quote:

someone know any machine that can do it ?

it cannot be done via sip without a media proxy.

Then I think SER + Media Proxy have no more advantage vs. Asterisk, since they use same BW (and can not cut the call if credit goes low).

the major differences are in design and capability. Asterisk cannot handle as many subscribers or calls per second as Oser+rtpproxy/mediaproxy can. Plus, with the latter, you have logical separation of your registrar and ingress/egress proxies, which helps with scaling. There are many other options to consider as well.

Thanks XC!

can you please tell me, how Openser work without RTP/Mediaproxy? Are the clients connected directly and you dont have to pay much for traffic of the server, right ?

correct, media flows end-to-end. However, if NAT is involved with both endpoints, the media wont be able to route properly.

x-console :

correct, media flows end-to-end. However, if NAT is involved with both endpoints, the media wont be able to route properly.

there are protocol technologies such as STUN, TURN, and ICE that can allow two endpoints behind NAT to connect to each other without proxy of media. these can be used in conjunction with a sip server or soft switch.

spg

p.s. i do believe that what i just wrote is accurate although i am not an expert on setting up sip servers an so am not the one to provide more details on implementation.

Quote:

there are protocol technologies such as STUN, TURN, and ICE

ICE is not a protocol - more a method of using STUN and TURN together to try everything possible to try and traverse NAT.

There are certain situations where both end-points are behind a particular type of NAT where you will not traverse it no matter what you do, and you have to proxy. In my experience here this is less than 2% of users however, so you can always take a view on that. Most NAT devices will open a "pinhole" for the UDP media traffic which stays open for a period of time. Both STUN and TURN utilise this to work, in different ways. Not all NAT devices allow it however.

The more intelligent SIP Session Border Control devices (the Ditech's spring to mind) try a majority of STUN, TURN and other tricks, resorting to media proxy only when absolutely necessary. I tend to call these "Intelligent NAT Traversal" devices. At the moment there are no open-source devices out there for this that I am aware of.

I believe that openSER will be configurable do to this at some point as intelligent NAT traversal is in the roadmap.

For now the easy options are:-

1. Buy a Ditech C1000 (or other intelligent NAT traversal device). That's a $10k outlay but it will make the problem go away.
2. Try using STUN, TURN or both (ICE).
3. Just route all media through an RTP proxy and be done with it.

The difficult option will be to build a config (and possibly re-code some of openSER) to try an ICE combo and then proxy in the event of media failure only.

See also:-

http://www.voipuser.org/forum_topic_7295.html