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 <[email protected]> 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: [email protected] > [mailto:[email protected]] 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: [email protected] [mailto:[email protected]] 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 <[email protected]> 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: [email protected] >> [mailto:[email protected]] 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:[email protected]: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@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@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:[email protected] >> 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@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@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 >> [email protected], 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 >> [email protected], 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: [email protected] >> [mailto:[email protected]] On Behalf Of Razvan Crainea >> Sent: Friday, 25 March 2011 8:25 PM >> To: [email protected] >> 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 >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
