[Serusers] rtpproxy
Klaus Darilion
klaus.mailinglists at pernau.at
Wed Mar 17 16:05:26 CET 2004
Hi Fabio!
It also depends on the configuration of your main proxy as the main
proxy will save the contact address in the REGISTER requests.
If the NAT is symmetric, the SIP messages also has to use the outbound
proxy for contacting the UA as shown below, as the pinhole in the NAT
box is only open for requests from the same IP/port which received the
REGISTER message:
UA1 UA2 outbound main
-----INVITE-----------------> ---------INVITE------>
<----INVITE------ <------INVITE---------
To do this, the outbound proxy also has to keep state of the location of
the NATed UAs. I think this is hard to do with ser. Thus, I suggest to
do not use a separate outbound proxy but integrate the NAT traversal
into the main proxy (as iptel does).
Is someone else using ser+nathelper+rtpproxy successful in a plain
outbound proxy configuration (comparable to the jasomi boxes)?
regards,
Klaus
Fábio Silvestri wrote:
> WoW
>
> Klaus, from client with public IP I can reach nated client very well. My
> problem is only when client with nat ip try to reach another client with
> nat ip too.
>
> The ser.cfg on Outbound proxy machine, has this configuration:
>
> route{
> log(1, "-------------------------------------------\n");
> log(1, "entering main loop (5060)\n");
>
> if (nat_uac_test("2")) {
> log(1, "src address different than via header->NAT
> detected\n");
> log(1, "force_rport and fix_nated_contact and
> setflag(5)\n");
> #try NAT traversal, works only if the client is symmetrical
> force_rport();
> fix_nated_contact();
> append_hf("P-hint: fixed NAT contact for request\r\n");
> # flag 5 indicates that incoming request is from NATed
> client
> setflag(5);
> };
> record_route();
> # loose-route processing
> if (loose_route()) {
> t_relay();
> break;
> };
> #inserted by klaus
> if (method=="INVITE") {
> log(1, "INVITE\n");
> record_route();
> force_rtp_proxy();
> /* set up reply processing */
> t_on_reply("1");
> };
> # forward to current uri now; use stateful forwarding; that
> # works reliably even if we forward from TCP to UDP
> if (!t_relay()) {
> sl_reply_error();
> };
>
> }
>
> #inserted by klaus
> # all incoming replies for t_onrepli-ed transactions enter here
> onreply_route[1] {
> log(1, "REPLY\n");
> if (status=~"[12][0-9][0-9]") {
> force_rtp_proxy();
> log(1, "PROXY\n");
> }
> }
>
>
> Klaus Darilion wrote:
>
>> rtpproxy also works fine within this setup.
>>
>> Try if you can reach the natted client from an client with public IP.
>> If this is not possible, maybe the conteact in the location table is
>> wrong. Do you use fix_nated_contact(); and natping from the nathelper
>> module to keep the bindings in the NAT boxes alive?
>>
>> Klaus
>>
>> Fábio Silvestri wrote:
>>
>>> Hi
>>>
>>> I'm still in trouble with using SER & rtpproxy.
>>>
>>> Everything works fine, just one only thing doesn't, if I'm registered
>>> with my ATA186 with nated ip (192.168.0.2) I can dial and talk with
>>> everybody on PSTN, but if I try to dial for another ATA186 (behind a
>>> nat 192.168.1.2) or maibe for the number configured on second port on
>>> ATA186, the call don't happen.
>>>
>>> I think this maibe a problem with rtpproxy, maibe they can't control
>>> two sessions with behind nat; because if the second ATA186 has valid
>>> IP, everything works fine.
>>>
>>>
>>
>
More information about the sr-users
mailing list