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
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
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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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:
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@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
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
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
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
General Lee schrieb:
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.
I just took a look at the code and there is a bug in nathelper when using "s" flag on ACK.
Probably rtpproxy_offer/answer should be used:
static int 2417 force_rtp_proxy2_f(struct sip_msg *msg, char *param1, char *param2) 2418 { 2419 int offer; 2420 2421 if (msg->first_line.type == SIP_REQUEST && 2422 msg->first_line.u.request.method_value == METHOD_INVITE) { 2423 offer = 1; 2424 } else if (msg->first_line.type == SIP_REPLY) { 2425 offer = 0; 2426 } else { 2427 return -1; 2428 } 2429 2430 return force_rtp_proxy(msg, param1, param2, offer); 2431 }
if you remove the METHOD_INVITE condition in line 2422 it should work. (make sure you never call force_rtpproxy for other methods)
regards klaus
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:
General Lee schrieb:
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.
I just took a look at the code and there is a bug in nathelper when using "s" flag on ACK.
Probably rtpproxy_offer/answer should be used:
static int 2417 force_rtp_proxy2_f(struct sip_msg *msg, char *param1, char *param2) 2418 { 2419 int offer; 2420 2421 if (msg->first_line.type == SIP_REQUEST && 2422 msg->first_line.u.request.method_value == METHOD_INVITE) { 2423 offer = 1; 2424 } else if (msg->first_line.type == SIP_REPLY) { 2425 offer = 0; 2426 } else { 2427 return -1; 2428 } 2429 2430 return force_rtp_proxy(msg, param1, param2, offer); 2431 }
if you remove the METHOD_INVITE condition in line 2422 it should work. (make sure you never call force_rtpproxy for other methods)
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
I couldn't get it working with the rtpproxy offer/answer but the force_rtp_proxy is working.
Same here. This was concluded from a lengthy thread I initiated on this subject a month or two ago; see the archives. I think this is an accepted conclusion now.
Alex Balashov wrote:
I couldn't get it working with the rtpproxy offer/answer but the force_rtp_proxy is working.
Same here. This was concluded from a lengthy thread I initiated on this subject a month or two ago; see the archives. I think this is an accepted conclusion now.
Although it is rather strange - they are just wrapper functions. Are you using any other "special" flags too?
regards klaus
No.
-- Sent from mobile device
On Dec 4, 2009, at 2:37 AM, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Alex Balashov wrote:
I couldn't get it working with the rtpproxy offer/answer but the force_rtp_proxy is working.
Same here. This was concluded from a lengthy thread I initiated on this subject a month or two ago; see the archives. I think this is an accepted conclusion now.
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:
No.
-- Sent from mobile device
On Dec 4, 2009, at 2:37 AM, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Alex Balashov wrote:
I couldn't get it working with the rtpproxy offer/answer but the force_rtp_proxy is working.
Same here. This was concluded from a lengthy thread I initiated on this subject a month or two ago; see the archives. I think this is an accepted conclusion now.
Although it is rather strange - they are just wrapper functions. Are you using any other "special" flags too?
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
-
Alex Balashov -
General Lee -
Klaus Darilion