[Kamailio-Users] Kamailio RTP Proxy issues

Mon Nov 2 12:45:11 CET 2009

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 at 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 
-- 
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.