From stefan.sayer at iptego.com Wed Jul 9 14:32:59 2008 From: stefan.sayer at iptego.com (Stefan Sayer) Date: Wed, 09 Jul 2008 23:32:59 +0200 Subject: [RTPproxy Devel] rtpproxy - transcoder patch Message-ID: <48752E8B.9000004@iptego.com> [sorry if you receive this mail multiple times on multiple mailing list - I thought people on (open)serdev might be interested, but not necessarily subscribed to rtpproxy lists] Hello, some time back Atle and me did a small hack to rtpproxy and nathelper so it could use the codecs from SEMS[1] to transcode RTP from one codec into another in the rtpproxy. Unfortunately we never had or spent the time to get this further than proof-of-concept. That is, iirc the rtpproxy part is quite ok, but the nathelper patch could need some eyes over it. As recently someone asked again about it, we thought we would just release the code as it is, so if there is anyone interested she or he could take the code, maybe improve and update it a little and maybe add it into rtpproxy/nathelper. It works the following way: - nathelper gets another function force_rtp_transcode, that takes the codec to encode to, and creates a completely new SDP with the local port and new codec line - nathelper tells rtpproxy to transcode with a new command option (T) that takes new codec id and format parameters - rtpproxy gets a new codec module path option, from where codec plugins are loaded - when rtpproxy is invoked with 'T' command option, it instantiates a rtpproxy transcoder session with two codec instances from the correct codec plugins - if a packet is received for an rtpproxy session with transcoder, it passes the packet through the codecs before sending The patch is against rtpproxy head from 14092006; since then I think the rtpproxy code has been a little restructured, so it would need some rework to go with current rtpproxy. It contains gsm, ilbc, speex-nb and g711 codec plugins; since then g726, l16, g722 (nb de/encoding) have been added to SEMS (though the codec interface has slightly changed, mostly optional stuff). Other codec wrappers (e.g. 729) could be added easily. A sample transcoder.cfg is in nathelper dir. The patch and files are available at http://user.cs.tu-berlin.de/~sayer/transcoder/ If anyone is taking this up, we would be happy to hear about it. Best Regards Stefan Sayer & Atle Samuelsen [1] http://iptel.org/sems -- Stefan Sayer VoIP Services stefan.sayer at iptego.com www.iptego.com iptego GmbH Am Borsigturm 40 13507 Berlin Germany Amtsgericht Charlottenburg, HRB 101010 Geschaeftsfuehrer: Alexander Hoffmann From sobomax at sippysoft.com Fri Jul 11 19:34:22 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Fri, 11 Jul 2008 19:34:22 -0700 Subject: [RTPproxy Devel] rtpproxy - transcoder patch In-Reply-To: <48752E8B.9000004@iptego.com> References: <48752E8B.9000004@iptego.com> Message-ID: <4878182E.20502@sippysoft.com> Stefan and Atle, Yes, it's very interesting work indeed, thank you for publishing it. Stefan Sayer wrote: > [sorry if you receive this mail multiple times on multiple mailing list > - I thought people on (open)serdev might be interested, but not > necessarily subscribed to rtpproxy lists] > > Hello, > > some time back Atle and me did a small hack to rtpproxy and nathelper so > it could use the codecs from SEMS[1] to transcode RTP from one codec > into another in the rtpproxy. > > Unfortunately we never had or spent the time to get this further than > proof-of-concept. That is, iirc the rtpproxy part is quite ok, but the > nathelper patch could need some eyes over it. As recently someone asked > again about it, we thought we would just release the code as it is, so > if there is anyone interested she or he could take the code, maybe > improve and update it a little and maybe add it into rtpproxy/nathelper. > > It works the following way: > - nathelper gets another function force_rtp_transcode, that takes the > codec to encode to, and creates a completely new SDP with the local port > and new codec line > - nathelper tells rtpproxy to transcode with a new command option (T) > that takes new codec id and format parameters > - rtpproxy gets a new codec module path option, from where codec > plugins are loaded > - when rtpproxy is invoked with 'T' command option, it instantiates a > rtpproxy transcoder session with two codec instances from the correct > codec plugins > - if a packet is received for an rtpproxy session with transcoder, it > passes the packet through the codecs before sending > > The patch is against rtpproxy head from 14092006; since then I think the > rtpproxy code has been a little restructured, so it would need some > rework to go with current rtpproxy. It contains gsm, ilbc, speex-nb and > g711 codec plugins; since then g726, l16, g722 (nb de/encoding) have > been added to SEMS (though the codec interface has slightly changed, > mostly optional stuff). Other codec wrappers (e.g. 729) could be added > easily. A sample transcoder.cfg is in nathelper dir. > > The patch and files are available at > http://user.cs.tu-berlin.de/~sayer/transcoder/ > > If anyone is taking this up, we would be happy to hear about it. > > Best Regards > Stefan Sayer & Atle Samuelsen > > [1] http://iptel.org/sems Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com From wireless.mobile.3 at gmail.com Sat Jul 19 20:10:23 2008 From: wireless.mobile.3 at gmail.com (Zhang William) Date: Sun, 20 Jul 2008 11:10:23 +0800 Subject: [RTPproxy Devel] About data structure naming(pls reply to my email box directly) In-Reply-To: References: Message-ID: any response? On 7/13/08, Zhang William wrote: > Hello Maxim, > > I am thinking whether we can apply some changes to the source code. I feel > some parts of the codes is not so easy to understand. > > As a sample, I list one structure here: > > struct rtpp_session { > /* ttl for caller [0] and callee [1] */ > int ttl[2]; > rtpp_ttl_mode ttl_mode; > unsigned long pcount[4]; > char *call_id; > char *tag; > rtpp_log_t log; > struct rtpp_session* rtcp; > struct rtpp_session* rtp; > /* Remote source addresses, one for caller and one for callee */ > struct sockaddr *addr[2]; > /* Flag which tells if we are allowed to update address with RTP src IP */ > int canupdate[2]; > /* Local listen addresses/ports */ > struct sockaddr *laddr[2]; > int ports[2]; > /* Descriptors */ > int fds[2]; > /* Session is complete, that is we received both request and reply */ > int complete; > int asymmetric[2]; > /* Flags: strong create/delete; weak ones */ > int strong; > int weak[2]; > /* Pointers to rtpp_record's opaque data type */ > void *rrcs[2]; > struct rtp_server *rtps[2]; > /* References to fd-to-session table */ > int sidx[2]; > /* Reference to active RTP generators table */ > int sridx; > /* Flag that indicates whether or not address supplied by client can't be > trusted */ > int untrusted_addr[2]; > struct rtp_resizer resizers[2]; > struct rtpp_session *prev; > struct rtpp_session *next; > struct rtpp_timeout_handler *timeout_handler; > }; > > we don't know what pcount[0], pcount[1], pcount[2], pcount[3] stands for > before reading > > the documentation or looking into the codes using this structure. Even we > know there > > meaning now, as time flies, we may forget later. > > For easy read purpose, the strcuture member name should speak for > themselves. > > for example, a standalone structre can be defined with each member having a > sound name. > > Also, there are many xxx[2] members, can we define such form structure, to > me it will be > > much clear: > > structure rtpp_server { > > int ttl; > > struct sockaddr *addr; > > int canupdate; > > struct sockaddr *laddr; > > int ports; > int fds; > > int asymmetric; > > int weak; > > void *rrcs; > > struct rtp_server *rtps; > > .... > > } > > struct rtpp_session { > > rtpp_server inbound_server; > > rtpp_server outbound_server; > > } > > Thanks, > > William > From wireless.mobile.3 at gmail.com Sat Jul 12 21:52:20 2008 From: wireless.mobile.3 at gmail.com (Zhang William) Date: Sun, 13 Jul 2008 12:52:20 +0800 Subject: [RTPproxy Devel] About data structure naming(pls reply to my email box directly) Message-ID: Hello Maxim, I am thinking whether we can apply some changes to the source code. I feel some parts of the codes is not so easy to understand. As a sample, I list one structure here: struct rtpp_session { /* ttl for caller [0] and callee [1] */ int ttl[2]; rtpp_ttl_mode ttl_mode; unsigned long pcount[4]; char *call_id; char *tag; rtpp_log_t log; struct rtpp_session* rtcp; struct rtpp_session* rtp; /* Remote source addresses, one for caller and one for callee */ struct sockaddr *addr[2]; /* Flag which tells if we are allowed to update address with RTP src IP */ int canupdate[2]; /* Local listen addresses/ports */ struct sockaddr *laddr[2]; int ports[2]; /* Descriptors */ int fds[2]; /* Session is complete, that is we received both request and reply */ int complete; int asymmetric[2]; /* Flags: strong create/delete; weak ones */ int strong; int weak[2]; /* Pointers to rtpp_record's opaque data type */ void *rrcs[2]; struct rtp_server *rtps[2]; /* References to fd-to-session table */ int sidx[2]; /* Reference to active RTP generators table */ int sridx; /* Flag that indicates whether or not address supplied by client can't be trusted */ int untrusted_addr[2]; struct rtp_resizer resizers[2]; struct rtpp_session *prev; struct rtpp_session *next; struct rtpp_timeout_handler *timeout_handler; }; we don't know what pcount[0], pcount[1], pcount[2], pcount[3] stands for before reading the documentation or looking into the codes using this structure. Even we know there meaning now, as time flies, we may forget later. For easy read purpose, the strcuture member name should speak for themselves. for example, a standalone structre can be defined with each member having a sound name. Also, there are many xxx[2] members, can we define such form structure, to me it will be much clear: structure rtpp_server { int ttl; struct sockaddr *addr; int canupdate; struct sockaddr *laddr; int ports; int fds; int asymmetric; int weak; void *rrcs; struct rtp_server *rtps; .... } struct rtpp_session { rtpp_server inbound_server; rtpp_server outbound_server; } Thanks, William -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rtpproxy.org/pipermail/devel/attachments/20080713/79a467c0/attachment.html From sobomax at sippysoft.com Mon Jul 21 01:37:17 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Mon, 21 Jul 2008 01:37:17 -0700 Subject: [RTPproxy Devel] About data structure naming(pls reply to my email box directly) In-Reply-To: References: Message-ID: <48844ABD.9050809@sippysoft.com> Dear Zhang, The suggestion has certain merits, however I would like to point out that there should be a balance between name clarity and convenience, as long names are harder to type and the chance of making a typo is higher. That being said, indeed there are several structure members in the RTPproxy whose names could be improved. However, I don't have a time to do re-name by myself, so that if you feel like it you are welcome to do it by yourself and submit a patch. I will get it committed if it makes sense. As for the inbound/outbound separation, in many places the ability to use index to address specific side of the session makes code much more compact, so that I am not convinced that using separate structures is justified. However, if you show me the patch that implements it without obscuring the code or bloating it significantly I would certainly consider it. If you submit a patch, please make sure you are using the latest version from the cvs trunk, as we've done significant code re-organization recently. Zhang William wrote: > Hello Maxim, > > I am thinking whether we can apply some changes to the source code. I > feel some parts of the codes is not so easy to understand. > > As a sample, I list one structure here: > > struct rtpp_session { > /* ttl for caller [0] and callee [1] */ > int ttl[2]; > rtpp_ttl_mode ttl_mode; > unsigned long pcount[4]; > char *call_id; > char *tag; > rtpp_log_t log; > struct rtpp_session* rtcp; > struct rtpp_session* rtp; > /* Remote source addresses, one for caller and one for callee */ > struct sockaddr *addr[2]; > /* Flag which tells if we are allowed to update address with RTP src IP */ > int canupdate[2]; > /* Local listen addresses/ports */ > struct sockaddr *laddr[2]; > int ports[2]; > /* Descriptors */ > int fds[2]; > /* Session is complete, that is we received both request and reply */ > int complete; > int asymmetric[2]; > /* Flags: strong create/delete; weak ones */ > int strong; > int weak[2]; > /* Pointers to rtpp_record's opaque data type */ > void *rrcs[2]; > struct rtp_server *rtps[2]; > /* References to fd-to-session table */ > int sidx[2]; > /* Reference to active RTP generators table */ > int sridx; > /* Flag that indicates whether or not address supplied by client can't > be trusted */ > int untrusted_addr[2]; > struct rtp_resizer resizers[2]; > struct rtpp_session *prev; > struct rtpp_session *next; > struct rtpp_timeout_handler *timeout_handler; > }; Sincerely, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com From wireless.mobile.3 at gmail.com Sat Jul 26 04:09:41 2008 From: wireless.mobile.3 at gmail.com (Zhang William) Date: Sat, 26 Jul 2008 19:09:41 +0800 Subject: [RTPproxy Devel] About data structure naming(pls reply to my email box directly) In-Reply-To: <48844ABD.9050809@sippysoft.com> References: <48844ABD.9050809@sippysoft.com> Message-ID: Dear Maxim, Thanks for your detailed answer about this question! And I fully understand your concern. >From the view of RTPproxy users, the naming is not important indeed. It's just like a black box. I have to say, at the time being, I don't have time to apply this change either. When I have time to work on this, I will let you know. OK, get the lastest cvs trunk before sumitting a patching is always correct. Best regards, William On 7/21/08, Maxim Sobolev wrote: > > Dear Zhang, > > The suggestion has certain merits, however I would like to point out that > there should be a balance between name clarity and convenience, as long > names are harder to type and the chance of making a typo is higher. That > being said, indeed there are several structure members in the RTPproxy whose > names could be improved. However, I don't have a time to do re-name by > myself, so that if you feel like it you are welcome to do it by yourself and > submit a patch. I will get it committed if it makes sense. > > As for the inbound/outbound separation, in many places the ability to use > index to address specific side of the session makes code much more compact, > so that I am not convinced that using separate structures is justified. > However, if you show me the patch that implements it without obscuring the > code or bloating it significantly I would certainly consider it. > > If you submit a patch, please make sure you are using the latest version > from the cvs trunk, as we've done significant code re-organization recently. > > > Zhang William wrote: > >> Hello Maxim, >> >> I am thinking whether we can apply some changes to the source code. I feel >> some parts of the codes is not so easy to understand. >> >> As a sample, I list one structure here: >> >> struct rtpp_session { >> /* ttl for caller [0] and callee [1] */ >> int ttl[2]; >> rtpp_ttl_mode ttl_mode; >> unsigned long pcount[4]; >> char *call_id; >> char *tag; >> rtpp_log_t log; >> struct rtpp_session* rtcp; >> struct rtpp_session* rtp; >> /* Remote source addresses, one for caller and one for callee */ >> struct sockaddr *addr[2]; >> /* Flag which tells if we are allowed to update address with RTP src IP >> */ >> int canupdate[2]; >> /* Local listen addresses/ports */ >> struct sockaddr *laddr[2]; >> int ports[2]; >> /* Descriptors */ >> int fds[2]; >> /* Session is complete, that is we received both request and reply */ >> int complete; >> int asymmetric[2]; >> /* Flags: strong create/delete; weak ones */ >> int strong; >> int weak[2]; >> /* Pointers to rtpp_record's opaque data type */ >> void *rrcs[2]; >> struct rtp_server *rtps[2]; >> /* References to fd-to-session table */ >> int sidx[2]; >> /* Reference to active RTP generators table */ >> int sridx; >> /* Flag that indicates whether or not address supplied by client can't be >> trusted */ >> int untrusted_addr[2]; >> struct rtp_resizer resizers[2]; >> struct rtpp_session *prev; >> struct rtpp_session *next; >> struct rtpp_timeout_handler *timeout_handler; >> }; >> > > Sincerely, > -- > Maksym Sobolyev > Sippy Software, Inc. > Internet Telephony (VoIP) Experts > T/F: +1-646-651-1110 > Web: http://www.sippysoft.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rtpproxy.org/pipermail/devel/attachments/20080726/fde4f4af/attachment.html