[OpenSIPS-Users] variables
Hi fellow sippers can anyone point me to documentation on what kind of variables you are able to use to define which part of the sip you want to look at. like TO, FROM, URI i cant seem to find any documentation on this ? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] variables
Hi fellow sippers can anyone point me to documentation on what kind of variables you are able to use to define which part of the sip you want to look at. like TO, FROM, URI i cant seem to find any documentation on this ? 2014-03-11 11:09 GMT+01:00 Mike Claudi Pedersen mike.peder...@ipnordic.dk: Hi fellow sippers can anyone point me to documentation on what kind of variables you are able to use to define which part of the sip you want to look at. like TO, FROM, URI i cant seem to find any documentation on this ? -- Med venlig hilsen ipnordic A/S Mike Claudi Pedersen Tekniker Telefon: 79301033 www.ipnordic.dk ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] variables
Hi, Mike! You can find here[1] the core pseudo variables for OpenSIPS 1.8. Each module has it's own variable, for example[2]. If you need a variable from a module, you should search in that module's documentation page. For example, if you need the number of onging calls, you should look in the dialog documentation page[2]. [1] http://www.opensips.org/Documentation/Script-CoreVar-1-8 [2] http://www.opensips.org/html/docs/modules/1.8.x/dialog.html#id296368 Best regards, Razvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 03/11/2014 12:11 PM, Mike Claudi Pedersen wrote: Hi fellow sippers can anyone point me to documentation on what kind of variables you are able to use to define which part of the sip you want to look at. like TO, FROM, URI i cant seem to find any documentation on this ? 2014-03-11 11:09 GMT+01:00 Mike Claudi Pedersen mike.peder...@ipnordic.dk mailto:mike.peder...@ipnordic.dk: Hi fellow sippers can anyone point me to documentation on what kind of variables you are able to use to define which part of the sip you want to look at. like TO, FROM, URI i cant seem to find any documentation on this ? -- Med venlig hilsen ipnordic A/S Mike Claudi Pedersen Tekniker Telefon: 79301033 www.ipnordic.dk http://www.ipnordic.dk/ ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] variables
thx.. i think you provided the information i needed 2014-03-11 11:50 GMT+01:00 Răzvan Crainea raz...@opensips.org: Hi, Mike! You can find here[1] the core pseudo variables for OpenSIPS 1.8. Each module has it's own variable, for example[2]. If you need a variable from a module, you should search in that module's documentation page. For example, if you need the number of onging calls, you should look in the dialog documentation page[2]. [1] http://www.opensips.org/Documentation/Script-CoreVar-1-8 [2] http://www.opensips.org/html/docs/modules/1.8.x/dialog.html#id296368 Best regards, Razvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 03/11/2014 12:11 PM, Mike Claudi Pedersen wrote: Hi fellow sippers can anyone point me to documentation on what kind of variables you are able to use to define which part of the sip you want to look at. like TO, FROM, URI i cant seem to find any documentation on this ? 2014-03-11 11:09 GMT+01:00 Mike Claudi Pedersen mike.peder...@ipnordic.dk mailto:mike.peder...@ipnordic.dk: Hi fellow sippers can anyone point me to documentation on what kind of variables you are able to use to define which part of the sip you want to look at. like TO, FROM, URI i cant seem to find any documentation on this ? -- Med venlig hilsen ipnordic A/S Mike Claudi Pedersen Tekniker Telefon: 79301033 www.ipnordic.dk http://www.ipnordic.dk/ ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Med venlig hilsen ipnordic A/S Mike Claudi Pedersen Tekniker Telefon: 79301033 www.ipnordic.dk ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] How to check SIP connection to UA?
Hello, I have calls with follow connection: UA ( NAT server )- OpnSips - real IP (with NAT support). How to setup Opensips to checking SIP connection with UA? I need to close call when connection between UA nad NAT server is down. Thanks in advance, PlayMen ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Prevent re-INVITE to T.38
Hello, Is there anything I can do at the proxy level to prevent a dialog from reinviting to to T.38? I think I could detect the T.38 attributes easily enough and respond with a 488, although I'm concerned the CSeq values would be out of sequence for the next transaction that did make it through the proxy to the far end. That could cause a problem, no? Is this something that requires a B2BUA? Is it possible from within the OpenSIPS B2B modules to do SDP inspection of any sort? - Jeff ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
Hi, Jeff. Maybe stream_exists(regexp) in sipmsgops module will be useful for you. Best regards, Alexander Mustafin mustafin.aleksa...@gmail.com 11 марта 2014 г., в 20:07, Jeff Pyle jp...@fidelityvoice.com написал(а): Hello, Is there anything I can do at the proxy level to prevent a dialog from reinviting to to T.38? I think I could detect the T.38 attributes easily enough and respond with a 488, although I'm concerned the CSeq values would be out of sequence for the next transaction that did make it through the proxy to the far end. That could cause a problem, no? Is this something that requires a B2BUA? Is it possible from within the OpenSIPS B2B modules to do SDP inspection of any sort? - Jeff ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users signature.asc Description: Message signed with OpenPGP using GPGMail ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
Hi Alexander, To detect the image session in the SDP, you are thinking the same way that I am. The problem I see is how to actually reject the re-INVITE. If I were to do something like a sl_send_reply(488, Not Acceptable Here), that would work in the moment, but the CSeq values would be increased by one on side compared to the other. That sounds to me like a recipe for problems in future in-dialog transactions (like BYE). - Jeff On Tue, Mar 11, 2014 at 12:58 PM, Alexander Mustafin mustafin.aleksa...@gmail.com wrote: Hi, Jeff. Maybe stream_exists(regexp) in sipmsgops module will be useful for you. Best regards, Alexander Mustafin mustafin.aleksa...@gmail.com 11 марта 2014 г., в 20:07, Jeff Pyle jp...@fidelityvoice.com написал(а): Hello, Is there anything I can do at the proxy level to prevent a dialog from reinviting to to T.38? I think I could detect the T.38 attributes easily enough and respond with a 488, although I'm concerned the CSeq values would be out of sequence for the next transaction that did make it through the proxy to the far end. That could cause a problem, no? Is this something that requires a B2BUA? Is it possible from within the OpenSIPS B2B modules to do SDP inspection of any sort? - Jeff ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
Remove the codec and let the re-INVITE go through. Regards, Ovidiu Sas On Tue, Mar 11, 2014 at 1:42 PM, Jeff Pyle jp...@fidelityvoice.com wrote: Hi Alexander, To detect the image session in the SDP, you are thinking the same way that I am. The problem I see is how to actually reject the re-INVITE. If I were to do something like a sl_send_reply(488, Not Acceptable Here), that would work in the moment, but the CSeq values would be increased by one on side compared to the other. That sounds to me like a recipe for problems in future in-dialog transactions (like BYE). - Jeff On Tue, Mar 11, 2014 at 12:58 PM, Alexander Mustafin mustafin.aleksa...@gmail.com wrote: Hi, Jeff. Maybe stream_exists(regexp) in sipmsgops module will be useful for you. Best regards, Alexander Mustafin mustafin.aleksa...@gmail.com 11 марта 2014 г., в 20:07, Jeff Pyle jp...@fidelityvoice.com написал(а): Hello, Is there anything I can do at the proxy level to prevent a dialog from reinviting to to T.38? I think I could detect the T.38 attributes easily enough and respond with a 488, although I'm concerned the CSeq values would be out of sequence for the next transaction that did make it through the proxy to the far end. That could cause a problem, no? Is this something that requires a B2BUA? Is it possible from within the OpenSIPS B2B modules to do SDP inspection of any sort? - Jeff ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
Hi Ovidiu, In the case of a pure T.38 SDP offer like this: v=0 o=- 1394560461 1394560461 IN IP4 192.168.58.4 s=- c=IN IP4 192.168.58.4 t=0 0 m=image 16426 udptl t38 a=T38FaxVersion:0 a=T38FaxRateManagement:transferredTCF a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38MaxBitRate:14400 a=T38FaxUdpEC:t38UDPRedundancy a=T38FaxMaxBuffer:600 a=T38FaxMaxDatagram:200 Which codec would I remove? - Jeff On Tue, Mar 11, 2014 at 1:44 PM, Ovidiu Sas o...@voipembedded.com wrote: Remove the codec and let the re-INVITE go through. Regards, Ovidiu Sas On Tue, Mar 11, 2014 at 1:42 PM, Jeff Pyle jp...@fidelityvoice.comwrote: Hi Alexander, To detect the image session in the SDP, you are thinking the same way that I am. The problem I see is how to actually reject the re-INVITE. If I were to do something like a sl_send_reply(488, Not Acceptable Here), that would work in the moment, but the CSeq values would be increased by one on side compared to the other. That sounds to me like a recipe for problems in future in-dialog transactions (like BYE). - Jeff On Tue, Mar 11, 2014 at 12:58 PM, Alexander Mustafin mustafin.aleksa...@gmail.com wrote: Hi, Jeff. Maybe stream_exists(regexp) in sipmsgops module will be useful for you. Best regards, Alexander Mustafin mustafin.aleksa...@gmail.com 11 марта 2014 г., в 20:07, Jeff Pyle jp...@fidelityvoice.com написал(а): Hello, Is there anything I can do at the proxy level to prevent a dialog from reinviting to to T.38? I think I could detect the T.38 attributes easily enough and respond with a 488, although I'm concerned the CSeq values would be out of sequence for the next transaction that did make it through the proxy to the far end. That could cause a problem, no? Is this something that requires a B2BUA? Is it possible from within the OpenSIPS B2B modules to do SDP inspection of any sort? - Jeff ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
Then remove completely the SDP. The other endpoint should offer the previous codec. The renegotiation should fail and hopefully the call will still stay on ... Regards, Ovidiu Sas On Tue, Mar 11, 2014 at 1:56 PM, Jeff Pyle jp...@fidelityvoice.com wrote: Hi Ovidiu, In the case of a pure T.38 SDP offer like this: v=0 o=- 1394560461 1394560461 IN IP4 192.168.58.4 s=- c=IN IP4 192.168.58.4 t=0 0 m=image 16426 udptl t38 a=T38FaxVersion:0 a=T38FaxRateManagement:transferredTCF a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38MaxBitRate:14400 a=T38FaxUdpEC:t38UDPRedundancy a=T38FaxMaxBuffer:600 a=T38FaxMaxDatagram:200 Which codec would I remove? - Jeff On Tue, Mar 11, 2014 at 1:44 PM, Ovidiu Sas o...@voipembedded.com wrote: Remove the codec and let the re-INVITE go through. Regards, Ovidiu Sas On Tue, Mar 11, 2014 at 1:42 PM, Jeff Pyle jp...@fidelityvoice.comwrote: Hi Alexander, To detect the image session in the SDP, you are thinking the same way that I am. The problem I see is how to actually reject the re-INVITE. If I were to do something like a sl_send_reply(488, Not Acceptable Here), that would work in the moment, but the CSeq values would be increased by one on side compared to the other. That sounds to me like a recipe for problems in future in-dialog transactions (like BYE). - Jeff On Tue, Mar 11, 2014 at 12:58 PM, Alexander Mustafin mustafin.aleksa...@gmail.com wrote: Hi, Jeff. Maybe stream_exists(regexp) in sipmsgops module will be useful for you. Best regards, Alexander Mustafin mustafin.aleksa...@gmail.com 11 марта 2014 г., в 20:07, Jeff Pyle jp...@fidelityvoice.com написал(а): Hello, Is there anything I can do at the proxy level to prevent a dialog from reinviting to to T.38? I think I could detect the T.38 attributes easily enough and respond with a 488, although I'm concerned the CSeq values would be out of sequence for the next transaction that did make it through the proxy to the far end. That could cause a problem, no? Is this something that requires a B2BUA? Is it possible from within the OpenSIPS B2B modules to do SDP inspection of any sort? - Jeff ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence: xmlns attributes inside tuple element not compliant to RFC3863
Hi, thanks for your answer. With OpenSIPS 1.10 the namespace attributes are not defined inside the presence element. Referring to RFC3863, Section 4.1.1 (https://tools.ietf.org/html/rfc3863#page-5) IMHO this is not intended. I'm not sure what you mean. What attributes are not defined? In the RFC the xmlns attribute is only described for the presence element. I don't find any UA that works with this presence element. Any client based on SIP SIMPLE Client SDK (such as Blink) works with those documents. Yeah, sorry, it's my fault. I only looked in my traces. Now, I have visually confirmed (e.g: Jitsi) that the user has changed his status. I never saw before, that a client/server wrote his namespaces in the tuple element. Is this a bug or are there options to tweak this? What do you need to tweak? (the encoding bug aside) We have a lot of soft clients in use, that are not capable to handle presence elements with this structure. E.g. the Ninja or Juggler soft client are not working and those are not based on the SIP SIMPLE SDK. Is it possible to tweak the structure of the presence element in OpenSIPS 1.10? Thanks in advance. Regards Martin ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
By removing the SDP, am I not causing a late-offer behavior? The B-leg would expect an SDP on the ACK from the A-leg (which it's not going to get), and the A-leg is going to wonder why its T.38 SDP was answered with, say, a G.711 one. I've yelled at customers for pulling stuff like that. :) - Jeff On Tue, Mar 11, 2014 at 2:00 PM, Ovidiu Sas o...@voipembedded.com wrote: Then remove completely the SDP. The other endpoint should offer the previous codec. The renegotiation should fail and hopefully the call will still stay on ... Regards, Ovidiu Sas On Tue, Mar 11, 2014 at 1:56 PM, Jeff Pyle jp...@fidelityvoice.comwrote: Hi Ovidiu, In the case of a pure T.38 SDP offer like this: v=0 o=- 1394560461 1394560461 IN IP4 192.168.58.4 s=- c=IN IP4 192.168.58.4 t=0 0 m=image 16426 udptl t38 a=T38FaxVersion:0 a=T38FaxRateManagement:transferredTCF a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38MaxBitRate:14400 a=T38FaxUdpEC:t38UDPRedundancy a=T38FaxMaxBuffer:600 a=T38FaxMaxDatagram:200 Which codec would I remove? - Jeff On Tue, Mar 11, 2014 at 1:44 PM, Ovidiu Sas o...@voipembedded.comwrote: Remove the codec and let the re-INVITE go through. Regards, Ovidiu Sas On Tue, Mar 11, 2014 at 1:42 PM, Jeff Pyle jp...@fidelityvoice.comwrote: Hi Alexander, To detect the image session in the SDP, you are thinking the same way that I am. The problem I see is how to actually reject the re-INVITE. If I were to do something like a sl_send_reply(488, Not Acceptable Here), that would work in the moment, but the CSeq values would be increased by one on side compared to the other. That sounds to me like a recipe for problems in future in-dialog transactions (like BYE). - Jeff On Tue, Mar 11, 2014 at 12:58 PM, Alexander Mustafin mustafin.aleksa...@gmail.com wrote: Hi, Jeff. Maybe stream_exists(regexp) in sipmsgops module will be useful for you. Best regards, Alexander Mustafin mustafin.aleksa...@gmail.com 11 марта 2014 г., в 20:07, Jeff Pyle jp...@fidelityvoice.com написал(а): Hello, Is there anything I can do at the proxy level to prevent a dialog from reinviting to to T.38? I think I could detect the T.38 attributes easily enough and respond with a 488, although I'm concerned the CSeq values would be out of sequence for the next transaction that did make it through the proxy to the far end. That could cause a problem, no? Is this something that requires a B2BUA? Is it possible from within the OpenSIPS B2B modules to do SDP inspection of any sort? - Jeff ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Prevent re-INVITE to T.38
Well, then your out of luck here. Even if there's no SDP in ACK, should be fine. On the other hand, if one end doesn't support T.38 and the other end is insisting on it, the call will fail, so you can just drop the call there. -ovidiu On Tue, Mar 11, 2014 at 3:14 PM, Jeff Pyle jp...@fidelityvoice.com wrote: By removing the SDP, am I not causing a late-offer behavior? The B-leg would expect an SDP on the ACK from the A-leg (which it's not going to get), and the A-leg is going to wonder why its T.38 SDP was answered with, say, a G.711 one. I've yelled at customers for pulling stuff like that. :) - Jeff On Tue, Mar 11, 2014 at 2:00 PM, Ovidiu Sas o...@voipembedded.com wrote: Then remove completely the SDP. The other endpoint should offer the previous codec. The renegotiation should fail and hopefully the call will still stay on ... Regards, Ovidiu Sas On Tue, Mar 11, 2014 at 1:56 PM, Jeff Pyle jp...@fidelityvoice.com wrote: Hi Ovidiu, In the case of a pure T.38 SDP offer like this: v=0 o=- 1394560461 1394560461 IN IP4 192.168.58.4 s=- c=IN IP4 192.168.58.4 t=0 0 m=image 16426 udptl t38 a=T38FaxVersion:0 a=T38FaxRateManagement:transferredTCF a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38MaxBitRate:14400 a=T38FaxUdpEC:t38UDPRedundancy a=T38FaxMaxBuffer:600 a=T38FaxMaxDatagram:200 Which codec would I remove? - Jeff On Tue, Mar 11, 2014 at 1:44 PM, Ovidiu Sas o...@voipembedded.com wrote: Remove the codec and let the re-INVITE go through. Regards, Ovidiu Sas On Tue, Mar 11, 2014 at 1:42 PM, Jeff Pyle jp...@fidelityvoice.com wrote: Hi Alexander, To detect the image session in the SDP, you are thinking the same way that I am. The problem I see is how to actually reject the re-INVITE. If I were to do something like a sl_send_reply(488, Not Acceptable Here), that would work in the moment, but the CSeq values would be increased by one on side compared to the other. That sounds to me like a recipe for problems in future in-dialog transactions (like BYE). - Jeff On Tue, Mar 11, 2014 at 12:58 PM, Alexander Mustafin mustafin.aleksa...@gmail.com wrote: Hi, Jeff. Maybe stream_exists(regexp) in sipmsgops module will be useful for you. Best regards, Alexander Mustafin mustafin.aleksa...@gmail.com 11 марта 2014 г., в 20:07, Jeff Pyle jp...@fidelityvoice.com написал(а): Hello, Is there anything I can do at the proxy level to prevent a dialog from reinviting to to T.38? I think I could detect the T.38 attributes easily enough and respond with a 488, although I'm concerned the CSeq values would be out of sequence for the next transaction that did make it through the proxy to the far end. That could cause a problem, no? Is this something that requires a B2BUA? Is it possible from within the OpenSIPS B2B modules to do SDP inspection of any sort? - Jeff ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc
The one thing we find annoying about deprecating this is that it's not a drop in replacement for the current xmlrpc implementation. We have a lot of system level monitoring an alerting (things like fraud checking, rate limiting, reporting to external systems) that rely upon accessing fifo via xmlrpc, and the format for the content responses returned by the new mi_xmlrpc_ng module is not the same as the old module (I don't remember the details off the top of my head, but basically it was a difference being double colon delimited and something else). It would really be beneficial if there was a way to control or configure the format of the xml response to line up the same as the old formatting, so that we could use it as a drop in replacement and not have to go rewrite a hundred different alerts/scripts that rely upon mi_xmlrpc's current format. On Fri, Mar 7, 2014 at 6:26 AM, Bogdan-Andrei Iancu bog...@opensips.orgwrote: Hello all, I would appreciate your input/opinions in the matter of deprecating the mi_xmlrpc module in favor of mi_xmlrpc_ng + httpd modules. Both modules offer the same functionality : XMLRPC backend for the Management Interface (see ww.opensips.org/Documentation/Interface-MI-1-10 ). The old mi_xmlrpc module use the libxmlrpc-c3 external library for the HTTP server and XMLRPC engine. This library was a source of problems along the years because of the difficulty in using it (threads versus processes support) - the user experience was horrible in trying to have this library properly working on various OS distros. The new mi_xmlrpc_ng module uses the httpd support from OpenSIPS and the generic libxml library - this is a safer and more robust approach ; users will find really easy to deploy these modules, to configure them (not to mention flexibility when comes to setting, restricting access, etc). So, I would suggest to terminate the mi_xmlrpc module and officially have the mi_xmlrpc_ng module for the XMLRPC backend. Comments, opinions are, as always, more than welcome. References : - mi_xmlrpc module - http://www.opensips.org/html/ docs/modules/1.10.x/mi_xmlrpc.html - mi_xmlrpc_ng module - http://www.opensips.org/html/ docs/modules/1.10.x/mi_xmlrpc_ng.html Regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
