From sobomax at sippysoft.com  Thu Jul  2 16:43:06 2009
From: sobomax at sippysoft.com (Maxim Sobolev)
Date: Thu, 02 Jul 2009 16:43:06 -0700
Subject: [RTPproxy Devel] [rtpproxy module] set_rtp_proxy_set() to allow
 pv	as parameter
In-Reply-To: <200906061540.06711.ibc@aliax.net>
References: <200906061540.06711.ibc@aliax.net>
Message-ID: <4A4D460A.1090203@sippysoft.com>

I?aki Baz Castillo wrote:
> So, in conclusion, is there any aim in improving RtpProxy module to allow real 
> and robust load-balancing? What about multiple rtpproxy instances in the same 
> set? is it really usable?
> 
> Thanks a lot for any comment on it.

Inaki,

What you have suggested is very reasonable and it would be a welcome 
addition to the nathelper module. The only problem is that I am quite 
overloaded with other stuff (and it's not going to improve in the next 
3-4 months) and also not very motivated to implement this functionality 
by myself. Therefore, if you want to work on implementing this feature 
please go ahead. I will try to provide whatever help is necessary to 
integrate you work when it's ready.

Regards,

-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
MSN: sales at sippysoft.com
Skype: SippySoft


From ibc at aliax.net  Fri Jul  3 00:54:24 2009
From: ibc at aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Fri, 3 Jul 2009 09:54:24 +0200
Subject: [RTPproxy Devel]
 =?utf-8?q?=5Brtpproxy_module=5D_set=5Frtp=5Fprox?=
 =?utf-8?q?y=5Fset=28=29_to_allow_pv=09as_parameter?=
In-Reply-To: <4A4D460A.1090203@sippysoft.com>
References: <200906061540.06711.ibc@aliax.net> <4A4D460A.1090203@sippysoft.com>
Message-ID: <200907030954.24404.ibc@aliax.net>

El Viernes, 3 de Julio de 2009, Maxim Sobolev escribi?:
> I?aki Baz Castillo wrote:
> > So, in conclusion, is there any aim in improving RtpProxy module to allow
> > real and robust load-balancing? What about multiple rtpproxy instances in
> > the same set? is it really usable?
> >
> > Thanks a lot for any comment on it.
>
> Inaki,
>
> What you have suggested is very reasonable and it would be a welcome
> addition to the nathelper module. The only problem is that I am quite
> overloaded with other stuff (and it's not going to improve in the next
> 3-4 months) and also not very motivated to implement this functionality
> by myself. Therefore, if you want to work on implementing this feature
> please go ahead. I will try to provide whatever help is necessary to
> integrate you work when it's ready.

Ok Maxim, I'll take a look when I get some time.



-- 
I?aki Baz Castillo <ibc at aliax.net>


From ibc at aliax.net  Mon Jul  6 09:39:36 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Mon, 6 Jul 2009 18:39:36 +0200
Subject: [RTPproxy Devel] About recorded RTP files
Message-ID: <cc1f582e0907060939o3b5116a3i6ffe2321053af252@mail.gmail.com>

Hi, I'm using start_recording() function of nathelper module. I use
"-R" option in rtpproxy daemon in order not to record RTCP.
start_recording() is called in route and onreply_route.

After the call ends I see the following files in the recording directory:

283K 2009-07-06 13:41
1e54fbae418504a40744ad765718792a at 212.230.19.1=38a3b929-co1782-INS001;1.a.rtp
275K 2009-07-06 13:41
1e54fbae418504a40744ad765718792a at 212.230.19.1=38a3b929-co1782-INS001;1.o.rtp
    0 2009-07-06 13:41
1e54fbae418504a40744ad765718792a at 212.230.19.1=38a3b929-co1782-INS001;2.a.rtp
    0 2009-07-06 13:41
1e54fbae418504a40744ad765718792a at 212.230.19.1=38a3b929-co1782-INS001;2.o.rtp

Some questions:

- "1.a.rtp" is one direction and "1.o.rtp" the other, right?

- What are the last two files? In this case they are 0 length, but in
longer calls the are some bytes length.


PS: Is there any way to start the recording when 200 OK arrives (so
early media is not recorded)?
I cannot imagine how to do it since "start_recording()" must be called
in the INVITE request (and also in the response).

Thanks a lot.


-- 
I?aki Baz Castillo
<ibc at aliax.net>


From sobomax at sippysoft.com  Tue Jul  7 04:43:06 2009
From: sobomax at sippysoft.com (Maxim Sobolev)
Date: Tue, 07 Jul 2009 04:43:06 -0700
Subject: [RTPproxy Devel] About recorded RTP files
In-Reply-To: <cc1f582e0907060939o3b5116a3i6ffe2321053af252@mail.gmail.com>
References: <cc1f582e0907060939o3b5116a3i6ffe2321053af252@mail.gmail.com>
Message-ID: <4A5334CA.5030807@sippysoft.com>

I?aki Baz Castillo wrote:
> Hi, I'm using start_recording() function of nathelper module. I use
> "-R" option in rtpproxy daemon in order not to record RTCP.
> start_recording() is called in route and onreply_route.
> 
> After the call ends I see the following files in the recording directory:
> 
> 283K 2009-07-06 13:41
> 1e54fbae418504a40744ad765718792a at 212.230.19.1=38a3b929-co1782-INS001;1.a.rtp
> 275K 2009-07-06 13:41
> 1e54fbae418504a40744ad765718792a at 212.230.19.1=38a3b929-co1782-INS001;1.o.rtp
>     0 2009-07-06 13:41
> 1e54fbae418504a40744ad765718792a at 212.230.19.1=38a3b929-co1782-INS001;2.a.rtp
>     0 2009-07-06 13:41
> 1e54fbae418504a40744ad765718792a at 212.230.19.1=38a3b929-co1782-INS001;2.o.rtp
> 
> Some questions:
> 
> - "1.a.rtp" is one direction and "1.o.rtp" the other, right?

Yes, that's right. Those are streams in two different directions. If my 
memory serves, ".a.rtp" is stream from caller, while ".o.rtp" is stream 
from callee. By the way, you might want to check PCAP recording instead 
of recording in custom format ("-P" option). It's little less compact 
but allows using third-party tools to analyze and decode streams.

> - What are the last two files? In this case they are 0 length, but in
> longer calls the are some bytes length.

Those should be files for the second stream in media session (video?). 
If you don't have video enabled then something is wrong, it would help 
if you can send SDP of the offer and SDP of the corresponding answer.

> PS: Is there any way to start the recording when 200 OK arrives (so
> early media is not recorded)?
> I cannot imagine how to do it since "start_recording()" must be called
> in the INVITE request (and also in the response).

Yes, you are correct. The current nathelper API doesn't allow this to be 
done. What we can do in this regard, is to implement some flag for 
start_recording() to request recording of stream going in different 
direction, so that you can do two subsequent calls in the 200 OK 
handler, one with that flag and one without. Should be trivial thing to 
do - just swap out to/from tags before passing them to the RTPproxy. I 
will take a look in the next few days if nobody beats me on that.

Regards,
-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
MSN: sales at sippysoft.com
Skype: SippySoft


From ibc at aliax.net  Tue Jul  7 06:52:02 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Tue, 7 Jul 2009 15:52:02 +0200
Subject: [RTPproxy Devel] About recorded RTP files
In-Reply-To: <4A5334CA.5030807@sippysoft.com>
References: <cc1f582e0907060939o3b5116a3i6ffe2321053af252@mail.gmail.com>
	<4A5334CA.5030807@sippysoft.com>
Message-ID: <cc1f582e0907070652y54ef66c5x8179644886abd1eb@mail.gmail.com>

2009/7/7 Maxim Sobolev <sobomax at sippysoft.com>:
>> - "1.a.rtp" is one direction and "1.o.rtp" the other, right?
>
> Yes, that's right. Those are streams in two different directions. If my
> memory serves, ".a.rtp" is stream from caller, while ".o.rtp" is stream
> from callee. By the way, you might want to check PCAP recording instead
> of recording in custom format ("-P" option). It's little less compact
> but allows using third-party tools to analyze and decode streams.

Yes, I'm already using -P option :)
However, the manpage of rtpproxy is not updated about the -P option.


>> - What are the last two files? In this case they are 0 length, but in
>> longer calls the are some bytes length.
>
> Those should be files for the second stream in media session (video?).
> If you don't have video enabled then something is wrong, it would help
> if you can send SDP of the offer and SDP of the corresponding answer.

You are right, there is video in the SDP offer (but not in the response):

SDP offer:
--------------------
v=0
o=- 732835142 732835142 IN IP4 222.220.5.228
s=ENSResip
c=IN IP4 222.220.32.79
t=0 0
m=audio 32624 RTP/AVP 0 18 8 3 101
a=fmtp:18 annexb=no
a=fmtp:101 0-16
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=sendrecv
m=video 32620 RTP/AVP 34 103 99
a=rtpmap:34 H263/90000
a=rtpmap:103 H263-1998/90000
a=rtpmap:99 H264/90000
a=nortpproxy:yes
-------------------------

SDP response:
-------------------------
v=0
o=- 1249125920 1249125920 IN IP4 222.220.5.228
s=ENSResip
c=IN IP4 222.220.5.232
t=0 0
m=audio 21044 RTP/AVP 0 101
a=fmtp:101 0-15
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
-------------------------



>> PS: Is there any way to start the recording when 200 OK arrives (so
>> early media is not recorded)?
>> I cannot imagine how to do it since "start_recording()" must be called
>> in the INVITE request (and also in the response).
>
> Yes, you are correct. The current nathelper API doesn't allow this to be
> done. What we can do in this regard, is to implement some flag for
> start_recording() to request recording of stream going in different
> direction, so that you can do two subsequent calls in the 200 OK
> handler, one with that flag and one without. Should be trivial thing to
> do - just swap out to/from tags before passing them to the RTPproxy. I
> will take a look in the next few days if nobody beats me on that.

It would be really nice :)


-- 
I?aki Baz Castillo
<ibc at aliax.net>


From ibc at aliax.net  Fri Jul 17 04:52:06 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Fri, 17 Jul 2009 13:52:06 +0200
Subject: [RTPproxy Devel] Bug in /etc/init.d/rtpproxy
Message-ID: <cc1f582e0907170452u73d66ab5m93e7f5f5c2899ff2@mail.gmail.com>

Hi, /etc/init.d/rtpproxy has these lines:

------------------
MYNAME=`basename $0`
MYCFG="/etc/default/${MYNAME}"
-------------------

When the system starts the /etc/default/rtpproxy file is NOT loaded.
I've discovered the bug by adding the following the following line:

------------------
MYNAME=`basename $0`
MYCFG="/etc/default/${MYNAME}"
echo "$(date):  MYNAME = ${MYNAME}" >> /root/rtpproxy.init.log
-------------------


I've restarted the system and this is the content of /root/rtpproxy.init.log:

  Fri Jul 17 13:43:37 CEST 2009:  MYNAME = K20rtpproxy
  Fri Jul 17 13:46:09 CEST 2009:  MYNAME = S20rtpproxy

If later I restart manually by typing "/etc/init.d/rtpproxy restart" then I see:

  vie jul 17 13:42:57 CEST 2009:  MYNAME = rtpproxy
  vie jul 17 13:43:09 CEST 2009:  MYNAME = rtpproxy

The issue occurs due to tha fact that init scripts are executed by
init process calling the *links* in /etc/rc2.d !!!


So I propose to change the current code:
------------------
MYNAME=`basename $0`
MYCFG="/etc/default/${MYNAME}"
-------------------

by:

------------------
MYCFG="/etc/default/${NAME}"
-------------------



-- 
I?aki Baz Castillo
<ibc at aliax.net>


From emmanuel.buu at ives.fr  Fri Jul 31 02:56:41 2009
From: emmanuel.buu at ives.fr (Emmanuel BUU)
Date: Fri, 31 Jul 2009 11:56:41 +0200
Subject: [RTPproxy Devel] Automatic bridging for RTP proxy and advertised
 address for external NAT
Message-ID: <4A72BFD9.50305@ives.fr>

Hello everybody,

I would like to submit two enhancement proposal for the RTPproxy software:

1/ automatic bridging handling

RTP proxy can be run in bridged mode. With the -l IP1/IP2 option, it
can mediate between two unrelated networks (e.g. a private network and
the public Internet) by running on a host with two network interfaces on 
each ot them. In that case, the SIP proxy that controls rtp proxy
need to determine whether the packet is coming from the internal network 
or the external network then send a the proper command to the RTP proxy 
through the protocol.

I propose to enhance rtp proxy so that this network routing is done 
inside the rtpproxy software itself:

The idea would be to describe the internal network (IP / mask, bind
address) in the RTP proxy configuration. When a "create session" or 
"update session" command would arrive, the the IP address and port 
present in the command frame would be compared against the internal 
network definition. The proxy would then able to know if the SIP packet
comes from the internal network or the external network. The proxy would 
then open the UDP socket on the correct bind address and send it to the 
correct network interface.

We would keep the 'E' and 'I' mode for backward compatibility if 'E' and 
'I' would not be specified, this automated selection would occur.

Ultimately, the configuration of RTP proxy could be automated by 
scanbing the IP routing tables of the host.


2/ External NAT handling

I would also to handle the case where RTP proxy is behind a NAT (one to
one NAT). If the communication is on the internal network then the
previous processing is applied. If the communication is to be done with 
the external network, rtp proxy would bind to the same interface but 
advertise the NATed adress in the answer.

We propose to implement these two enhancements but would like to agree 
with the rtp maintainer in order to have a chance to push this into the 
open source. This lead me to  another question. RTPProxy has currently 
no configuration file. Would the crowd here consider such an addition to 
describe the networks (and maybe the port range)?

What config library would you favor?


Emmanuel BUU
IVeS
http://www.ives.fr/




From sobomax at sippysoft.com  Fri Jul 31 15:06:13 2009
From: sobomax at sippysoft.com (Maxim Sobolev)
Date: Fri, 31 Jul 2009 15:06:13 -0700
Subject: [RTPproxy Devel] Automatic bridging for RTP proxy and
 advertised address for external NAT
In-Reply-To: <4A72BFD9.50305@ives.fr>
References: <4A72BFD9.50305@ives.fr>
Message-ID: <4A736AD5.5090907@sippysoft.com>

Emmanuel,

Thank you for your message. Please see my comments in-line below.

Emmanuel BUU wrote:
> Hello everybody,
> 
> I would like to submit two enhancement proposal for the RTPproxy software:
> 
> 1/ automatic bridging handling
> 
> RTP proxy can be run in bridged mode. With the -l IP1/IP2 option, it
> can mediate between two unrelated networks (e.g. a private network and
> the public Internet) by running on a host with two network interfaces on 
> each ot them. In that case, the SIP proxy that controls rtp proxy
> need to determine whether the packet is coming from the internal network 
> or the external network then send a the proper command to the RTP proxy 
> through the protocol.
> 
> I propose to enhance rtp proxy so that this network routing is done 
> inside the rtpproxy software itself:
> 
> The idea would be to describe the internal network (IP / mask, bind
> address) in the RTP proxy configuration. When a "create session" or 
> "update session" command would arrive, the the IP address and port 
> present in the command frame would be compared against the internal 
> network definition. The proxy would then able to know if the SIP packet
> comes from the internal network or the external network. The proxy would 
> then open the UDP socket on the correct bind address and send it to the 
> correct network interface.
> 
> We would keep the 'E' and 'I' mode for backward compatibility if 'E' and 
> 'I' would not be specified, this automated selection would occur.
> 
> Ultimately, the configuration of RTP proxy could be automated by 
> scanbing the IP routing tables of the host.

This feature is already supported in our private development tree (IPv4 
only for now) and it will be released soon. It would require matching 
changes on the part of SER/Kamalio/OpenSIPS/B2BUA as well as IPv6 
support, which what holds it at the moment.

> 2/ External NAT handling
> 
> I would also to handle the case where RTP proxy is behind a NAT (one to
> one NAT). If the communication is on the internal network then the
> previous processing is applied. If the communication is to be done with 
> the external network, rtp proxy would bind to the same interface but 
> advertise the NATed adress in the answer.
> 
> We propose to implement these two enhancements but would like to agree 
> with the rtp maintainer in order to have a chance to push this into the 
> open source. This lead me to  another question. RTPProxy has currently 
> no configuration file. Would the crowd here consider such an addition to 
> describe the networks (and maybe the port range)?
> 
> What config library would you favor?

Yes, RTPproxy really needs a configuration file, this is something on my 
list of features for 2.0 as well. I don't have any strong preference for 
config library, however it should meet the few basic criteria:

1. BSD-like license. Apache, Mozilla, MIT are fine. No GPL/LGPL.

2. Clean interface and internal representation. Ability to have 
different contexts.

3. Ability to handle on-the-fly config file reload gracefully.

So, feel free if you want to suggest and discuss something or even want 
to make a code submission.

I look foward to hearing from you.

Sincerely,
-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
MSN: sales at sippysoft.com
Skype: SippySoft


From emmanuel.buu at ives.fr  Fri Jul 31 15:36:39 2009
From: emmanuel.buu at ives.fr (Emmanuel BUU)
Date: Sat, 01 Aug 2009 00:36:39 +0200
Subject: [RTPproxy Devel] Automatic bridging for RTP proxy and
 advertised address for external NAT
In-Reply-To: <4A736AD5.5090907@sippysoft.com>
References: <4A72BFD9.50305@ives.fr> <4A736AD5.5090907@sippysoft.com>
Message-ID: <4A7371F7.7010200@ives.fr>

Maxim Sobolev a ?crit :
> Emmanuel,
>
> Thank you for your message. Please see my comments in-line below.
>
> Emmanuel BUU wrote:
>   
>> Hello everybody,
>>
>> I would like to submit two enhancement proposal for the RTPproxy software:
>>
>> 1/ automatic bridging handling
>>
>> (...)
>>
>> Ultimately, the configuration of RTP proxy could be automated by 
>> scanbing the IP routing tables of the host.
>>     
>
> This feature is already supported in our private development tree (IPv4 
> only for now) and it will be released soon. It would require matching 
> changes on the part of SER/Kamalio/OpenSIPS/B2BUA as well as IPv6 
> support, which what holds it at the moment.
>
>   
Hum great, maybe I can help with the NATHELPER module of OpenSIPS if you 
describe me what change have been made to the RTP proxy control protocol 
and provide me access to the source code.

>> 2/ External NAT handling
>>
>> I would also to handle the case where RTP proxy is behind a NAT (one to
>> one NAT). If the communication is on the internal network then the
>> previous processing is applied. If the communication is to be done with 
>> the external network, rtp proxy would bind to the same interface but 
>> advertise the NATed adress in the answer.
>>     
What about this case? Is there a way to handle external NAT by pairing 
some interface witn an external advertised address ?
>> We propose to implement these two enhancements but would like to agree 
>> with the rtp maintainer in order to have a chance to push this into the 
>> open source. This lead me to  another question. RTPProxy has currently 
>> no configuration file. Would the crowd here consider such an addition to 
>> describe the networks (and maybe the port range)?
>>
>> What config library would you favor?
>>     
>
> Yes, RTPproxy really needs a configuration file, this is something on my 
> list of features for 2.0 as well. I don't have any strong preference for 
> config library, however it should meet the few basic criteria:
>
> 1. BSD-like license. Apache, Mozilla, MIT are fine. No GPL/LGPL.
>
> 2. Clean interface and internal representation. Ability to have 
> different contexts.
>
> 3. Ability to handle on-the-fly config file reload gracefully.
>
> So, feel free if you want to suggest and discuss something or even want 
> to make a code submission.
>   
Few !! These are proper requirements. Why is GPL not accepted? I thought 
that rtpproxy was GPL also?
Or maybe there is an intellectual propery issue?

Ok I did not find any of these compling the 3 requirements. Req #3 is 
tough ...
> I look foward to hearing from you.
>
> Sincerely,
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rtpproxy.org/pipermail/devel/attachments/20090801/ace31aa8/attachment.html 

From emmanuel.buu at ives.fr  Wed Jul 29 15:28:18 2009
From: emmanuel.buu at ives.fr (Emmanuel BUU)
Date: Thu, 30 Jul 2009 00:28:18 +0200
Subject: [RTPproxy Devel] Automatic bridging for RTP proxy and advertised
 address for external NAT
Message-ID: <4A70CD02.9090603@ives.fr>

Hello everybody,

I would like to submit two enhancement proposal for the RTPproxy software:

1/ automatic bridging handling

RTP proxy can be run in bridged mode. With the -l IP1/IP2 option, one 
can mediate between two unrelated networks (e.g. a private network and 
the public Internet) by running the rtpproxy software on a host with two 
nework interface with each of it connected to the neworks. It is the SIP 
proxy that needs to deterline wether the packet is coming from the 
internal network or the
external network and pass it on to the RTP proxy through the protocol.

I propose that this determination is done inside the rtpproxy software. 
The idea would be describe the internal nework (IP / mask, bind 
address). When a create or update command would
arrive, ithe the IP and port to be contacted present in the comand frame 
would be compared against the internal nework definition. Therefor, RTP 
proxy create the socket on the right bind address
and provide it in the asnwer. If the IP provided in the commande does 
not match the internal network definition, it is considered to be on the 
external network.

2/ External nat handling

I would also to handle the case where RTP proxy is behind a NAT (one to 
one NAT). If the communication is on the internal network then the 
previous processing is applied
if the communication is to be done with the external network, rtp proxy 
would bind to the same interface but advertise the NATed adress in the 
asnwer.

We propose to implement these two enhancements and this lead me to 
another question. RTPProxy has currently no configuration file. Would 
the crowd here consider an addition ?

Emmanuel BUU
IVeS
http://www.ives.fr/