Hi, just in case, i forgot to attach my patch to the previous mail, i have attached it to this mail.
Kind regards, Carsten 2010/8/30 Carsten Bock <[email protected]>: > 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] > -- Carsten Bock Schomburgstr. 80 22767 Hamburg Germany Mobile +49 179 2021244 Home +49 40 34927217 Fax +49 40 34927218 mailto:[email protected]
rtpproxy.patch
Description: Binary data
_______________________________________________ Devel mailing list [email protected] http://lists.rtpproxy.org/mailman/listinfo/devel
