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] _______________________________________________ Devel mailing list [email protected] http://lists.rtpproxy.org/mailman/listinfo/devel
