Hi, i changed my patch accordingly: Instead of checking the timeout-socket string for "http://";, an optional timeout_socket_type can be provided on the interface (with now 0 for "native/current support" and 1 for the Kamailio-XML-RPC-Socket). I have adapted my rtpproxy-module of kamailio (branch carstenbock/rtpproxy) accordingly. Please review my patch and give me feedback.
Carsten 2010/8/26 Carsten Bock <[email protected]>: > Hi Ovidiu, > > now i understood, what you meant. > I will adapt this in the next days.... > > Carsten > > 2010/8/26 Ovidiu Sas <[email protected]>: >> 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 >> > > > > -- > Carsten Bock > Schomburgstr. 80 > 22767 Hamburg > Germany > > Mobile +49 179 2021244 > Home +49 40 34927217 > Fax +49 40 34927218 > mailto:[email protected] > -- 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
