[OpenSIPS-Users] inconsistence nathelper behavior

Ovidiu Sas osas at voipembedded.com
Fri Apr 8 04:36:05 CEST 2011


Please check the following example and adjust your config accordingly:
http://www.opensips.org/html/docs/modules/devel/rtpproxy.html#id292375


Regards,
Ovidiu Sas

On Thu, Apr 7, 2011 at 9:59 PM, Leon Li <Leon.Li at aarnet.edu.au> wrote:
> Sorry, forgot to add my config:
>
> route[3] {
>        #---- NAT fixup ----#
>        #---- RTPproxy handling ----#
>        if (is_method("BYE|CANCEL")) {
>                unforce_rtp_proxy();
>        } else if (is_method("INVITE")) {
>                #---- Activates the RTP Proxy for the CALLEE ---#
>                #force_rtp_proxy();
>                if (has_body("application/sdp")) {
>                        if (rtpproxy_offer())
>                                rtpproxy_answer();
>                        } else {
>                                rtpproxy_offer();
>                        }
>        } else if (is_method("ACK") && has_body("application/sdp"))
>                rtpproxy_answer();
>
>        # catch and fix replies
>        t_on_reply("2");
> }
>
> onreply_route[2] {
>        xlog("incoming reply\n");
>
>        #---- Handling of the SDP for the 200 or 183 reply ----#
>        #---- If behind nat (flags 5 or 6) start RTP Proxy ----#
>        #----    Activates the RTP Proxy for the CALLER    ----#
>        if ( is_method("INVITE") && (isflagset(5) || isbflagset(6)) &&
>                has_body("application/sdp")) {
>                force_rtp_proxy();
>        }
>
>        #---- If the CALLEE is behind NAT, fix the CONTACT HF ----#
>        if (isbflagset(6)) {
>                fix_nated_contact();
>                search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');
>        }
> }
>
> Regards,
> Leon
>
>
> -----Original Message-----
> From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Leon Li
> Sent: Friday, 8 April 2011 11:40 AM
> To: Ovidiu Sas; OpenSIPS users mailling list
> Subject: Re: [OpenSIPS-Users] inconsistence nathelper behavior
>
> Thanks Ovidiu,
>
> I gave a go but no luck.
>
> The DSP is offered in a "200 OK" from NATed endpoint, however, I couldn't find a way to check against "200 OK" and offer rtpproxy (ie. rewrite c= part). anyway I can modify a 200 OK response?
>
> Regards,
> Leon
>
>
> -----Original Message-----
> From: sip.nslu at gmail.com [mailto:sip.nslu at gmail.com] On Behalf Of Ovidiu Sas
> Sent: Friday, 1 April 2011 10:20 AM
> To: OpenSIPS users mailling list
> Cc: Leon Li
> Subject: Re: [OpenSIPS-Users] inconsistence nathelper behavior
>
> From the log that you previously posted, you are invoking
> force_rtp_proxy on the INVITE, and the INVITE has no SDP (and there
> you have your first error log).
> Then you got a reply and you are trying to invoke force_rtp_proxy with
> incorrect parameters maybe and there you have the second error.
> You need to fix your script and properly invoke the rtpproxy functions
> for INVITE/200ok or 200ok/ACK.
>
> Maybe it's time to upgrade and use rtpproxy_offer/answer functions
> (see example in README file):
> http://www.opensips.org/html/docs/modules/devel/rtpproxy.html#id292912
>
>
> Regards,
> Ovidiu Sas
>
> On Thu, Mar 31, 2011 at 7:11 PM, Leon Li <Leon.Li at aarnet.edu.au> wrote:
>> Hi Razvan,
>>
>> The call was initialled from CUCM (public side), which always does late
>> offer, so there is no SDP body in the first INVITE. The SDP was created in
>> the "200 OK" by the Callee (private side). Anyway we can parse this one.
>>
>> The function used is  force_rtp_proxy() as I am still on v1.6.2.
>>
>> Regards,
>>
>> Leon
>>
>>
>>
>> From: users-bounces at lists.opensips.org
>> [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea
>> Sent: Friday, 1 April 2011 12:18 AM
>>
>> To: OpenSIPS users mailling list
>> Subject: Re: [OpenSIPS-Users] inconsistence nathelper behavior
>>
>>
>>
>> Hello Leon,
>>
>> As you can see, OpenSIPS is unable to parse the SDP body. Please make sure
>> that your INVITE message has SDP body. If it does and you still have the
>> problem, a capture of the initial INVITE would be very useful.
>> There are no debug messages of RTPProxy, only INFOs. Can you please tell me
>> if the RTPProxy error comes from an rtpproxy_offer function or
>> rtpproxy_answer?
>>
>> Regards,
>> Razvan
>>
>> On 03/30/2011 01:40 AM, Leon Li wrote:
>>
>> Hi Razvan,
>>
>>
>>
>> I've turned on DBUG, although not many output in syslog.
>>
>>
>>
>> Mar 29 22:12:05 /usr/sbin/opensips[9336]: INVITE Received -
>> RURI=sip:xxxxxxxxxxxxxxxxxxxxxxxxx
>>
>> Mar 29 22:12:05 /usr/sbin/opensips[9336]: Alias Found, New
>> RURI=xxxxxxxxxxxxxxxxxxxx
>>
>> Mar 29 22:12:05 /usr/sbin/opensips[9336]: ERROR:nathelper:force_rtp_proxy:
>> Unable to parse body
>>
>> Mar 29 22:12:05 /usr/sbin/opensips[9336]: new branch at
>> sip:xxxxxx at 192.168.1.112:19463;user=phone
>>
>> Mar 29 22:12:05 /usr/sbin/opensips[9321]: incoming reply
>>
>> Mar 29 22:12:05 /usr/sbin/opensips[9325]: incoming reply
>>
>> Mar 29 22:12:07 /usr/sbin/opensips[9323]: incoming reply
>>
>> Mar 29 22:12:07 /usr/sbin/opensips[9323]:
>> ERROR:nathelper:force_rtp_proxy_body: incorrect port 0 in reply from rtp
>> proxy
>>
>> Mar 29 22:12:07 rtpproxy[11501]: INFO:handle_command: lookup request failed:
>> session 9332ee00-d9215935-5a7d0-22cf9eca at Public IP, tags
>> 7d81dea5-6b91-4499-b7a2-77dff783a179-43141483;1/1219087299;1 not found
>>
>> Mar 29 22:12:07 /usr/sbin/opensips[9323]: ACC: transaction answered:
>> timestamp=1301436727;method=INVITE;from_tag=7d81dea5-6b91-4499-b7a2-77dff783a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0-22cf9eca at xxxx;code=200;reason=OK
>>
>> Mar 29 22:12:07 /usr/sbin/opensips[9336]: Method ACK from NATed UA -
>> RURI=sip:xxxxxx;user=phone;nat=yes F=sip:xxxxxx T=sip:xxxx at 202.158.196.132
>> C=<null>
>>
>> Mar 29 22:12:07 /usr/sbin/opensips[9336]: ACC: request acknowledged:
>> timestamp=1301436727;method=ACK;from_tag=7d81dea5-6b91-4499-b7a2-77dff783a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0-22cf9eca at xxxx4;code=200;reason=OK
>>
>> Mar 29 22:12:15 /usr/sbin/opensips[9323]: INFO:core:parse_first_line: empty
>> or bad first line
>>
>> Mar 29 22:12:15 /usr/sbin/opensips[9323]: INFO:core:parse_first_line: bad
>> message
>>
>> Mar 29 22:12:15 /usr/sbin/opensips[9323]: ERROR:core:parse_msg: message=<>
>>
>> Mar 29 22:12:15 /usr/sbin/opensips[9323]: ERROR:core:receive_msg: parse_msg
>> failed
>>
>> Mar 29 22:12:34 rtpproxy[11501]: INFO:handle_command: delete request failed:
>> session 9332ee00-d9215935-5a7d0-22cf9eca at xxxx, tags
>> 7d81dea5-6b91-4499-b7a2-77dff783a179-43141483/1219087299 not found
>>
>>
>>
>> However, a successful call (i.e. from NATed to public) has much more output,
>> like below.
>>
>>
>>
>> Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session
>> 825186551-19463-7 at BJC.BGI.B.BBC, tag 1615321429;1 requested, type strong
>>
>> Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session on a port
>> 64286 created, tag 1615321429;1
>>
>> Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: pre-filling caller's
>> address with Public IP of ADSL:45020
>>
>> Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session
>> 825186551-19463-7 at BJC.BGI.B.BBC, tag 1615321429;2 requested, type strong
>>
>> Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session on a port
>> 37262 created, tag 1615321429;2
>>
>> Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: pre-filling caller's
>> address with Public IP of ADSL:23420
>>
>>
>>
>> BTW, I am running opensips v1.6.2 and rtpproxy version
>>
>> /usr/bin/rtpproxy -v
>>
>> Basic version: 20040107
>>
>> Extension 20050322: Support for multiple RTP streams and MOH
>>
>> Extension 20060704: Support for extra parameter in the V command
>>
>> Extension 20071116: Support for RTP re-packetization
>>
>> Extension 20071218: Support for forking (copying) RTP stream
>>
>> Extension 20080403: Support for RTP statistics querying
>>
>> Extension 20081102: Support for setting codecs in the update/lookup command
>>
>> Extension 20081224: Support for session timeout notifications
>>
>>
>>
>> Thanks,
>>
>> Leon
>>
>>
>>
>> From: users-bounces at lists.opensips.org
>> [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea
>> Sent: Friday, 25 March 2011 8:25 PM
>> To: users at lists.opensips.org
>> Subject: Re: [OpenSIPS-Users] inconsistence nathelper behavior
>>
>>
>>
>> Hi Leon,
>>
>> You should run rtpproxy with '-d DBUG'. You can find the logs in
>> /var/log/syslog.
>>
>> Regards,
>> Razvan
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



More information about the Users mailing list