[Kamailio-Users] Kamailio RTP Proxy issues

[Alex Balashov]

General Lee,

We just had a thread about this, initiated by me and Joe Hart.  We 
came to the conclusion that the rtpproxy_offer/answer functions don't 
actually work, but force_rtp_proxy() does, and that use of flags is 
required:

http://lists.kamailio.org/pipermail/users/2009-October/024934.html

-- Alex

General Lee wrote:

> 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:
>> Do you use force_rtpproxy() or the ...offer() and ...answer() functions?
>>
>> Do you use any flags when call the functions?
>>
>> klaus
>>
>> General Lee schrieb:
>>> Hi,
>>>
>>> I am currently integrating an H323 to SIP gateway with Kamailio and
>>> trying
>>> to route all calls through RTP Proxy. 
>>>
>>> I have a problem where RTP Proxy treats both the incoming H323 gateway
>>> call
>>> (Caller) and outgoing SIP call (Callee) as the 'caller' in the RTP Proxy
>>> syslog. RTP Proxy doesn't assign a 'callee' therefore not able to setup a
>>> call (See syslog below). I have configured Kamailio to accept the 'ACK'
>>> with
>>> SDP and this is working correctly.
>>>
>>> When I enable H323 Fast connect and the SDP is included in the INVITE,
>>> the
>>> call connects correctly and is routed through RTP Proxy. I feel the
>>> problem
>>> is related to RTP Proxy receiving an INVITE from the H323-SIP gateway
>>> without SDP.
>>>
>>>  Can anyone explain why RTP Proxy treats both the incoming H323 Gateway
>>> call
>>> and outgoing SIP call as the 'caller' in the RTP Proxy syslog. How can I
>>> make RTP Proxy treat the incoming H323 call as the 'callee'? 
>>>
>>> Thanks,
>>>
>>>
>>>
>>>
>>> More information below
>>>
>>> *******************************************************************************
>>>
>>> My H323 endpoints use H323 Slow Connect, so when the H323-SIP Gateway
>>> delivers the 'INVITE' to Kamailio there is no SDP included in the INVITE.
>>> I
>>> added a 'onreply_route' to the Kamailio configuration file which handles
>>> the
>>> 'ACK' with SDP which is working correctly.
>>>
>>> All of my SIP calls (Signalling + Media) are forced though RTP Proxy and
>>> I
>>> would like to force all H323-SIP Gateway calls through RTP Proxy.
>>>
>>> When placing a call from my H323 endpoint to my SIP UA, the RTP Proxy
>>> syslog
>>> records the incoming and outgoing call, however RTP Proxy states that the
>>> ‘callee’ is actually the 'caller'. The RTP Proxy syslog also states that
>>> the
>>> caller is the caller so there is no 'callee' (see below).  In the syslogs
>>> both the ‘callee’ and ‘caller’ are recognised as the ‘caller’ so RTP
>>> Proxy
>>> has no callee to send the traffic back to.
>>>
>>> When the INVITE is received the ‘callee’ is populated in the syslogs as
>>> the
>>> ‘caller’. The H323 Gateway call is not recorded until after the ‘ACK’ 
>>> with
>>> SDP is received from the gateway.
>>>
>>> Oct 27 17:33:05 rtpproxy[24086]: INFO:handle_command: pre-filling
>>> caller's
>>> address with 72.19.211.106:49620 (Should be callee)
>>> Oct 27 17:33:05 rtpproxy[24086]: INFO:handle_command: pre-filling
>>> caller's
>>> address with 72.19.211.106:49622  (Should be callee)
>>>
>>> Then after the ‘ACK’ is received from the Gateway, the H323 call is
>>> mentioned in the syslog as well as the other caller who is supposed to be
>>> the callee. 
>>>
>>> Oct 27 17:33:06 rtpproxy[24086]: INFO:handle_command: pre-filling
>>> caller's
>>> address with 69.72.11.51:10204
>>> Oct 27 17:33:06 rtpproxy[24086]: INFO:handle_command: pre-filling
>>> caller's
>>> address with 69.72.11.51:10214
>>>
>>> Oct 27 17:33:06 rtpproxy[24086]: INFO:handle_command: pre-filling
>>> caller's
>>> address with 72.19.211.106:49620
>>> Oct 27 17:33:06 rtpproxy[24086]: INFO:handle_command: pre-filling
>>> caller's
>>> address with 72.19.211.106:49622
>>>
>>>   
>> _______________________________________________
>> 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
>>
> 


-- 
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671