From daniel at readytechnology.co.uk Sun Jun 1 07:20:40 2008 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Sun, 01 Jun 2008 15:20:40 +0100 Subject: [RTPproxy Devel] [RTPproxy Users] patch - per-channel timeouts, notification on timeout In-Reply-To: <48406D56.6040400@sippysoft.com> References: <47931.194.201.144.25.1210086370.squirrel@secure.trendhosting.net> <4820A998.7020202@sippysoft.com> <10640.194.201.144.25.1210150636.squirrel@secure.trendhosting.net> <482B2F3E.3010108@sippysoft.com> <48404E4B.1090800@readytechnology.co.uk> <484056CE.306@sippysoft.com> <484062B9.7090700@readytechnology.co.uk> <48406D56.6040400@sippysoft.com> Message-ID: <4842B038.8040307@readytechnology.co.uk> >> - if the pathname is missing, any existing socket configuration for that >> session will be removed >> > > I don't understand the last one. Can you please explain in more details > what do you mean by that? > > In other words, if a `u' command is sent without a pathname argument, then rtpproxy will not send any notifications for that session. If an earlier `u' command had set the pathname, the subsequent `u' command will remove that setting (see the final `else' clause below): if (op == UPDATE) { + if(cf->timeout_handler.socket_name != NULL && + socket_name_u != NULL) { + if(strcmp(cf->timeout_handler.socket_name, socket_name_u) + != 0) { + rtpp_log_write(RTPP_LOG_ERR, "invalid socket name %s", + socket_name_u); + socket_name_u = NULL; + } else { + spa->timeout_handler = &cf->timeout_handler; + } + } else if(socket_name_u == NULL && spa->timeout_handler != NULL) { + spa->timeout_handler = NULL; + } rtpp_log_write(RTPP_LOG_INFO, spa->log, "adding %s flag to existing session, new=%d/%d/%d", -- ----------------------------------------------------------------------- Ready Technology Limited http://www.readytechnology.co.uk Incorporated in England and Wales, 4940731 Registered office: Devonshire House, 60 Goswell Rd, London, EC1M 7AD ----------------------------------------------------------------------- From daniel at readytechnology.co.uk Sun Jun 1 08:51:34 2008 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Sun, 01 Jun 2008 16:51:34 +0100 Subject: [RTPproxy Devel] [RTPproxy Users] patch - per-channel timeouts, notification on timeout In-Reply-To: <4842B038.8040307@readytechnology.co.uk> References: <47931.194.201.144.25.1210086370.squirrel@secure.trendhosting.net> <4820A998.7020202@sippysoft.com> <10640.194.201.144.25.1210150636.squirrel@secure.trendhosting.net> <482B2F3E.3010108@sippysoft.com> <48404E4B.1090800@readytechnology.co.uk> <484056CE.306@sippysoft.com> <484062B9.7090700@readytechnology.co.uk> <48406D56.6040400@sippysoft.com> <4842B038.8040307@readytechnology.co.uk> Message-ID: <4842C586.3040205@readytechnology.co.uk> Here are some notes on how to observe the new notification behaviour: Start a timeout listener in one window: $ socat UNIX-LISTEN:/var/run/rtpproxy-test.timeout.sock STDOUT Start rtpproxy in another window: $ /tmp/rtpproxy -s unix:/var/run/rtpproxy-test.sock -n unix:/var/run/rtpproxy-test.timeout.sock -f In a third window, send a test command to rtpproxy: $ socat STDIO UNIX-CONNECT:/var/run/rtpproxy-test.sock Ua test01 192.168.1.100 1001 fromtag01 totag01 /var/run/rtpproxy-test.timeout.sock 35000 192.168.1.101 Now wait for a timeout... the message will appear in the first window (socat output) at the same time as the rtpproxy log message about a session timeout. -- ----------------------------------------------------------------------- Ready Technology Limited http://www.readytechnology.co.uk Incorporated in England and Wales, 4940731 Registered office: Devonshire House, 60 Goswell Rd, London, EC1M 7AD ----------------------------------------------------------------------- From daniel at readytechnology.co.uk Mon Jun 2 03:43:35 2008 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Mon, 2 Jun 2008 11:43:35 +0100 (BST) Subject: [RTPproxy Devel] rtppclient.h Message-ID: <10777.194.201.144.25.1212403415.squirrel@secure.trendhosting.net> I've been thinking about what should go in a C client library for the rtpproxy control socket protocol. I don't want to try and implement everything at once, I thought that the SER nathelper implementation and my own variation of this for C++ provide a good starting point: http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/nathelper/nathelper.c?rev=1.126&content-type=text/vnd.viewcvs-markup https://svn.resiprocate.org/viewsvn/resiprocate/main/b2bua/RtpProxyUtil.hxx?revision=7712&view=markup License issue: who wrote the nathelper.c code? It is currently under the GNU license - is it ok to put some of this code in the rtpproxy repository using the BSD license? At a low level, we probably need: - a configuration struct to encapsulate the socket file descriptor(s) - code for sending commands over the socket (e.g. send_rtpp_command from nathelper.c) Above that, there would be a function for each command, my own example includes the following: // Inform rtpproxy of the caller's details unsigned int setupCaller(const char *callID, const char *callerAddr, int callerPort, const char *fromTag, bool callerAsymmetric); // ammend the caller's details (after the caller sends re-INVITE) void ammendCaller(const char *callerAddr, int callerPort); // Inform rtpproxy of the callee's details unsigned int setupCallee(const char *calleeAddr, int calleePort, const char *toTag, bool calleeAsymmetric); // ammend the callee's details void ammendCallee(const char *calleeAddr, int calleePort); Some useful commands not explicitly implemented in my example: - stopAllCalls() - getVersion() At the next level, there would need to be an init() function that can setup the socket, invoke getVersion() and probably invoke stopAllCalls(), in case any calls are still active from a previous instance of the client. From sobomax at sippysoft.com Mon Jun 2 11:50:53 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Mon, 02 Jun 2008 11:50:53 -0700 Subject: [RTPproxy Devel] rtppclient.h In-Reply-To: <10777.194.201.144.25.1212403415.squirrel@secure.trendhosting.net> References: <10777.194.201.144.25.1212403415.squirrel@secure.trendhosting.net> Message-ID: <4844410D.10905@sippysoft.com> Daniel, Please see my comments below: Daniel Pocock wrote: > > > I've been thinking about what should go in a C client library for the > rtpproxy control socket protocol. > > I don't want to try and implement everything at once, I thought that the > SER nathelper implementation and my own variation of this for C++ provide > a good starting point: > > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/nathelper/nathelper.c?rev=1.126&content-type=text/vnd.viewcvs-markup > > https://svn.resiprocate.org/viewsvn/resiprocate/main/b2bua/RtpProxyUtil.hxx?revision=7712&view=markup > > License issue: who wrote the nathelper.c code? It is currently under the > GNU license - is it ok to put some of this code in the rtpproxy repository > using the BSD license? Most if not all of the communication code has been written by myself, so that I think it's pretty safe to relicense it under BSD license. > At a low level, we probably need: > > - a configuration struct to encapsulate the socket file descriptor(s) > > - code for sending commands over the socket (e.g. send_rtpp_command from > nathelper.c) > > Above that, there would be a function for each command, my own example > includes the following: > > // Inform rtpproxy of the caller's details > unsigned int setupCaller(const char *callID, const char *callerAddr, int > callerPort, const char *fromTag, bool callerAsymmetric); > // ammend the caller's details (after the caller sends re-INVITE) > void ammendCaller(const char *callerAddr, int callerPort); > // Inform rtpproxy of the callee's details > unsigned int setupCallee(const char *calleeAddr, int calleePort, const > char *toTag, bool calleeAsymmetric); > // ammend the callee's details > void ammendCallee(const char *calleeAddr, int calleePort); > > Some useful commands not explicitly implemented in my example: > > - stopAllCalls() > - getVersion() > > At the next level, there would need to be an init() function that can > setup the socket, invoke getVersion() and probably invoke stopAllCalls(), > in case any calls are still active from a previous instance of the client. Sounds good, however I would like to point out that the terms "caller" and "callee" are not entirely correct when rtpproxy is being used with non-dialog stateful software, which has not way to determine who the caller and who the callee is. Perhaps there is a need to have two APIs, for for dialog-stateful entries like B2BUAs, and another one for proxies like SER/OpenSER? The second API should be simpler, something like: unsigned int processOffer(const char *callID, const char *callerAddr, int callerPort, const char *fromTag, const char *toTag, bool asymmetric); unsigned int processAnswer(const char *callID, const char *callerAddr, int callerPort, const char *fromTag, const char *toTag, bool asymmetric); There should be also way to pass multiple other supported flags with the U/L command. Perhaps the best way to do it is to pass pointer to options struct instead of asymmetric arg: struct stream_opts { int assymetric; enum {I2I, E2E, I2E, E2I} direction; int isipv6; int repacket; const char *notify_sock; }; Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com From sobomax at sippysoft.com Mon Jun 2 23:32:05 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Mon, 02 Jun 2008 23:32:05 -0700 Subject: [RTPproxy Devel] [RTPproxy Users] patch - per-channel timeouts, notification on timeout In-Reply-To: <4842C586.3040205@readytechnology.co.uk> References: <47931.194.201.144.25.1210086370.squirrel@secure.trendhosting.net> <4820A998.7020202@sippysoft.com> <10640.194.201.144.25.1210150636.squirrel@secure.trendhosting.net> <482B2F3E.3010108@sippysoft.com> <48404E4B.1090800@readytechnology.co.uk> <484056CE.306@sippysoft.com> <484062B9.7090700@readytechnology.co.uk> <48406D56.6040400@sippysoft.com> <4842B038.8040307@readytechnology.co.uk> <4842C586.3040205@readytechnology.co.uk> Message-ID: <4844E565.9040804@sippysoft.com> Daniel, I've cleaned up your code slightly. Please review my changes and let me know if something is unclear or if you have any objections. There are few things in the notify code that need to be improved: 1. The API to enable/disable this functionality. You have added name of the notify socket as an additional argument to the U (UPDATE) command and is detecting its presence by counting arguments. This with only work with B2BUAs, since SIP proxy may not have To tag (i.e. initial INVITE). Instead, the presence/absence of the additional socket_name argument should be indicated by the modifier after U command, so that it's possible to use this feature with or without To tag. 2. For the same reason it would be nice to make it possible to enable/disable this functionality via L (LOOKUP) command. 3. The amount of data reported to the notify socket is clearly suboptimal. At least call id, from tag and to tag should be reported. Daniel Pocock wrote: > > > Here are some notes on how to observe the new notification behaviour: > > Start a timeout listener in one window: > > $ socat UNIX-LISTEN:/var/run/rtpproxy-test.timeout.sock STDOUT > > > Start rtpproxy in another window: > > $ /tmp/rtpproxy -s unix:/var/run/rtpproxy-test.sock -n > unix:/var/run/rtpproxy-test.timeout.sock -f > > > > In a third window, send a test command to rtpproxy: > > $ socat STDIO UNIX-CONNECT:/var/run/rtpproxy-test.sock > Ua test01 192.168.1.100 1001 fromtag01 totag01 > /var/run/rtpproxy-test.timeout.sock > 35000 192.168.1.101 > > > Now wait for a timeout... the message will appear in the first window > (socat output) at the same time as the rtpproxy log message about a > session timeout. > > > > > -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com From daniel at readytechnology.co.uk Tue Jun 3 03:36:31 2008 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Tue, 3 Jun 2008 11:36:31 +0100 (BST) Subject: [RTPproxy Devel] [RTPproxy Users] patch - per-channel timeouts, notification on timeout In-Reply-To: <4844E565.9040804@sippysoft.com> References: <47931.194.201.144.25.1210086370.squirrel@secure.trendhosting.net> <4820A998.7020202@sippysoft.com> <10640.194.201.144.25.1210150636.squirrel@secure.trendhosting.net> <482B2F3E.3010108@sippysoft.com> <48404E4B.1090800@readytechnology.co.uk> <484056CE.306@sippysoft.com> <484062B9.7090700@readytechnology.co.uk> <48406D56.6040400@sippysoft.com> <4842B038.8040307@readytechnology.co.uk> <4842C586.3040205@readytechnology.co.uk> <4844E565.9040804@sippysoft.com> Message-ID: <17064.194.201.144.25.1212489391.squirrel@secure.trendhosting.net> > Daniel, > > I've cleaned up your code slightly. Please review my changes and let me > know if something is unclear or if you have any objections. > The comments in the CVS log make sense, but a few things I notice in the code: - reconnect_timeout_handler(struct rtpp_session *sp, struct rtpp_timeout_handler *th) does not need both arguments, sp is sufficient - do_timeout_notification() no longer attempts to re-connect the socket if the first send() fails - Why must notify_buf[64] be in struct rtpp_timeout_handler? Using the stack is not slower, and the buffer is only needed during the send() operation. - If tags and other things are included in the notification string (see below), 64 bytes may not be long enough (I noticed you reduced this from my original 80 bytes) - any objections if I bump this up again? > There are few things in the notify code that need to be improved: > > 1. The API to enable/disable this functionality. You have added name of > the notify socket as an additional argument to the U (UPDATE) command > and is detecting its presence by counting arguments. This with only work > with B2BUAs, since SIP proxy may not have To tag (i.e. initial INVITE). > Instead, the presence/absence of the additional socket_name argument > should be indicated by the modifier after U command, so that it's > possible to use this feature with or without To tag. > > 2. For the same reason it would be nice to make it possible to > enable/disable this functionality via L (LOOKUP) command. > I will do both of these things > 3. The amount of data reported to the notify socket is clearly > suboptimal. At least call id, from tag and to tag should be reported. > Ok, I will do call ID, from tag, to tag, port numbers and TTLs From daniel at readytechnology.co.uk Tue Jun 3 06:56:03 2008 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Tue, 3 Jun 2008 14:56:03 +0100 (BST) Subject: [RTPproxy Devel] call_id, from_tag and to_tag Message-ID: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> I notice that rtpp_session only stores one tag, not both If I understand correctly, SIP requires a Call ID, From tag and To tag to uniquely identify a call. Is there any reason why rtpproxy should not store both tags in one rtpp_session? Is it reasonable to assume a one-one mapping of rtpp_session and SIP dialog? >From page 13, RFC 3261 (SIP): The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between Alice and Bob and is referred to as a dialog. From daniel at readytechnology.co.uk Tue Jun 3 07:38:42 2008 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Tue, 3 Jun 2008 15:38:42 +0100 (BST) Subject: [RTPproxy Devel] call_id, from_tag and to_tag In-Reply-To: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> References: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> Message-ID: <50263.194.201.144.25.1212503922.squirrel@secure.trendhosting.net> This is the new notification format I'm considering: snprintf(th->notify_buf, sizeof(th->notify_buf), "%s %s %d %d %d %d\n", sp->call_id, sp->tag, sp->ttl[0], sp->ttl[1], sp->ports[0], sp->ports[1]); From sobomax at sippysoft.com Tue Jun 3 17:48:09 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Tue, 03 Jun 2008 17:48:09 -0700 Subject: [RTPproxy Devel] [RTPproxy Users] patch - per-channel timeouts, notification on timeout In-Reply-To: <17064.194.201.144.25.1212489391.squirrel@secure.trendhosting.net> References: <47931.194.201.144.25.1210086370.squirrel@secure.trendhosting.net> <4820A998.7020202@sippysoft.com> <10640.194.201.144.25.1210150636.squirrel@secure.trendhosting.net> <482B2F3E.3010108@sippysoft.com> <48404E4B.1090800@readytechnology.co.uk> <484056CE.306@sippysoft.com> <484062B9.7090700@readytechnology.co.uk> <48406D56.6040400@sippysoft.com> <4842B038.8040307@readytechnology.co.uk> <4842C586.3040205@readytechnology.co.uk> <4844E565.9040804@sippysoft.com> <17064.194.201.144.25.1212489391.squirrel@secure.trendhosting.net> Message-ID: <4845E649.2000206@sippysoft.com> Daniel Pocock wrote: > >> Daniel, >> >> I've cleaned up your code slightly. Please review my changes and let me >> know if something is unclear or if you have any objections. >> > > The comments in the CVS log make sense, but a few things I notice in the > code: > > - reconnect_timeout_handler(struct rtpp_session *sp, struct > rtpp_timeout_handler *th) does not need both arguments, sp is sufficient Yes, I know, but we have th ready, so why not use that? > - do_timeout_notification() no longer attempts to re-connect the socket if > the first send() fails I am not sure what the logic behind this is? Can you please explain? > - Why must notify_buf[64] be in struct rtpp_timeout_handler? Using the > stack is not slower, and the buffer is only needed during the send() > operation. It's just the matter of personal preference. I don't like it when lot of staff is allocated on stack. Really matters in kernel code and heavily-threaded programs, doesn't matter much in this case probably. > - If tags and other things are included in the notification string (see > below), 64 bytes may not be long enough (I noticed you reduced this from > my original 80 bytes) - any objections if I bump this up again? Sure, I would suggest bumping it to 1K or even more. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com From mrdatman at gmail.com Wed Jun 4 11:21:01 2008 From: mrdatman at gmail.com (David Thompson) Date: Wed, 4 Jun 2008 13:21:01 -0500 Subject: [RTPproxy Devel] blocking on high usage b2bua In-Reply-To: <50263.194.201.144.25.1212503922.squirrel@secure.trendhosting.net> References: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> <50263.194.201.144.25.1212503922.squirrel@secure.trendhosting.net> Message-ID: <01b601c8c66f$c093f290$41bbd7b0$@com> Daniel, THANK YOU for putting some examples and ideas of reciprocate -> rtpproxy on the reciprocate trunk. I am pouring through the RtpProxyUtil and other classes and I had a few high level questions. Let's assume a b2b type of application was handling a high number of concurrent calls, and for arguments sake had to be able to handle 1000 new call setups per second. Would you recommend any calls to rtp proxy be made directly in process (ie on the same thread as the app logic) or through another FIFO. In other words, could the calls to rtpproxy consume enough real-time blocking to warrant a FIFO approach? Let me know your thoughts.... David From daniel at readytechnology.co.uk Wed Jun 4 11:35:11 2008 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 04 Jun 2008 19:35:11 +0100 Subject: [RTPproxy Devel] blocking on high usage b2bua In-Reply-To: <01b601c8c66f$c093f290$41bbd7b0$@com> References: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> <50263.194.201.144.25.1212503922.squirrel@secure.trendhosting.net> <01b601c8c66f$c093f290$41bbd7b0$@com> Message-ID: <4846E05F.2040800@readytechnology.co.uk> David Thompson wrote: > Daniel, > > THANK YOU for putting some examples and ideas of reciprocate -> rtpproxy on > the reciprocate trunk. > > I am pouring through the RtpProxyUtil and other classes and I had a few high > level questions. Let's assume a b2b type of application was handling a high > number of concurrent calls, and for arguments sake had to be able to handle > 1000 new call setups per second. > > Would you recommend any calls to rtp proxy be made directly in process (ie > on the same thread as the app logic) or through another FIFO. In other > words, could the calls to rtpproxy consume enough real-time blocking to > warrant a FIFO approach? > > Let me know your thoughts.... > This is something I was thinking about the other day You might notice I've proposed (and will be contributing to) a librtppclient library (to be linked in your B2BUA) Such a library could work in three ways (user selectable): a) Existing mode - connect to an external rtpproxy process over UNIX or UDP sockets, with some convenient C functions b) Forking mode - start and configure an rtpproxy process for you, this would simplify configuration, init scripts, restarts, etc, but all communication would still occur over a UNIX socket c) Threaded mode - as for forking mode, but address space is shared, so the UNIX socket is not needed. In this case, multi-threaded programming techniques would be needed to ensure the rtpproxy thread's data structures are not improperly accessed from another thread. All of rtpproxy would not be made thread safe - just the stuff for handling commands. To simplify option (b) and (c), the code for parsing command line arguments needs to be generalised so that command line arguments can be passed directly in some kind of struct. To make option (c) feasible, the code for handle_command(), which parses commands over the socket, probably needs to be generalised so that commands can be passed through an internal FIFO structure. Ideally, it would be safe for multiple threads to call the new version of handle_command(), or some related function. All three options, (a), (b) and (c) could potentially be used with the same client API. Regards, Daniel -- ----------------------------------------------------------------------- Ready Technology Limited http://www.readytechnology.co.uk Incorporated in England and Wales, 4940731 Registered office: Devonshire House, 60 Goswell Rd, London, EC1M 7AD ----------------------------------------------------------------------- From mrdatman at gmail.com Wed Jun 4 12:06:42 2008 From: mrdatman at gmail.com (David Thompson) Date: Wed, 4 Jun 2008 14:06:42 -0500 Subject: [RTPproxy Devel] blocking on high usage b2bua In-Reply-To: <4846E05F.2040800@readytechnology.co.uk> References: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> <50263.194.201.144.25.1212503922.squirrel@secure.trendhosting.net> <01b601c8c66f$c093f290$41bbd7b0$@com> <4846E05F.2040800@readytechnology.co.uk> Message-ID: <01c301c8c676$215fb4a0$641f1de0$@com> I personally would be uneasy running RTPProxy and my main B2BUA on the same machine as scalability becomes a concern for me (I would most likely have a bank of RTPProxy machines running). This basically rules out b and c. If you are building a client for rtpproxy, perhaps an idea for those who will connect remotely to an existing machine would be to send all command requests to an internal FIFO to ensure you are taking as little time of the caller as possible. Then your internal FIFO would send the commands over the socket as quick as it can with some kind of alerting mechanism for errors. I will most likely create a flow similar to this for my existing b2b. Let me know if you want/need help with your client. David -----Original Message----- From: devel-bounces at rtpproxy.org [mailto:devel-bounces at rtpproxy.org] On Behalf Of Daniel Pocock Sent: Wednesday, June 04, 2008 1:35 PM To: RTPproxy Development Subject: Re: [RTPproxy Devel] blocking on high usage b2bua David Thompson wrote: > Daniel, > > THANK YOU for putting some examples and ideas of reciprocate -> rtpproxy on > the reciprocate trunk. > > I am pouring through the RtpProxyUtil and other classes and I had a few high > level questions. Let's assume a b2b type of application was handling a high > number of concurrent calls, and for arguments sake had to be able to handle > 1000 new call setups per second. > > Would you recommend any calls to rtp proxy be made directly in process (ie > on the same thread as the app logic) or through another FIFO. In other > words, could the calls to rtpproxy consume enough real-time blocking to > warrant a FIFO approach? > > Let me know your thoughts.... > This is something I was thinking about the other day You might notice I've proposed (and will be contributing to) a librtppclient library (to be linked in your B2BUA) Such a library could work in three ways (user selectable): a) Existing mode - connect to an external rtpproxy process over UNIX or UDP sockets, with some convenient C functions b) Forking mode - start and configure an rtpproxy process for you, this would simplify configuration, init scripts, restarts, etc, but all communication would still occur over a UNIX socket c) Threaded mode - as for forking mode, but address space is shared, so the UNIX socket is not needed. In this case, multi-threaded programming techniques would be needed to ensure the rtpproxy thread's data structures are not improperly accessed from another thread. All of rtpproxy would not be made thread safe - just the stuff for handling commands. To simplify option (b) and (c), the code for parsing command line arguments needs to be generalised so that command line arguments can be passed directly in some kind of struct. To make option (c) feasible, the code for handle_command(), which parses commands over the socket, probably needs to be generalised so that commands can be passed through an internal FIFO structure. Ideally, it would be safe for multiple threads to call the new version of handle_command(), or some related function. All three options, (a), (b) and (c) could potentially be used with the same client API. Regards, Daniel -- ----------------------------------------------------------------------- Ready Technology Limited http://www.readytechnology.co.uk Incorporated in England and Wales, 4940731 Registered office: Devonshire House, 60 Goswell Rd, London, EC1M 7AD ----------------------------------------------------------------------- _______________________________________________ Devel mailing list Devel at rtpproxy.org http://lists.rtpproxy.org/mailman/listinfo/devel From sobomax at sippysoft.com Wed Jun 4 12:43:28 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Wed, 04 Jun 2008 12:43:28 -0700 Subject: [RTPproxy Devel] blocking on high usage b2bua In-Reply-To: <4846E05F.2040800@readytechnology.co.uk> References: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> <50263.194.201.144.25.1212503922.squirrel@secure.trendhosting.net> <01b601c8c66f$c093f290$41bbd7b0$@com> <4846E05F.2040800@readytechnology.co.uk> Message-ID: <4846F060.3040402@sippysoft.com> Daniel Pocock wrote: > To make option (c) feasible, the code for handle_command(), which parses > commands over the socket, probably needs to be generalised so that > commands can be passed through an internal FIFO structure. Ideally, it > would be safe for multiple threads to call the new version of > handle_command(), or some related function. > > All three options, (a), (b) and (c) could potentially be used with the > same client API. Well, I don't quite see the need to have shared memory space between rtpproxy client and rtpproxy server. Even with gigabit speed networks there is simply not enough setup/teardowns per second to warrant huge increasing of complexity in this case. Instead I think the command handling should be re-worked to allow several commands complete independently. To tell you the truth, we even plan to move in completely opposite direction - from our simple ad-hoc messages based protocol to something more complicated but standard such as xmlrpc. With the increasing number of cores per average processor we can spare one for command handling thread without sacrificing the performance. Speaking about the original question, the low hanging fruit here doesn't even require any changes to rtpproxy - one can simply enhance client library to allow using pool of rtpproxies in round-robin fashion. Client class Rtp_proxy_session.py from Sipppy B2BUA already implements that already (http://cvs.berlios.de/cgi-bin/viewcvs.cgi/sippy/sippy/Rtp_proxy_session.py). We successfully use it in production for one of our clients, with 4 proxies running in parallel, pushing around 100MBps in each direction per single box*). I think you can get to 1000 calls/sec now by running 10 in parallel easily. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com *) 3796 ? Ss 219:30 /usr/local/bin/rtpproxy -l X.Y.Z.W -L 8192 -p /var/run/rtpproxy.pid -s /var/run/rtpproxy.sock -m 25000 -M 34999 3805 ? Ss 235:38 /usr/local/bin/rtpproxy1 -l X.Y.Z.W -L 8192 -p /var/run/rtpproxy1.pid -s /var/run/rtpproxy1.sock -m 35000 -M 44999 3814 ? Ss 223:09 /usr/local/bin/rtpproxy2 -l X.Y.Z.W -L 8192 -p /var/run/rtpproxy2.pid -s /var/run/rtpproxy2.sock -m 45000 -M 54999 3823 ? Ss 236:08 /usr/local/bin/rtpproxy3 -l X.Y.Z.W -L 8192 -p /var/run/rtpproxy3.pid -s /var/run/rtpproxy3.sock -m 55000 -M 64999 From mrdatman at gmail.com Wed Jun 4 13:06:08 2008 From: mrdatman at gmail.com (David Thompson) Date: Wed, 4 Jun 2008 15:06:08 -0500 Subject: [RTPproxy Devel] blocking on high usage b2bua In-Reply-To: <4846F060.3040402@sippysoft.com> References: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> <50263.194.201.144.25.1212503922.squirrel@secure.trendhosting.net> <01b601c8c66f$c093f290$41bbd7b0$@com> <4846E05F.2040800@readytechnology.co.uk> <4846F060.3040402@sippysoft.com> Message-ID: <01c701c8c67e$6f0ea9b0$4d2bfd10$@com> Thanks Maksym. Would it be safe to assume then I should plan on max concurrent rtp sessions (a call being 2) for a given instance to 100? -----Original Message----- From: devel-bounces at rtpproxy.org [mailto:devel-bounces at rtpproxy.org] On Behalf Of Maxim Sobolev Sent: Wednesday, June 04, 2008 2:43 PM To: RTPproxy Development Subject: Re: [RTPproxy Devel] blocking on high usage b2bua Daniel Pocock wrote: > To make option (c) feasible, the code for handle_command(), which parses > commands over the socket, probably needs to be generalised so that > commands can be passed through an internal FIFO structure. Ideally, it > would be safe for multiple threads to call the new version of > handle_command(), or some related function. > > All three options, (a), (b) and (c) could potentially be used with the > same client API. Well, I don't quite see the need to have shared memory space between rtpproxy client and rtpproxy server. Even with gigabit speed networks there is simply not enough setup/teardowns per second to warrant huge increasing of complexity in this case. Instead I think the command handling should be re-worked to allow several commands complete independently. To tell you the truth, we even plan to move in completely opposite direction - from our simple ad-hoc messages based protocol to something more complicated but standard such as xmlrpc. With the increasing number of cores per average processor we can spare one for command handling thread without sacrificing the performance. Speaking about the original question, the low hanging fruit here doesn't even require any changes to rtpproxy - one can simply enhance client library to allow using pool of rtpproxies in round-robin fashion. Client class Rtp_proxy_session.py from Sipppy B2BUA already implements that already (http://cvs.berlios.de/cgi-bin/viewcvs.cgi/sippy/sippy/Rtp_proxy_session.py) . We successfully use it in production for one of our clients, with 4 proxies running in parallel, pushing around 100MBps in each direction per single box*). I think you can get to 1000 calls/sec now by running 10 in parallel easily. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com *) 3796 ? Ss 219:30 /usr/local/bin/rtpproxy -l X.Y.Z.W -L 8192 -p /var/run/rtpproxy.pid -s /var/run/rtpproxy.sock -m 25000 -M 34999 3805 ? Ss 235:38 /usr/local/bin/rtpproxy1 -l X.Y.Z.W -L 8192 -p /var/run/rtpproxy1.pid -s /var/run/rtpproxy1.sock -m 35000 -M 44999 3814 ? Ss 223:09 /usr/local/bin/rtpproxy2 -l X.Y.Z.W -L 8192 -p /var/run/rtpproxy2.pid -s /var/run/rtpproxy2.sock -m 45000 -M 54999 3823 ? Ss 236:08 /usr/local/bin/rtpproxy3 -l X.Y.Z.W -L 8192 -p /var/run/rtpproxy3.pid -s /var/run/rtpproxy3.sock -m 55000 -M 64999 _______________________________________________ Devel mailing list Devel at rtpproxy.org http://lists.rtpproxy.org/mailman/listinfo/devel From sobomax at sippysoft.com Wed Jun 4 16:52:12 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Wed, 04 Jun 2008 16:52:12 -0700 Subject: [RTPproxy Devel] blocking on high usage b2bua In-Reply-To: <01c701c8c67e$6f0ea9b0$4d2bfd10$@com> References: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> <50263.194.201.144.25.1212503922.squirrel@secure.trendhosting.net> <01b601c8c66f$c093f290$41bbd7b0$@com> <4846E05F.2040800@readytechnology.co.uk> <4846F060.3040402@sippysoft.com> <01c701c8c67e$6f0ea9b0$4d2bfd10$@com> Message-ID: <48472AAC.1060302@sippysoft.com> David, No, I have been talking about 100 calls/second here, not concurrent sessions. There is no universal way to convert from one to another, but 100 calls/second corresponds to at least 5,000 concurrent sessions (assuming average call duration of 200 seconds and ASR of 25%). You can get 1,000 concurent calls with single rtpproxy easily. You don't need 10 instances for that. David Thompson wrote: > Thanks Maksym. Would it be safe to assume then I should plan on max > concurrent rtp sessions (a call being 2) for a given instance to 100? Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com From daniel at readytechnology.co.uk Fri Jun 6 12:47:49 2008 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Fri, 06 Jun 2008 20:47:49 +0100 Subject: [RTPproxy Devel] blocking on high usage b2bua In-Reply-To: <01b601c8c66f$c093f290$41bbd7b0$@com> References: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> <50263.194.201.144.25.1212503922.squirrel@secure.trendhosting.net> <01b601c8c66f$c093f290$41bbd7b0$@com> Message-ID: <48499465.50704@readytechnology.co.uk> > > Would you recommend any calls to rtp proxy be made directly in process (ie > on the same thread as the app logic) or through another FIFO. In other > words, could the calls to rtpproxy consume enough real-time blocking to > warrant a FIFO approach? > Going back to your original question here, this is also meant to be addressed in the B2BUA library. You will notice that the calls to rtpproxy are synchronous - the SIP stack is blocked while waiting for rtpproxy. Using the UNIX socket, only one concurrent call to rtpproxy is possible. I originally intended to work around this by setting up a separate thread in the B2BUA. The B2BUA should put the call in the state MediaProxyPending (currently commented out in B2BCall.hxx). The SIP thread would immediately continue processing other SIP requests, while the rtpproxy-control thread would send the command over the socket. When the rtpproxy response arrives, the call state should then go to MediaProxySuccess. At some point after that, the SIP stack thread would invoke the method doMediaProxySuccess(). If multiple rtpproxies are available, there could be multiple rtpproxy threads, or at least one thread using select() to monitor all of their sockets efficiently. One of the reasons for putting the B2BUA in the public domain is that I don't have the time to implement every one of these possibilities. I've tried to create a good foundation for this, and now people can extend it in the direction they desire. Regards, Daniel -- ----------------------------------------------------------------------- Ready Technology Limited http://www.readytechnology.co.uk Incorporated in England and Wales, 4940731 Registered office: Devonshire House, 60 Goswell Rd, London, EC1M 7AD ----------------------------------------------------------------------- From mrdatman at gmail.com Sat Jun 7 07:27:55 2008 From: mrdatman at gmail.com (David Thompson) Date: Sat, 7 Jun 2008 09:27:55 -0500 Subject: [RTPproxy Devel] Command Help In-Reply-To: <48472AAC.1060302@sippysoft.com> References: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> <50263.194.201.144.25.1212503922.squirrel@secure.trendhosting.net> <01b601c8c66f$c093f290$41bbd7b0$@com> <4846E05F.2040800@readytechnology.co.uk> <4846F060.3040402@sippysoft.com> <01c701c8c67e$6f0ea9b0$4d2bfd10$@com> <48472AAC.1060302@sippysoft.com> Message-ID: <000601c8c8aa$ae515360$0af3fa20$@com> Maxim, I have been going through yours and Daniel's code to gather the syntax needed for my scenario. I almost have it but wanted to see if you could help me out... Here is what I am trying to do: Caller A calls into to me with sdp in invite I send back immediate comfort ring tone to them I then place a call out to Callee B, CalleeB rejects the call (Server Busy) I then place a call out to Callee C, Callee C When CalleeC sends an OK, I bridge the call through the proxy to with CallerA. So here is what I have so far, if you can fill in the pieces and correct my syntax I would be very grateful. 1. Call A sends invite (I to establish rtp with them) Syntax: "Ls calleeCallID calleeip calleeport fromtag totag" 2. I then send a play command: (I want to send comfort ring (looping if possible)) Syntax: "P calleeCallID ring.wav codec fromtag totag" 3. I need to send an invite to CalleeB (I need a port number to give) Syntax: "?????" (I just need a port number to send in invite) 4. CalleeB Rejects Call so I need to send invite to CalleeC Syntax: "?????" (I need port number to send in invite) 3. I get an OK from CalleeC I now want to stop playing the ring tone to CalleerA and bridge the call with CallerC Syntax: "?????" Thanks in advance. David From mrdatman at gmail.com Sat Jun 7 07:34:29 2008 From: mrdatman at gmail.com (David Thompson) Date: Sat, 7 Jun 2008 09:34:29 -0500 Subject: [RTPproxy Devel] blocking on high usage b2bua In-Reply-To: <48499465.50704@readytechnology.co.uk> References: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> <50263.194.201.144.25.1212503922.squirrel@secure.trendhosting.net> <01b601c8c66f$c093f290$41bbd7b0$@com> <48499465.50704@readytechnology.co.uk> Message-ID: <000701c8c8ab$9889a720$c99cf560$@com> Daniel, Thank you for your response. I wanted to get your opinion on something. Because the RTP Proxy will be on a different machine than the b2bua, I can use UNIX sockets directly. So I have played around with the udp/cookie based approach that the library has as an alternative (umode =1) My concern is I require a high degree of reliability of communication between the b2bua and rtp proxy. I fear that using udp with the matching cookie response method might get less that reliable results under high load of communication. What is your experience with this? Would I be better writing a "communications" wrapper that sits on the same machine as rtpproxy, communicates with it using UNIX sockets and communicates back with my b2bua using regular TCP sockets? If this was the case I could use your suggestion here to communicate across machine boundaries with my "communicator" which then relays the messages to one or more instances of a locally running RTPProxy using UNIX sockets? Is this an overkill? Penny for your thoughts.... Thanks, David -----Original Message----- From: devel-bounces at rtpproxy.org [mailto:devel-bounces at rtpproxy.org] On Behalf Of Daniel Pocock Sent: Friday, June 06, 2008 2:48 PM To: RTPproxy Development Subject: Re: [RTPproxy Devel] blocking on high usage b2bua > > Would you recommend any calls to rtp proxy be made directly in process (ie > on the same thread as the app logic) or through another FIFO. In other > words, could the calls to rtpproxy consume enough real-time blocking to > warrant a FIFO approach? > Going back to your original question here, this is also meant to be addressed in the B2BUA library. You will notice that the calls to rtpproxy are synchronous - the SIP stack is blocked while waiting for rtpproxy. Using the UNIX socket, only one concurrent call to rtpproxy is possible. I originally intended to work around this by setting up a separate thread in the B2BUA. The B2BUA should put the call in the state MediaProxyPending (currently commented out in B2BCall.hxx). The SIP thread would immediately continue processing other SIP requests, while the rtpproxy-control thread would send the command over the socket. When the rtpproxy response arrives, the call state should then go to MediaProxySuccess. At some point after that, the SIP stack thread would invoke the method doMediaProxySuccess(). If multiple rtpproxies are available, there could be multiple rtpproxy threads, or at least one thread using select() to monitor all of their sockets efficiently. One of the reasons for putting the B2BUA in the public domain is that I don't have the time to implement every one of these possibilities. I've tried to create a good foundation for this, and now people can extend it in the direction they desire. Regards, Daniel -- ----------------------------------------------------------------------- Ready Technology Limited http://www.readytechnology.co.uk Incorporated in England and Wales, 4940731 Registered office: Devonshire House, 60 Goswell Rd, London, EC1M 7AD ----------------------------------------------------------------------- _______________________________________________ Devel mailing list Devel at rtpproxy.org http://lists.rtpproxy.org/mailman/listinfo/devel From daniel at readytechnology.co.uk Sat Jun 7 08:49:44 2008 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Sat, 07 Jun 2008 16:49:44 +0100 Subject: [RTPproxy Devel] blocking on high usage b2bua In-Reply-To: <000701c8c8ab$9889a720$c99cf560$@com> References: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> <50263.194.201.144.25.1212503922.squirrel@secure.trendhosting.net> <01b601c8c66f$c093f290$41bbd7b0$@com> <48499465.50704@readytechnology.co.uk> <000701c8c8ab$9889a720$c99cf560$@com> Message-ID: <484AAE18.9070408@readytechnology.co.uk> > What is your experience with this? Would I be better writing a > "communications" wrapper that sits on the same machine as rtpproxy, > communicates with it using UNIX sockets and communicates back with my b2bua > using regular TCP sockets? If this was the case I could use your suggestion > here to communicate across machine boundaries with my "communicator" which > then relays the messages to one or more instances of a locally running > RTPProxy using UNIX sockets? Is this an overkill? > > I haven't pushed it that level, so I can't comment on experience. However, what would be your thoughts on using ActiveMQ-CPP or some other middleware (e.g. RendezVous)? These solutions are obviously a little more heavy-weight, but they may offer more scalability, and you can leverage many features that are already implemented (e.g. timeout on messages, round-robin delivery) -- ----------------------------------------------------------------------- Ready Technology Limited http://www.readytechnology.co.uk Incorporated in England and Wales, 4940731 Registered office: Devonshire House, 60 Goswell Rd, London, EC1M 7AD ----------------------------------------------------------------------- From sobomax at sippysoft.com Mon Jun 9 12:04:42 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Mon, 09 Jun 2008 12:04:42 -0700 Subject: [RTPproxy Devel] blocking on high usage b2bua In-Reply-To: <000701c8c8ab$9889a720$c99cf560$@com> References: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> <50263.194.201.144.25.1212503922.squirrel@secure.trendhosting.net> <01b601c8c66f$c093f290$41bbd7b0$@com> <48499465.50704@readytechnology.co.uk> <000701c8c8ab$9889a720$c99cf560$@com> Message-ID: <484D7ECA.3020302@sippysoft.com> David, Our own experience shows that remote UDP mode is quite reliable, as long as client does proper retransmits. Widely used industry-standard protocols like RADIUS successfully employ similar "cookie" mechanism with client-driven retransmits. David Thompson wrote: > Daniel, > > Thank you for your response. > > I wanted to get your opinion on something. Because the RTP Proxy will be on > a different machine than the b2bua, I can use UNIX sockets directly. So I > have played around with the udp/cookie based approach that the library has > as an alternative (umode =1) > > My concern is I require a high degree of reliability of communication > between the b2bua and rtp proxy. I fear that using udp with the matching > cookie response method might get less that reliable results under high load > of communication. > > What is your experience with this? Would I be better writing a > "communications" wrapper that sits on the same machine as rtpproxy, > communicates with it using UNIX sockets and communicates back with my b2bua > using regular TCP sockets? If this was the case I could use your suggestion > here to communicate across machine boundaries with my "communicator" which > then relays the messages to one or more instances of a locally running > RTPProxy using UNIX sockets? Is this an overkill? > > Penny for your thoughts.... Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com From mrdatman at gmail.com Mon Jun 9 12:44:07 2008 From: mrdatman at gmail.com (David Thompson) Date: Mon, 9 Jun 2008 14:44:07 -0500 Subject: [RTPproxy Devel] blocking on high usage b2bua In-Reply-To: <484D7ECA.3020302@sippysoft.com> References: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> <50263.194.201.144.25.1212503922.squirrel@secure.trendhosting.net> <01b601c8c66f$c093f290$41bbd7b0$@com> <48499465.50704@readytechnology.co.uk> <000701c8c8ab$9889a720$c99cf560$@com> <484D7ECA.3020302@sippysoft.com> Message-ID: <002701c8ca69$2eb72330$8c256990$@com> Thank you. I'll roll with the UDP then. (saves me a bit of work) -----Original Message----- From: devel-bounces at rtpproxy.org [mailto:devel-bounces at rtpproxy.org] On Behalf Of Maxim Sobolev Sent: Monday, June 09, 2008 2:05 PM To: RTPproxy Development Subject: Re: [RTPproxy Devel] blocking on high usage b2bua David, Our own experience shows that remote UDP mode is quite reliable, as long as client does proper retransmits. Widely used industry-standard protocols like RADIUS successfully employ similar "cookie" mechanism with client-driven retransmits. David Thompson wrote: > Daniel, > > Thank you for your response. > > I wanted to get your opinion on something. Because the RTP Proxy will be on > a different machine than the b2bua, I can use UNIX sockets directly. So I > have played around with the udp/cookie based approach that the library has > as an alternative (umode =1) > > My concern is I require a high degree of reliability of communication > between the b2bua and rtp proxy. I fear that using udp with the matching > cookie response method might get less that reliable results under high load > of communication. > > What is your experience with this? Would I be better writing a > "communications" wrapper that sits on the same machine as rtpproxy, > communicates with it using UNIX sockets and communicates back with my b2bua > using regular TCP sockets? If this was the case I could use your suggestion > here to communicate across machine boundaries with my "communicator" which > then relays the messages to one or more instances of a locally running > RTPProxy using UNIX sockets? Is this an overkill? > > Penny for your thoughts.... Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com _______________________________________________ Devel mailing list Devel at rtpproxy.org http://lists.rtpproxy.org/mailman/listinfo/devel From sobomax at sippysoft.com Fri Jun 13 11:26:54 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Fri, 13 Jun 2008 11:26:54 -0700 Subject: [RTPproxy Devel] Command Help In-Reply-To: <000601c8c8aa$ae515360$0af3fa20$@com> References: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> <50263.194.201.144.25.1212503922.squirrel@secure.trendhosting.net> <01b601c8c66f$c093f290$41bbd7b0$@com> <4846E05F.2040800@readytechnology.co.uk> <4846F060.3040402@sippysoft.com> <01c701c8c67e$6f0ea9b0$4d2bfd10$@com> <48472AAC.1060302@sippysoft.com> <000601c8c8aa$ae515360$0af3fa20$@com> Message-ID: <4852BBEE.1070507@sippysoft.com> David Thompson wrote: > Maxim, > > I have been going through yours and Daniel's code to gather the syntax > needed for my scenario. I almost have it but wanted to see if you could help > me out... > > > Here is what I am trying to do: > > Caller A calls into to me with sdp in invite > I send back immediate comfort ring tone to them > I then place a call out to Callee B, CalleeB rejects the call (Server Busy) > I then place a call out to Callee C, Callee C > When CalleeC sends an OK, I bridge the call through the proxy to with > CallerA. > > So here is what I have so far, if you can fill in the pieces and correct my > syntax I would be very grateful. > > 1. Call A sends invite (I to establish rtp with them) > Syntax: "Ls calleeCallID calleeip calleeport fromtag totag" U call_id remote_ip remote_port from_tag > > 2. I then send a play command: (I want to send comfort ring (looping if > possible)) > Syntax: "P calleeCallID ring.wav codec fromtag totag" P-1 call_id prompt_name codecs from_tag to_tag > 3. I need to send an invite to CalleeB (I need a port number to give) > Syntax: "?????" (I just need a port number to send in invite) You should really use port number from call (1). > 4. CalleeB Rejects Call so I need to send invite to CalleeC > Syntax: "?????" (I need port number to send in invite) You can either use port from (1) or do another call: L call_id remote_ip remote_port to_tag from_tag > 3. I get an OK from CalleeC I now want to stop playing the ring tone to > CalleerA and bridge the call with CallerC > Syntax: "?????" S call_id from_tag to_tag Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com From mrdatman at gmail.com Fri Jun 13 13:48:11 2008 From: mrdatman at gmail.com (David Thompson) Date: Fri, 13 Jun 2008 15:48:11 -0500 Subject: [RTPproxy Devel] Command Help In-Reply-To: <4852BBEE.1070507@sippysoft.com> References: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> <50263.194.201.144.25.1212503922.squirrel@secure.trendhosting.net> <01b601c8c66f$c093f290$41bbd7b0$@com> <4846E05F.2040800@readytechnology.co.uk> <4846F060.3040402@sippysoft.com> <01c701c8c67e$6f0ea9b0$4d2bfd10$@com> <48472AAC.1060302@sippysoft.com> <000601c8c8aa$ae515360$0af3fa20$@com> <4852BBEE.1070507@sippysoft.com> Message-ID: <005d01c8cd96$ccfbed70$66f3c850$@com> Thank you for taking the time to respond here, I appreciate it. -----Original Message----- From: devel-bounces at rtpproxy.org [mailto:devel-bounces at rtpproxy.org] On Behalf Of Maxim Sobolev Sent: Friday, June 13, 2008 1:27 PM To: RTPproxy Development Subject: Re: [RTPproxy Devel] Command Help David Thompson wrote: > Maxim, > > I have been going through yours and Daniel's code to gather the syntax > needed for my scenario. I almost have it but wanted to see if you could help > me out... > > > Here is what I am trying to do: > > Caller A calls into to me with sdp in invite > I send back immediate comfort ring tone to them > I then place a call out to Callee B, CalleeB rejects the call (Server Busy) > I then place a call out to Callee C, Callee C > When CalleeC sends an OK, I bridge the call through the proxy to with > CallerA. > > So here is what I have so far, if you can fill in the pieces and correct my > syntax I would be very grateful. > > 1. Call A sends invite (I to establish rtp with them) > Syntax: "Ls calleeCallID calleeip calleeport fromtag totag" U call_id remote_ip remote_port from_tag > > 2. I then send a play command: (I want to send comfort ring (looping if > possible)) > Syntax: "P calleeCallID ring.wav codec fromtag totag" P-1 call_id prompt_name codecs from_tag to_tag > 3. I need to send an invite to CalleeB (I need a port number to give) > Syntax: "?????" (I just need a port number to send in invite) You should really use port number from call (1). > 4. CalleeB Rejects Call so I need to send invite to CalleeC > Syntax: "?????" (I need port number to send in invite) You can either use port from (1) or do another call: L call_id remote_ip remote_port to_tag from_tag > 3. I get an OK from CalleeC I now want to stop playing the ring tone to > CalleerA and bridge the call with CallerC > Syntax: "?????" S call_id from_tag to_tag Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com _______________________________________________ Devel mailing list Devel at rtpproxy.org http://lists.rtpproxy.org/mailman/listinfo/devel From sobomax at sippysoft.com Mon Jun 16 00:52:21 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Mon, 16 Jun 2008 00:52:21 -0700 Subject: [RTPproxy Devel] call_id, from_tag and to_tag In-Reply-To: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> References: <44928.194.201.144.25.1212501363.squirrel@secure.trendhosting.net> Message-ID: <48561BB5.7030008@sippysoft.com> Daniel Pocock wrote: > > > I notice that rtpp_session only stores one tag, not both > > If I understand correctly, SIP requires a Call ID, From tag and To tag to > uniquely identify a call. > > Is there any reason why rtpproxy should not store both tags in one > rtpp_session? Is it reasonable to assume a one-one mapping of > rtpp_session and SIP dialog? Well, historically the rtpproxy was developed to work on the ingress side in SER, so that even if the call forked to several destination there would be only one session in the proxy. For that reason it doesn't care about To (aka remote) tag. >>From page 13, RFC 3261 (SIP): > > The combination of the To tag, From tag, > and Call-ID completely defines a peer-to-peer SIP relationship > between Alice and Bob and is referred to as a dialog. Yes, I know. My suggestion to report Call-ID and From tag for now. Sincerely, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com From sobomax at sippysoft.com Thu Jun 19 14:17:48 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Thu, 19 Jun 2008 14:17:48 -0700 Subject: [RTPproxy Devel] RTPproxy 1.1 has bee released Message-ID: <485ACCFC.1040200@sippysoft.com> Hi everybody! Just a quick note that a new stable version 1.1 of RTPproxy has been released. The new release includes performance enhancements and several new features. It's available immediately at http://www.rtpproxy.org. Detailed release notes are here: http://www.b2bua.org/wiki/RTPproxy/RELENG_1_1_0_NOTES Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com From tavis.lists at galaxytelecom.net Tue Jun 24 15:20:40 2008 From: tavis.lists at galaxytelecom.net (Tavis P.) Date: Tue, 24 Jun 2008 15:20:40 -0700 Subject: [RTPproxy Devel] RTPProxy Enhancements - Syslog Support and Relay Port Randomization Message-ID: <48617338.3050500@galaxytelecom.net> Hello, We have added a couple new features to RTPProxy and would like to share them with you. 1: Relay Port Randomization Due to concerns about possible RTP injection attacks we did some work to randomize the ports used for RTP sessions in RTPProxy. In our implementation the RTPProxy application generates a random "path" through the available port range at startup, where RTPProxy selects a random port by simply skipping to the next port in the list of random ports (much like song randomization in certain mp3 players) 2: Syslog support All logging output can now be presented using system, this makes daemon mode logging more visible to the admin (and creates the potential to alert on certain error conditions). There is a new command line argument [-d debug_level] where debug_level is an integer specifying the level of logging . The supported mode are specified via syslog.h, ie on syslog.h 8.1 (Berkeley) 6/2/93: LOG_CRIT 2, LOG_ERR 3, LOG_WARNING 4, LOG_INFO 6, LOG_DEBUG 7 Credits go to: Tavis Paquette Peter Baer The attached patch was tested on version rtpproxy-1.1.tar.gz Cheers! The Galaxy Development Team -------------- next part -------------- A non-text attachment was scrubbed... Name: rtpproxy-1.1.patch Type: text/x-patch Size: 12852 bytes Desc: not available Url : http://lists.rtpproxy.org/pipermail/devel/attachments/20080624/fda7f1f7/attachment.bin From sobomax at sippysoft.com Tue Jun 24 15:35:24 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Tue, 24 Jun 2008 15:35:24 -0700 Subject: [RTPproxy Devel] RTPProxy Enhancements - Syslog Support and Relay Port Randomization In-Reply-To: <48617338.3050500@galaxytelecom.net> References: <48617338.3050500@galaxytelecom.net> Message-ID: <486176AC.4000605@sippysoft.com> Dear Tavis, Thank you very much for your patches. Both features indeed very useful, I will get them integrated in the next few days. Please consider subscribing to the list, so that you can see replies and comments. Tavis P. wrote: > Hello, > > We have added a couple new features to RTPProxy and would like to share > them with you. > > 1: Relay Port Randomization > Due to concerns about possible RTP injection attacks we did some work to > randomize the ports used for RTP sessions in RTPProxy. In our > implementation the RTPProxy application generates a random "path" > through the available port range at startup, where RTPProxy selects a > random port by simply skipping to the next port in the list of random > ports (much like song randomization in certain mp3 players) > > > 2: Syslog support > All logging output can now be presented using system, this makes daemon > mode logging more visible to the admin (and creates the potential to > alert on certain error conditions). > There is a new command line argument [-d debug_level] where debug_level > is an integer specifying the level of logging . > The supported mode are specified via syslog.h, ie on syslog.h 8.1 > (Berkeley) 6/2/93: > LOG_CRIT 2, > LOG_ERR 3, > LOG_WARNING 4, > LOG_INFO 6, > LOG_DEBUG 7 > > Credits go to: > Tavis Paquette > Peter Baer > > > The attached patch was tested on version rtpproxy-1.1.tar.gz Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com From tavis.lists at galaxytelecom.net Tue Jun 24 15:44:16 2008 From: tavis.lists at galaxytelecom.net (Tavis P.) Date: Tue, 24 Jun 2008 15:44:16 -0700 Subject: [RTPproxy Devel] RTPProxy Enhancements - Syslog Support and Relay Port Randomization In-Reply-To: <486176AC.4000605@sippysoft.com> References: <48617338.3050500@galaxytelecom.net> <486176AC.4000605@sippysoft.com> Message-ID: <486178C0.6080108@galaxytelecom.net> Done and done :) Maxim Sobolev wrote: > Dear Tavis, > > Thank you very much for your patches. Both features indeed very useful, > I will get them integrated in the next few days. > > Please consider subscribing to the list, so that you can see replies and > comments. > > Tavis P. wrote: > >> Hello, >> >> We have added a couple new features to RTPProxy and would like to share >> them with you. >> >> 1: Relay Port Randomization >> Due to concerns about possible RTP injection attacks we did some work to >> randomize the ports used for RTP sessions in RTPProxy. In our >> implementation the RTPProxy application generates a random "path" >> through the available port range at startup, where RTPProxy selects a >> random port by simply skipping to the next port in the list of random >> ports (much like song randomization in certain mp3 players) >> >> >> 2: Syslog support >> All logging output can now be presented using system, this makes daemon >> mode logging more visible to the admin (and creates the potential to >> alert on certain error conditions). >> There is a new command line argument [-d debug_level] where debug_level >> is an integer specifying the level of logging . >> The supported mode are specified via syslog.h, ie on syslog.h 8.1 >> (Berkeley) 6/2/93: >> LOG_CRIT 2, >> LOG_ERR 3, >> LOG_WARNING 4, >> LOG_INFO 6, >> LOG_DEBUG 7 >> >> Credits go to: >> Tavis Paquette >> Peter Baer >> >> >> The attached patch was tested on version rtpproxy-1.1.tar.gz >> > > Regards, >