I changed the line modparam("nathelper", "rtpproxy_sock", "/var/run/rtpproxy.sock") to modparam("nathelper", "rtpproxy_sock", "udp:localhost:22222") and started the rtpproxy as ./rtpproxy -s udp from the relevant directory and this resulted in a series of "rtpp_command: no response from rtpproxy" and rtpproxy temporarily disabled" errors. If I return to the original modparam and start it as ./rtpproxy then it works but like I said when the private client rings the public client, I get "ERROR: send_rtpp_command: cant read reply from a RTP Proxy".

Any further ideas? Has anyone on the mailing list experienced this? I am using the script given in the onsip getting started doc for 0.9.0. but am using ser 0.8.14.

BR,

Vivienne

"Greger V. Teigre" <greger@teigre.com> wrote:

See inline.

> Thank you for that Greger. I have altered my script so that it
> exactly mimics the one in the onsip document besides the has_totag
> and fix_nated register. All is good when I ring from a private phone
> to a public phone i.e. the audio is very clear and the following
> messages are in /var/log.
>
> ERROR: extract_body: message body has length zero
> ERROR: force_rtp_proxy2: cant extract body from the message.
>
> I assume this is because of the 200 OK to a register message where
> theres no sdp?? Is this correct?

That's correct. You will find code in the example configs where we test for an empty body before calling force_rtp_proxy.

> However when I try to phone from public into private I get:
>
> ERROR: send_rtpp_command: cant read reply from a RTP Proxy.
>
> I find this confusing because I know the rtpproxy is working.

This means that rtpproxy is not responding to a particular message. I have heard some people have had problems with the socket based communication. I only use UDP. This is what you do to set up udp (22222 is default port):

modparam("nathelper", "rtpproxy_sock", "udp:localhost:22222")

rtpproxy must be started with -s udp:*

g-)

> BR
> Vivienne.
>
> "Greger V. Teigre" <greger@teigre.com> wrote:
> Yes, you can use fix_nated_contact instead. It is not entirely
> RFC-compliant, but that's what you have in 0.8.14.
> The has_totag() only tests to see if the INVITE has a To header,
> which means that it is in-dialog and thus is a re-INVITE. An INVITE
> will normally not have loose routing unless you have another SIP
> proxy forwarding an INVITE to you (in which case you should assume
> that the other proxy handles NAT and thus not trigger NAT-related
> code). You can safely remove the has_totag() if you use
> force_rtp_proxy("l")
> g-)
>
> ---- Original Message ----
> From: Vivienne Curran
> To: Greger V. Teigre ; serusers@lists.iptel.org
> Sent: Tuesday, April 05, 2005 02:25 PM
> Subject: Re: [Serusers] Contact Header and SDP not rewritten
>
>> Greger,
>>
>> Since fix_nated_register does not exist with 0.8.14, will
>> fix_nated_contact do instead? Also if I am leaving out the
>> has_totag() at the start of the script, will this greatly effect its
>> functionality?
>>
>> Thank you,
>> Vivienne