Hello Carsten, What I meant in my previous e-mail, is that the new rtpproxy protocol should take in consideration all those possibilities and the features that applies today to kamailio for the xmlrpc should be specifically imposed via the timeout socket in the lookup request. In other words, instead of assuming that if the timeout socket starts with "http://"; we are dealing with a kamailio server, the kamailio server should be imposed - along with the xmlrcp protocol - inside the lookup request. No new work - at this point in time - should be done inside rtpproxy in order to support new servers or new protocols. The only server supported for now would be kamailio via xmlrpc, but this two parameters must be enforced via the rtpproxy protocol.
If we assume that "http://"; refers to kamailio over xmlrpc, it will be difficult for others to add support for new servers and new protocols if the timeout socket will start with "http://";. All I'm asking for now is to "fix" the rtpprotocol and have a clean start. Regards, Ovidiu Sas On Wed, Aug 25, 2010 at 2:52 AM, Carsten Bock <[email protected]> wrote: > Hi Ovidiu, > > i agree, it would be nice. However, i have a tight schedule right now > (including some holidays :-) ), so i would put these extensions on a > wish list for later enhancements. > For your scenario, it would at least work for systems 1 & 4 (in > parallel) right now, maybe i could add system 2 later; however i think > the adaption for opensips should be done by someone, who is deeper > into opensips.... > > Carsten > > 2010/8/24 Ovidiu Sas <[email protected]>: >> Hello Carsten, >> >> Here are a few observations: >> - kamailio has multiple control interfaces (beside xmlrpc). It would >> be nice to be able to choose over which interface to send the timeout >> notification. Right now, we have only xmlrpc coded into the rtpproxy >> server, but datagram interface is also very appealing (see >> http://www.kamailio.org/docs/modules/3.0.x/modules_k/mi_datagram.html). >> Therefore I would propose specifically adding the communication >> interface to the rtpprotocol instead of assuming that "http://"; is the >> xmlrpc interface. >> - right now, this new feature assumes that kamailio is the only >> server that can handle notification. I would like the server type to >> be passed to the rtpproxy as a parameter, so the rtpproxy can properly >> handle multiple servers and properly craft timeout notifications based >> on server type and communication protocol. >> >> Let's say we have multiple servers using the same rtpproxy server. >> With the above approach, each server will be able to receive proper >> timeout notification: >> - server1: kamailio receiving notifications over xmlrpc >> - server2 : kamailio receiving notifications over datagram >> - server3: opensips receiving notifications over xmlrpc >> - server4: sippy b2bua receiving notifications over "sippy b2bua >> communication protocol" >> >> >> Regards, >> Ovidiu Sas >> >> On Tue, Aug 24, 2010 at 3:18 AM, Carsten Bock <[email protected]> wrote: >>> Hi, >>> >>> please find attached the patch (i removed aclocal.m4, Makefile.in and >>> configure from my local repository, since they are generated by >>> automake). >>> >>> What i changed: >>> - protocol: >>> Lookup existing session (in reverse direction), update if necessary. >>> L[args] callid addr port from_tag to_tag [timeout_socket] >>> >>> Since i do not know the "To-Tag" during the initial Update-request, i >>> need to set the Timeout-Socket when calling "Lookup" >>> - when the timeout-socket begins with "http://";, it is assumed the >>> remote system is a Kamailio-Proxy. The rtpproxy sends a >>> "dlg_terminate_dlg <call-id>" using libxmlrpc towards the Proxy. >>> There is no requirement/dependency for having libxmlrpc installed >>> added, the feature is deactivated if it is missing and the according >>> code-parts are deactivated using a compiler switch. >>> >>> That's about it for now - any feedback is welcome. >>> >>> Carsten >>> >>> >>> 2010/8/24 Maxim Sobolev <[email protected]> >>>> >>>> On 8/22/2010 4:15 AM, Carsten Bock wrote: >>>>> >>>>> i have some improvements ready for the RTP-Proxy (Timeout notification >>>>> using XML-RPC for kamailio-trunk/sip-router.org >>>>> <http://sip-router.org>). My version is developed against rtpproxy-trunk >>>>> (the full source-code is currently as a tar-file on the sip-router >>>>> repository), i can send a patch for it to the list next week. >>>>> Is there a place, where i can put my patches (like the tracker of >>>>> sip-router.org <http://sip-router.org>)? >>>>> I need to validate some other changes (improvements regarding T.38 with >>>>> some Zyxel devices), which at the moment are "quick and dirty" and needs >>>>> some cleanup before i would send patch. >>>> >>>> Carsten, >>>> >>>> We don't have any tracking at the moment, so the best way to send this >>>> patch is to post a link here or to my personal e-mail. I will review it >>>> and either give you my feedback or check it into the trunk. >>>> >>>> Regards, >>>> -- >>>> Maksym Sobolyev >>>> Sippy Software, Inc. >>>> Internet Telephony (VoIP) Experts >>>> T/F: +1-646-651-1110 >>>> Web: http://www.sippysoft.com >>>> MSN: [email protected] >>>> Skype: SippySoft >>> >>> >>> >>> -- >>> Carsten Bock >>> Schomburgstr. 80 >>> 22767 Hamburg >>> Germany >>> >>> Mobile +49 179 2021244 >>> Home +49 40 34927217 >>> Fax +49 40 34927218 >>> mailto:[email protected] >>> >>> _______________________________________________ >>> Devel mailing list >>> [email protected] >>> http://lists.rtpproxy.org/mailman/listinfo/devel >>> >>> >> >> _______________________________________________ >> Devel mailing list >> [email protected] >> http://lists.rtpproxy.org/mailman/listinfo/devel >> > > > > -- > Carsten Bock > Schomburgstr. 80 > 22767 Hamburg > Germany > > Mobile +49 179 2021244 > Home +49 40 34927217 > Fax +49 40 34927218 > mailto:[email protected] > > _______________________________________________ > Devel mailing list > [email protected] > http://lists.rtpproxy.org/mailman/listinfo/devel > _______________________________________________ Devel mailing list [email protected] http://lists.rtpproxy.org/mailman/listinfo/devel
