Re: [OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc

[Bobby Smith]

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

> 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

Re: [OpenSIPS-Users] Prevent re-INVITE to T.38

[Ovidiu Sas]

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  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  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 
>> 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 
>>> 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 
 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
>  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 
>> написал(а):
>>
>> 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] Prevent re-INVITE to T.38

[Jeff Pyle]

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  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 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 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 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 
> написал(а):
>
> 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] Presence: "xmlns" attributes inside element not compliant to RFC3863

[Martin Stock]

Hi,

thanks for your answer.

>> With OpenSIPS 1.10 the namespace attributes are not defined inside 
the  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  element.

>> I don't find any UA that works with this  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 
 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  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

[Ovidiu Sas]

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  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  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 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 
 написал(а):

 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] Prevent re-INVITE to T.38

[Jeff Pyle]

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  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 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 
>>> написал(а):
>>>
>>> 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

[Ovidiu Sas]

Remove the codec and let the re-INVITE go through.

Regards,
Ovidiu Sas



On Tue, Mar 11, 2014 at 1:42 PM, Jeff Pyle  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 
>> написал(а):
>>
>> 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

[Jeff Pyle]

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  написал(а):
>
> 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

[Alexander Mustafin]

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  написал(а):

> 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

[OpenSIPS-Users] Prevent re-INVITE to T.38

[Jeff Pyle]

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

[OpenSIPS-Users] How to check SIP connection to UA?

[Dragomir Haralambiev]

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

Re: [OpenSIPS-Users] variables

[Mike Claudi Pedersen]

thx.. i think you provided the information i needed


2014-03-11 11:50 GMT+01:00 Răzvan Crainea :

> 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
>> 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 
>>
>>
>> ___
>> 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

Re: [OpenSIPS-Users] variables

[Răzvan Crainea]

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


___
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

[Mike Claudi Pedersen]

 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 :

> 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

[OpenSIPS-Users] variables

[Mike Claudi Pedersen]

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