Hi Klaus. I use the rtpproxy_offer + answer functions without any flags. I've listed parts of my code below. route[2] { if (is_method("BYE|CANCEL")) { unforce_rtp_proxy(); } else if (is_method("INVITE")) { if(has_body("application/sdp")){ if(rtpproxy_offer()) t_on_reply("1"); }else{ t_on_reply("2"); #this will handle the initial INVITE that has no SDP } } if(is_method("ACK") && has_body("application/sdp")){ rtpproxy_answer(); } } onreply_route[1] { if (has_body("application/sdp")) rtpproxy_answer(); if (isbflagset(6)) { search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nty=yes'); search_append('m:.<sip:[^>[:cntrl:]]*', ';nty=yes'); if(cmp_str("MY_IP","$si")) else { fix_nated_contact(); } } exit; } onreply_route[2] { if (has_body("application/sdp")) rtpproxy_offer(); if (isbflagset(6)) { search_append('Contact:.*sip:[:cntrl:]]*', ';nty=yes'); search_append('m:.<sip:[^>[:cntrl:]]*', ';nty=yes'); if(cmp_str("MY_IP","$si")) else { fix_nated_contact(); } } exit; } Klaus Darilion-2 wrote: -- View this message in context: http://www.nabble.com/Kamailio-RTP-Proxy-issues-tp26112049p26123037.html Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

Thank you Alex. If the rtpproxy_offer/answer functions do not work, do you have any ideas on how I should route an INVITE without SDP and ACK with SDP using force_rtp_proxy similar to the example below? route { ... if (is_method("INVITE")) { if (has_sdp()) { if (rtpproxy_offer()) t_on_reply("1"); } else { t_on_reply("2"); } } if (is_method("ACK") && has_sdp()) rtpproxy_answer(); ... } onreply_route[1] { ... if (has_sdp()) rtpproxy_answer(); ... } onreply_route[2] { ... if (has_sdp()) rtpproxy_offer(); ... } Alex Balashov wrote: -- View this message in context: http://old.nabble.com/Kamailio-RTP-Proxy-issues-tp26112049p26124537.html Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

Thanks for your email Klaus, that was very helpful. I tried your inserting your code. Attached is the RTP Proxy syslog from the call. I added xlog comments and my call appears to be processed correctly using the force_rtp_proxy("s") statements however the call is still not setting up correctly. I am still not seeing the callee setup in the RTP Proxy syslog messages. Below is my examination of the capture files from one of my H323 - SIP calls. I have also attached a full RTP Proxy syslog capture from another call. I would appreciate if anyone has any suggestions why my calls are not being routed though RTP Proxy correctly? Thanks, My First test was a H323 - SIP call using H323 fast connect. This call was successful. Mirial-fast connect: In the inital sdp in the invite (sip-dum file) v=0. o=GateWay 1 0 IN IP4 69.35.15.51. s=SipCall. c=IN IP4 69.35.15.51. t=0 0. a=sendrecv. m=audio 10044 RTP/AVP 0. a=sendrecv. a=rtpmap:0 PCMU/8000/1. In the same file it says RTP stats: 364 in from callee, 477 in from caller, 841 relayed, 0 dropped Since I proxyed packets from both sides, the call was setup correctly - even if it was missing the video which was never offered. === H323 to SIP call using H323 Standard Connect Miral H323_Mirial SIP The RTP proxy looks to have been set up correctly with the proxy but at the BYE, the following stats were noted. RTP stats: 0 in from callee, 0 in from caller, 0 relayed, 0 dropped Which was a failed call. The tshark file is REALLY interesting. You can see both my H323 and SIP clients sending data (120.19.211.106 & 69.35.15.51) like mad but the rtpproxy not relaying anything on to the other client. I checked the sip pcap file and it confirms that it was sending data. So the question is why doesn't rtpproxy forward these packets. One answer may be in the SDP. the OK from the kamailio to the client reads v=0. o=103 2114479936 0 IN IP4 192.168.0.151. s=-. i=Dylogic Mirial 7.0.7. c=IN IP4 69.35.104.179. b=AS:256. t=0 0. m=audio 42248 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=x-mpdp:192.168.0.151:49620. m=video 41044 RTP/AVP 96 34. a=rtpmap:96 H263-1998/90000. a=fmtp:96 CIF=1; QCIF=1; D=1; F=1; I=1; J=1; L=1; S=1; T=1. a=rtpmap:34 H263/90000. a=fmtp:34 CIF=1; QCIF=1. a=x-mpdp:192.168.0.151:49622. a=nortpproxy:yes. and the ACK reads v=0. o=GateWay 1 0 IN IP4 69.35.15.51. s=SipCall. c=IN IP4 69.35.104.179. t=0 0. a=sendrecv. m=audio 42248 RTP/AVP 0. a=sendrecv. a=rtpmap:0 PCMU/8000/1. m=video 41044 RTP/AVP 34. a=rtpmap:34 H263/90000/1. a=nortpproxy:yes. So my question is ... Why is RTP Proxy telling both clients to talk to it on the same port for audio and again for video?? You can see in the fast-connect version how the two ports are different. Here is an example of the callee being setup as the caller. Also Oct 27 17:33:06 nzvrs rtpproxy[24086]: DBUG:handle_command: received command "6220_332 Uc0,8,101 f701328-330f48d3-13c4-45026-7ff92-64debcb6-7ff92 120.19.211.106 49620 DLddb8219e97;1 f363348-330f48d3-13c4-45026-7ff92-2be5df3c-7ff92;1" Oct 27 17:33:06 nzvrs rtpproxy[24086]: INFO:handle_command: adding strong flag to existing session, new=1/0/0 Oct 27 17:33:06 nzvrs rtpproxy[24086]: INFO:handle_command: lookup on ports 42248/0, session timer restarted Oct 27 17:33:06 nzvrs rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 120.19.211.106:49620 should have been setting up the callee not the caller. I can't see any callee setup. Klaus Darilion-2 wrote: http://old.nabble.com/file/p26156685/RTP%2BProxy%2Bsyslog.txt RTP+Proxy+syslog.txt http://old.nabble.com/file/p26156685/RTP%2BProxy%2Bsyslog.txt RTP+Proxy+syslog.txt -- View this message in context: http://old.nabble.com/Kamailio-RTP-Proxy-issues-tp26112049p26156685.html Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

Klaus, Thanks so much for your help. Removing the 'METHOD_INVITE' on line 2422 worked for the force_rtp_proxy with "s" flag :). I couldn't get it working with the rtpproxy offer/answer but the force_rtp_proxy is working. Thanks again for your help. Klaus Darilion-2 wrote: -- View this message in context: http://old.nabble.com/Kamailio-RTP-Proxy-issues-tp26112049p26619422.html Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

Alex Balashov wrote: Although it is rather strange - they are just wrapper functions. Are you using any other "special" flags too? regards klaus

I agree it is very strange that they do not work as they are, indeed, just wrappers, and very simple ones at that. But alas, one thing is certain: they do not. At least, not when used exactly as described in their respective documentation examples. Alex Balashov wrote: -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671