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:
General Lee schrieb:
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?
It is the s flag which was originally used (should be now deprecated, but people report that offer/answer does not work).
route { ... if (is_method("INVITE")) { if (has_sdp()) { if (rtpproxy_offer())
here: force_rtpproxy();
t_on_reply("1"); } else { t_on_reply("2"); } } if (is_method("ACK") && has_sdp()) rtpproxy_answer();here: force_rtpproxy("s");
... }
onreply_route[1] { ... if (has_sdp()) rtpproxy_answer();
here: force_rtpproxy();
... }
onreply_route[2] { ... if (has_sdp()) rtpproxy_offer();
here: force_rtpproxy("s");
... }
regards klaus
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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