[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

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

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

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

[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

[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

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

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

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: [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

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

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

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. :)

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

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