Re: [RTPproxy Users] Kamilio integration with rtpproxy

2008-12-01 Thread Joan
2008/12/1 Maxim Sobolev [EMAIL PROTECTED]:
 Joan,

 Were there any other calls going through the machine at the very same
 time? For some reason the RTPproxy was unable to locate any spare port,
 do you run any other software that use lot of UDP ports on that machine?

This is a testing environment, the only calls in the system are the
ones I'm doing, and there's only a single phone registered to to the
calls.
There's no much more on the machine other than a apache to manage the
phpmyadmin...


 Can you please send output of the netstat -uap command?

Proto Recv-Q Send-Q Local Address   Foreign Address
State   PID/Program name
udp0  0 localhost:46090 localhost:15000
ESTABLISHED 31163/kamailio
udp0  0 localhost:15000 *:*
 31180/rtpproxy
udp0  0 localhost:34863 localhost:15000
ESTABLISHED 31171/kamailio
udp0  0 localhost:34742 localhost:15000
ESTABLISHED 31165/kamailio
udp0  0 localhost:47033 localhost:15000
ESTABLISHED 31172/kamailio
udp0  0 localhost:35262 localhost:15000
ESTABLISHED 31170/kamailio
udp0  0 localhost:41407 localhost:15000
ESTABLISHED 31168/kamailio
udp0  0 192.168.253.98:sip  *:*
 31162/kamailio
udp0  0 localhost:sip   *:*
 31162/kamailio
udp0  0 localhost:42181 localhost:15000
ESTABLISHED 31174/kamailio
udp0  0 localhost:41813 localhost:15000
ESTABLISHED 31166/kamailio
udp0  0 localhost:55255 localhost:15000
ESTABLISHED 31164/kamailio
udp0  0 localhost:42585 localhost:15000
ESTABLISHED 31167/kamailio



 Joan wrote:
 2008/11/28 Maxim Sobolev [EMAIL PROTECTED]:
 Joan wrote:
 2008/11/28 Maxim Sobolev [EMAIL PROTECTED]:
 Joan wrote:
 DBUG:handle_command: received command 9506_2 U
 [EMAIL PROTECTED] 192.168.253.12 16434
 f0cdb2c2aee55197o0;1
 INFO:handle_command: new session [EMAIL PROTECTED], tag
 f0cdb2c2aee55197o0;1 requested, type strong
 ERR:handle_command: can't create listener
 DBUG:doreply: sending reply 9506_2 E10
 That's weird. The only case when the RTPproxy can fail like this is when
 it cannot allocate a UDP ports for the session, either due to ports
 already taken by other application or due to kernel not allowing to use
 any ports in the specified range (EADDRINUSE or EACCES). Can you please
 answer the following questions to help me identify the issue:

 1. Did you make any changes to the sources or defines?

 No, the only change I made was with the include, the one already
 commited into trunk.
 Currently I've built from a clean cvs up
 OK, can you please apply the attached patch, recompile, restart and send the
 error output again.

 Here it is ...

 Regards,
 --
 Maksym Sobolyev
 Sippy Software, Inc.
 Internet Telephony (VoIP) Experts
 T/F: +1-646-651-1110
 Web: http://www.sippysoft.com
 MSN: [EMAIL PROTECTED]
 Skype: SippySoft
 ___
 Users mailing list
 Users@rtpproxy.org
 http://lists.rtpproxy.org/mailman/listinfo/users

___
Users mailing list
Users@rtpproxy.org
http://lists.rtpproxy.org/mailman/listinfo/users


Re: [RTPproxy Users] Kamilio integration with rtpproxy

2008-11-25 Thread Joan
2008/11/24 Klaus Darilion [EMAIL PROTECTED]:
 Hi Joan!

 I suggest to create an openser config with the wizard on sipwise.com.
 Then analyze this config and you will learn how to apply nat traversal
 and use rtpproxy.

Ok, as Klaus have suggested, I've generated the configuration (also
with the pattern to route outgoing trough PSTN), and same thing
happens ...

From the logs:
/usr/sbin/kamailio[8755]: Callee is not local - M=INVITE
RURI=sip:[EMAIL PROTECTED] F=sip:[EMAIL PROTECTED]
T=sip:[EMAIL PROTECTED] IP=192.168.253.12
[EMAIL PROTECTED]
/usr/sbin/kamailio[8755]: DBG:nathelper:force_rtp_proxy2_f: proxy reply: E10
/usr/sbin/kamailio[8755]: ERROR:nathelper:force_rtp_proxy2_f:
incorrect port 0 in reply from rtp proxy

As I see, doesn't matter the logic I use for routing (altought the
sipwise, must be better that mine at this point), rtpproxy always
returns me a E10.

 regards
 klaus

 Joan schrieb:
 2008/11/21 Maxim Sobolev [EMAIL PROTECTED]:
 Joan,

 The problem seems to be in unbalanced force_rtp_proxy() - which means
 that you don't invoke force_rtp_proxy() on INVITE, but call it on
 response. This is not allowed, since you would have one way audio in
 such case.

 In your script you call force_rtp_proxy() on INVITEs only in the case if
 isbflagset(2) is set, while call it on responses if nat_uac_test(19)
 returns true on 200 OK. Is it possible that INVITE won't have bflag 9
 set, while 200 OK response would trigger nat_uac_test(19). You should
 either fix your NAT detection logic, or use separate onreply blocks for
 the cases when you have called force_rtp_proxy() on INVITE and for the
 case when you have not.
 Hello, until this morning I haven't been able to modify any
 configuration, what I did basically, is to use nat_uac_test(19) in
 both places.

if (is_method(INVITE)) {
 +  if(nat_uac_test(19)) {
 -   if(isbflagset(2)) {##  # behind a NAT
log(MIS: Forcing proxy within router 1)
force_rtp_proxy();
};

 Watching the logs it seems that nat i detected properly during the
 INVITE and the force_rtp_proxy is called for the outgoing call, but
 rtpproxy gives back an answer that kamailio doesn't recognize.
 I could't find any reference to this value neither.

 Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]: MIS: Forcing proxy
 within router 1
 Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
 DBG:core:parse_headers: flags=
 Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
 DBG:core:get_hdr_field: content_length=399
 Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
 DBG:core:get_hdr_field: found end of header
 Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
 DBG:nathelper:check_content_type: type application/sdp found valid
 Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
 DBG:core:parse_headers: flags=40
 Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
 DBG:nathelper:force_rtp_proxy2_f: proxy reply: E10
 Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
 ERROR:nathelper:force_rtp_proxy2_f: incorrect port 0 in reply from rtp
 proxy


 Regards
 ___
 Users mailing list
 Users@rtpproxy.org
 http://lists.rtpproxy.org/mailman/listinfo/users
 ___
 Users mailing list
 Users@rtpproxy.org
 http://lists.rtpproxy.org/mailman/listinfo/users



kamailio.cfg
Description: Binary data
___
Users mailing list
Users@rtpproxy.org
http://lists.rtpproxy.org/mailman/listinfo/users


Re: [RTPproxy Users] Kamilio integration with rtpproxy

2008-11-25 Thread Maxim Sobolev
Joan,

The E10 means that the proxy was not able to open ports for 
sending/receiving RTP traffic on. Can you please run the rtpproxy in 
foreground (-f command line switch) and post log output here. This would 
help a lot to diagnose the issue.

Joan wrote:
 2008/11/24 Klaus Darilion [EMAIL PROTECTED]:
 Hi Joan!

 I suggest to create an openser config with the wizard on sipwise.com.
 Then analyze this config and you will learn how to apply nat traversal
 and use rtpproxy.

 Ok, as Klaus have suggested, I've generated the configuration (also
 with the pattern to route outgoing trough PSTN), and same thing
 happens ...
 
From the logs:
 /usr/sbin/kamailio[8755]: Callee is not local - M=INVITE
 RURI=sip:[EMAIL PROTECTED] F=sip:[EMAIL PROTECTED]
 T=sip:[EMAIL PROTECTED] IP=192.168.253.12
 [EMAIL PROTECTED]
 /usr/sbin/kamailio[8755]: DBG:nathelper:force_rtp_proxy2_f: proxy reply: E10
 /usr/sbin/kamailio[8755]: ERROR:nathelper:force_rtp_proxy2_f:
 incorrect port 0 in reply from rtp proxy
 
 As I see, doesn't matter the logic I use for routing (altought the
 sipwise, must be better that mine at this point), rtpproxy always
 returns me a E10.

Regards,
-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
MSN: [EMAIL PROTECTED]
Skype: SippySoft
___
Users mailing list
Users@rtpproxy.org
http://lists.rtpproxy.org/mailman/listinfo/users


Re: [RTPproxy Users] Kamilio integration with rtpproxy

2008-11-25 Thread Joan
2008/11/25 Maxim Sobolev [EMAIL PROTECTED]:
 Joan,

 The E10 means that the proxy was not able to open ports for
 sending/receiving RTP traffic on. Can you please run the rtpproxy in
 foreground (-f command line switch) and post log output here. This would
 help a lot to diagnose the issue.

I start the proxy like this:
rtpproxy -s udp:127.0.0.1:15000 -f -u kamailio -l 192.168.253.98

Rtpproxy can bind to port 15000 and the user/ip are also right. System
is a debian lenny with kernel 2.6.26

The log is the following (after starting kamailio with 2 children only) :
INFO:main: rtpproxy started, pid 9489
DBUG:handle_command: received command 9505_0 V
DBUG:doreply: sending reply 9505_0 20040107

DBUG:handle_command: received command 9505_1 VF 20050322
DBUG:doreply: sending reply 9505_1 1

DBUG:handle_command: received command 9504_0 V
DBUG:doreply: sending reply 9504_0 20040107

DBUG:handle_command: received command 9506_0 V
DBUG:doreply: sending reply 9506_0 20040107

DBUG:handle_command: received command 9507_0 V
DBUG:doreply: sending reply 9507_0 20040107

DBUG:handle_command: received command 9508_0 V
DBUG:doreply: sending reply 9508_0 20040107

DBUG:handle_command: received command 9509_0 V
DBUG:doreply: sending reply 9509_0 20040107

DBUG:handle_command: received command 9511_0 V
DBUG:doreply: sending reply 9511_0 20040107

DBUG:handle_command: received command 9504_1 VF 20050322
DBUG:doreply: sending reply 9504_1 1

DBUG:handle_command: received command 9506_1 VF 20050322
DBUG:doreply: sending reply 9506_1 1

DBUG:handle_command: received command 9507_1 VF 20050322
DBUG:doreply: sending reply 9507_1 1

DBUG:handle_command: received command 9509_1 VF 20050322
DBUG:doreply: sending reply 9509_1 1

DBUG:handle_command: received command 9511_1 VF 20050322
DBUG:doreply: sending reply 9511_1 1

DBUG:handle_command: received command 9508_1 VF 20050322
DBUG:doreply: sending reply 9508_1 1

DBUG:handle_command: received command 9513_0 V
DBUG:doreply: sending reply 9513_0 20040107

DBUG:handle_command: received command 9512_0 V
DBUG:doreply: sending reply 9512_0 20040107

DBUG:handle_command: received command 9516_0 V
DBUG:doreply: sending reply 9516_0 20040107

DBUG:handle_command: received command 9512_1 VF 20050322
DBUG:doreply: sending reply 9512_1 1

DBUG:handle_command: received command 9513_1 VF 20050322
DBUG:doreply: sending reply 9513_1 1

DBUG:handle_command: received command 9516_1 VF 20050322
DBUG:doreply: sending reply 9516_1 1

DBUG:handle_command: received command 9506_2 U
[EMAIL PROTECTED] 192.168.253.12 16434
f0cdb2c2aee55197o0;1
INFO:handle_command: new session [EMAIL PROTECTED], tag
f0cdb2c2aee55197o0;1 requested, type strong
ERR:handle_command: can't create listener
DBUG:doreply: sending reply 9506_2 E10

DBUG:handle_command: received command 9507_2 L
[EMAIL PROTECTED] 192.168.253.2 15660
f0cdb2c2aee55197o0;1 as0bd2d3ae;1
INFO:handle_command: lookup request failed: session
[EMAIL PROTECTED], tags f0cdb2c2aee55197o0;1/as0bd2d3ae;1
not found
DBUG:doreply: sending reply 9507_2 0 192.168.253.98

DBUG:handle_command: received command 9507_3 D
[EMAIL PROTECTED] as0bd2d3ae f0cdb2c2aee55197o0
INFO:handle_command: delete request failed: session
[EMAIL PROTECTED], tags as0bd2d3ae/f0cdb2c2aee55197o0 not
found
DBUG:doreply: sending reply 9507_3 E8

___
Users mailing list
Users@rtpproxy.org
http://lists.rtpproxy.org/mailman/listinfo/users


Re: [RTPproxy Users] Kamilio integration with rtpproxy

2008-11-24 Thread Joan
2008/11/21 Maxim Sobolev [EMAIL PROTECTED]:
 Joan,

 The problem seems to be in unbalanced force_rtp_proxy() - which means
 that you don't invoke force_rtp_proxy() on INVITE, but call it on
 response. This is not allowed, since you would have one way audio in
 such case.

 In your script you call force_rtp_proxy() on INVITEs only in the case if
 isbflagset(2) is set, while call it on responses if nat_uac_test(19)
 returns true on 200 OK. Is it possible that INVITE won't have bflag 9
 set, while 200 OK response would trigger nat_uac_test(19). You should
 either fix your NAT detection logic, or use separate onreply blocks for
 the cases when you have called force_rtp_proxy() on INVITE and for the
 case when you have not.
Hello, until this morning I haven't been able to modify any
configuration, what I did basically, is to use nat_uac_test(19) in
both places.

   if (is_method(INVITE)) {
+  if(nat_uac_test(19)) {
-   if(isbflagset(2)) {##  # behind a NAT
   log(MIS: Forcing proxy within router 1)
   force_rtp_proxy();
   };

Watching the logs it seems that nat i detected properly during the
INVITE and the force_rtp_proxy is called for the outgoing call, but
rtpproxy gives back an answer that kamailio doesn't recognize.
I could't find any reference to this value neither.

Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]: MIS: Forcing proxy
within router 1
Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
DBG:core:parse_headers: flags=
Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
DBG:core:get_hdr_field: content_length=399
Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
DBG:core:get_hdr_field: found end of header
Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
DBG:nathelper:check_content_type: type application/sdp found valid
Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
DBG:core:parse_headers: flags=40
Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
DBG:nathelper:force_rtp_proxy2_f: proxy reply: E10
Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
ERROR:nathelper:force_rtp_proxy2_f: incorrect port 0 in reply from rtp
proxy


Regards
___
Users mailing list
Users@rtpproxy.org
http://lists.rtpproxy.org/mailman/listinfo/users


Re: [RTPproxy Users] Kamilio integration with rtpproxy

2008-11-20 Thread Maxim Sobolev
Joan wrote:
 Hello, I've been trying to setup a testing scenario to offer voip services.
 At this point I've a phone behind a nat, and I am trying to
 communicate to the openser, that in turns forwards the calls to an
 asterisk server.
 Before nating the phone and starting with the rtpproxy everything was
 working properly.
 The current scenario would be:
 IP Phone (192.168.2.50) - NAT server masking as 192.168.253.12)
 - Kamailio (192.168.253.98) - Asterisk (192.168.253.2)
 
 The working scenario was:
 IP Phone 192.168.253.25 - Kamailio (192.168.253.98) - Asterisk
 (192.168.253.2)
 
 I've configured everthing in kamailio as the examples I saw, but I
 suspect there's something wrong with my rtpproxy (I'm using
 rtpproxy-1.2.alpha.20081104)
 The fact is that when I sniff the traffic in localhost, having started
 rtpproxy as rtpproxy -s udp:localhost 15000 -f -u openser -l
 192.168.253.98 
 
 ###
 test:~# ngrep -lqtt -W byline port 15000 -d lo
 interface: lo (127.0.0.0/255.0.0.0)
 filter: (ip or ip6) and ( port 15000 )
 
 U 2008/11/20 16:46:13.466299 127.0.0.1:59654 - 127.0.0.1:15000
 19694_4 L [EMAIL PROTECTED] 192.168.253.2 17790
 4e178bc90eb3861o0;1 as64b2e8a6;1
 
 U 2008/11/20 16:46:13.466376 127.0.0.1:15000 - 127.0.0.1:59654
 19694_4 0 192.168.253.98
 ###
 
 I see that rtpproxy is returning 0 to the openser doesn't like it and
 it says ERROR:nathelper:force_rtp_proxy2_f: incorrect port 0 in reply
 from rtp proxy
 
 Do i have a broken rtpproxy, or it's a matter of configuration?

Joan,

It looks like misconfiguration to me, can you please send your 
openser.cfg config?

Regards,
-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
MSN: [EMAIL PROTECTED]
Skype: SippySoft
___
Users mailing list
Users@rtpproxy.org
http://lists.rtpproxy.org/mailman/listinfo/users