Re: [OpenSIPS-Users] Managing the implicit subscription and its NOTIFYs within B2BUA REFER handling

[Jeff Pyle]

Great.  Is it still recommended to keep a particular OpenSIPS instance
either all proxy commands or all B2B commands?  Or, do we have some
flexibility to mix them since B2B commands live in the script now?


- Jeff


On Wed, Jan 26, 2022 at 9:50 AM Vlad Patrascu  wrote:

> Hi Jeff,
>
> Sending NOTIFYs is supported by using the "n" flag for the b2b_bridge()
> [1] function. Just note that some mechanisms from RFC 3515 2.4.4
> <https://datatracker.ietf.org/doc/html/rfc3515#section-2.4.4> are not
> implemented though, such as the ability to terminate the subscription
> prematurely by unsubscribing or refreshing the subscription.
>
> [1] https://opensips.org/docs/modules/3.2.x/b2b_logic.html#func_b2b_bridge
>
> Regards,
>
> --
> Vlad Patrascu
> OpenSIPS Core Developerhttp://www.opensips-solutions.com
>
> On 24.01.2022 17:38, Jeff Pyle wrote:
>
> OpenSIPS 3.2 supports some slick in-script B2B functions, documented here
> [1] with an example for handling REFER.  Does this approach include
> support for the subscription and the subsequent NOTIFYs required by RFC
> 3515 2.4.4 [2]
> <https://datatracker.ietf.org/doc/html/rfc3515#section-2.4.4>?
>
> I have a need to write some REFER handling functions into an existing
> OpenSIPS SBC stack, and I need to send accurate NOTIFYs back to the
> REFER-er.  Terminating the subscription with the first NOTIFY isn't good
> enough, sadly.  I'm hoping this is the right way to do it.
>
>   [1]  https://www.opensips.org/Documentation/Tutorials-B2BUA-3-2#toc10
>   [2]  https://datatracker.ietf.org/doc/html/rfc3515#section-2.4.4
>
>
> - Jeff
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://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

[OpenSIPS-Users] Managing the implicit subscription and its NOTIFYs within B2BUA REFER handling

[Jeff Pyle]

OpenSIPS 3.2 supports some slick in-script B2B functions, documented here
[1] <[1] https://www.opensips.org/Documentation/Tutorials-B2BUA-3-2#toc10>
with an example for handling REFER.  Does this approach include support for
the subscription and the subsequent NOTIFYs required by RFC 3515 2.4.4 [2]
?

I have a need to write some REFER handling functions into an existing
OpenSIPS SBC stack, and I need to send accurate NOTIFYs back to the
REFER-er.  Terminating the subscription with the first NOTIFY isn't good
enough, sadly.  I'm hoping this is the right way to do it.

  [1]  https://www.opensips.org/Documentation/Tutorials-B2BUA-3-2#toc10
  [2]  https://datatracker.ietf.org/doc/html/rfc3515#section-2.4.4


- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] TCP-related errors

[Jeff Pyle]

Hello,

I have two similarly configured systems running a recent OpenSIPS 3.2 with
may errors like this:

CRITICAL:core:io_watch_add:
>>> fd_array idx 1 (fd=193) points to bogus map
(fd=-1,type=0,flags=2000,data=(nil))

It seems you have hit a programming bug.
Please help us make OpenSIPS better by reporting it at
https://github.com/OpenSIPS/opensips/issues

and

ERROR:tls_openssl:openssl_tls_async_connect: failed to retrieve SO_ERROR
[server=52.114.76.76:5061] (3) No such process
ERROR:proto_tls:tls_async_write: failed to do pre-tls handshake!
ERROR:tls_openssl:openssl_tls_accept: SSL_ERROR_SYSCALL err=Success(0)
ERROR:tls_openssl:openssl_tls_accept: New TLS connection from
52.114.32.169:6912 failed to accept
ERROR:proto_tls:tls_read_req: failed to do pre-tls handshake!
ERROR:tls_openssl:openssl_tls_accept: SSL_ERROR_SYSCALL err=Success(0)
ERROR:tls_openssl:openssl_tls_accept: New TLS connection from
52.114.132.46:3008 failed to accept
ERROR:proto_tls:tls_read_req: failed to do pre-tls handshake!
ERROR:tls_openssl:openssl_tls_accept: SSL_ERROR_SYSCALL err=Success(0)
ERROR:tls_openssl:openssl_tls_accept: New TLS connection from
52.114.32.169:3072 failed to accept

I'm wondering if this is truly a bug as the text suggests, or if I have a
misconfiguration.  I increased the number of file descriptors available to
opensips in /etc/security/limits.conf on one of the systems about 10
minutes ago, and so far, no more errors.  Normally I would have seen them
by now.

Both systems have low traffic, less than 1 cps.

I don't have a lot of experience using OpenSIPS with TCP.  It wouldn't
surprise me if I've missed something.



- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] double sdp.

[Jeff Pyle]

Johan,

To avoid problems like this, I call rtpengine_offer() in branch_route on
initial invites, and make sure to call rtpengine_delete() in any failure
route to remove any session from a failed offer that was never used.
Perhaps these will help in your situation as well.


- Jeff


On Mon, Oct 18, 2021 at 11:37 AM Johan De Clercq  wrote:

> Hi,
>
> A and B are on the same proxy.
>
> A calls B,
> (as I need transcoding I need to call rtpengine_offer here)
> B returns 183 with SDP.
>  (this implies calling rtpengine_answer in onreply_route)
>  B lets the call time out
> On the proxy I intercept the 480 returned by B
> and I change the INVITE so that it point to SEMS
>   (this ismplies calling rtpengine_offer again)
>
> Issue: when you call 2x rtpengine_offer, you end up with a double sdp
> body.
>
> So,
> how can I instruct opensips to overwrite the body instead of appending one
> ?
>
> wkr,
> ___
> 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

[OpenSIPS-Users] rtpengine weight configuration

[Jeff Pyle]

Hello,

This is on OpenSIPS 2.4, although I suspect the answer will be the same for
any modern-ish OpenSIPS version.

I have a collection of rtpengine entries loaded into the rtpengine table.
All works well.  The "rtpengine_show" fifo command lists them all with
weight=1.  If I'd like to load some relays more than others, where does one
adjust the weights?  I see reference in the module documentation that
weight will be used within a set, but not where to define them per relay.


Regards,
Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] rtpengine sets - load balancing proxy weighting

[Jeff Pyle]

This may be a good place to ask this, or perhaps not.

Is it possible to define the DB rows in such a way that causes a
priority-based behavior?  Prefer this one, move to the next if the first
isn't available, etc.  As I think through it, it may be possible to do that
manually in the script by calling different groups, but it would be more
convenient if it just worked as a function of the schema.

For example, the way one defines gateways for use in the dr_carriers table
as part of the drouting module.  Something like that if that makes sense.


Regards,
Jeff


On Fri, Aug 20, 2021 at 9:38 AM John Burke via Users <
users@lists.opensips.org> wrote:

> Hey Mark,
>
> The load balancing weights are set on a per node basis via their socket
> URL. If no weight is explicitly set, then the default is 1.
>
> schema:
> ::(=)
>
> ex:
> udp:192.168.1.200:2=25
>
> There currently is no way to dynamically change the weight of a node,
> although there's an open PR [1] which would allow for weights to be changed
> via the "rtpengine_enable" MI command.
>
> [1] https://github.com/OpenSIPS/opensips/pull/2600
>
> Thanks,
> John Burke
>
>
> On 8/20/21 5:00 AM, Mark Allen wrote:
>
> I've not been able to find the answer to this. Can anyone help?
>
> On Thu, 22 Jul 2021 at 11:02, Mark Allen  wrote:
>
>> In the rtpengine documentation [1] in the section "1.2 - Multiple RTP
>> proxy usage" it says...
>>
>> "The balancing inside a set is done automatically by the module based
>> on the weight of each RTP proxy from the set."
>>
>>
>> ...how is the weighting determined? Is there a parameter to allocate a
>> weighting value, is weighting allocated by the software dynamically (and if
>> so, based on what criteria?), or are all proxies weighted the same?
>>
>>
>>
>> [1]
>> https://opensips.org/html/docs/modules/3.1.x/rtpengine.html#idp4123616
>>
>>
>>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://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] strange behavior with TCP reply port

[Jeff Pyle]

Hi Liviu,

You're probably right.  And, force_rport() appears to solve the problem.
I'm calling it first thing in the script so all the replies go to the right
place.  Basic testing seems okay, even on UDP connections into proxy where
everything is 5060.

Do you have any thoughts what this might break?


- Jeff


On Mon, Aug 16, 2021 at 4:06 PM Liviu Chircu  wrote:

> On 11.08.2021 22:01, Jeff Pyle wrote:
>
> the sl_send_reply() function opens a new TCP socket to the UAC on the
> IP:port listed in the original message's Contact, rather than sending the
> 100 on the existing socket (using the ephemeral port)
>
> Hi, Jeff!
>
> Just to frame the problem better: are you sure the reply's target IP:port
> is equal to the request's Contact header and not the topmost Via header?
> Maybe a *force_rport()* before calling *sl_send_reply()* is everything
> that's needed here.  *fingers crossed*
>
> Best,
>
> --
> Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com
> OpenSIPS Summit 2021 Distributed | www.opensips.org/events
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] strange behavior with TCP reply port

[Jeff Pyle]

Hello,

This is on the 3.1.3~20210731~b333a222f-1 from the Debian 3.1-nightly repo.

Typically I run with

  modparam("tm", "auto_100trying", 0)

so I can manually send a 100 with

  sl_send_reply(100, "Trying");

earlier in the script, before blocking processes like DB lookups and such.
No problem...until today.  On a TCP (TLS) connection, the sl_send_reply()
function opens a new TCP socket to the UAC on the IP:port listed in the
original message's Contact, rather than sending the 100 on the existing
socket (using the ephemeral port) the UAC used for its TCP socket to us.
Future downstream replies are relayed back upstream to the ephemeral port.
In other words, only the 100 Trying message from sl_send_reply() is opening
a new socket back upstream.

The auto_100trying option from tm, however, sends its 100 messages to the
ephemeral port of the UAC.

How can I get the sl_send_reply() function to reply on the existing TCP
socket?


Regards,
Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Delayed Bye?

[Jeff Pyle]

Eek.  This sounds like a recipe for future problems with this carrier.  If
you really want to try, you could do a sleep() or usleep() on BYE requests
in the section of your script that processes sequential requeststhe
has_totag() and loose_route() part (assuming no topology_hiding).  That's
going to occupy the process, though, so you might want to look at doing it
async-style if scale is a concern.  If you want to do it only on BYE
requests to the carrier rather than on BYE requests in both directions,
then you'll have to detect the direction, which is possible but gets more
involved.

I know I'm going to regret asking this, but why does your carrier want you
to delay your BYE messages?


- Jeff


On Sun, Jun 27, 2021 at 5:07 PM Alexander Perkins <
alexanderhenryperk...@gmail.com> wrote:

> Hi All.  Our carrier has asked us if we can do a 'delayed bye'.  I have no
> idea what this means.  The way it was explained to me is -  the b-let is
> held for x numbers of seconds after the a leg hangs up.
>
> Does that make sense?  If so, can someone point me in the right direction?
>
> Thank you,
> Alex
> ___
> 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] Remove previously added header

[Jeff Pyle]

Add it in a branch_route.  That way if you have to route advance, it'll
already be gone because you'll be on a new branch.


- Jeff


On Mon, Jun 14, 2021 at 5:52 PM David Villasmil <
david.villasmil.w...@gmail.com> wrote:

> Hello guys,
>
> So, I'm appending a header (append_hf("header")) to a forward.
> That forward fails and I'm trying to remove it with remove_hf("header"),
> but it's not getting removed for some reason, what am I doing wrong?
>
> Thanks everyone!
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
> ___
> 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] Getting header from 302

[Jeff Pyle]

I've been working on a proxy to sit between MS Teams and "normal" SIP
stacks.  Teams sends way too many 180s and RTP-less 183s so I sanitize them
like this:

onreply_route[relay_reply] {
if (t_check_status("180")) {
if (isflagset("GOT_180")) {
drop;
} else {
setflag("GOT_180");
}
}

if (isflagset("GOT_180") && t_check_status("183")) {
drop;
}
}

With this I stop superfluous 18x messages from being relayed downstream.
The 'drop' here kills the message completely.  You could include the drop
if you want to stop the message from being relayed (which you probably do)
and are finished processing it in the script (which you are probably not).

If I understand your application correctly, I'd populate the AVP in the
reply route and do everything else in the failure route.  Or, try Liviu's
suggestion of using $(hdr(Identity)) in the failure_route directly.
Either way, then continue in the failure_route to do whatever else needs to
happen.


- Jeff



On Wed, Jun 2, 2021 at 2:10 PM David Villasmil <
david.villasmil.w...@gmail.com> wrote:

> Hello Jeff,
>
> That's exactly what I'm doing:
>
> # Relay to REDIRECT server
> route[relay_to_REDIRECT]
> {
> t_on_reply("reply_from_REDIRECT");
> t_on_failure("failure_from_REDIRECT");
>
> xlog("L_ERR", "[$ci][$rm]: Relaying to REDIRECT");
> if (!t_relay()) {
> xlog("L_ERR", "[$ci][$rm]: unable to relay request $ru to $tU --
> replying with error");
> sl_reply_error();
> }
>
> exit;
> }
>
> # Response from REDIRECT will come in here.
> failure_route[failure_from_REDIRECT]
> {
> xlog("L_ERR", "[$ci][$rm]: I'm in
> failure_route[failover_from_REDIRECT]");
> if (t_was_cancelled()) {
> exit;
> }
>
> if(is_avp_set("$avp(myheader)")) {
> xlog("L_ERR", "[$ci][$rm]: Got Identity Header: $(hdr(myheader))");
> setflag(100);
> route(invite);
> }
> }
>
> # Response 302 from REDIRECT will come in here.
> onreply_route[reply_from_REDIRECT]
> {
> xlog("L_ERR", "[$ci][$rm]: I'm in onreply_route[reply_from_REDIRECT]");
> if (t_was_cancelled()) {
> exit;
> }
>
> # detect redirect, store the header and send to "invite" as normally
> if (t_check_status("302") && is_present_hf("myheader")) {
> $avp(identity_header) = $(hdr(myheader));
> setflag(100);
> drop();
> }
> }
>
> So I suppose i don't need the drop()?
>
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
>
>
> On Wed, Jun 2, 2021 at 4:32 PM Jeff Pyle  wrote:
>
>> If I arm both t_on_failure() and t_on_reply(), do a t_relay(), and a 302
>> comes back, I have access to the reply in the onreply_route, then the
>> failure_route.  From a SIP perspective, a 302 is a failure since it's not
>> 2xx-series, no?  I don't do a drop() in the onreply_route.  It just
>> naturally follows its course to the failure_route.
>>
>> David, in your case, since you're trying to drop any 302 that doesn't
>> have an Identity header, I'd check for its presence in the onreply_route
>> and set a flag if there accordingly.  And, capture its value in an AVP if
>> you need.  Next, in the failure_route, if (t_check_status("302") &&
>> !isflagset("302_HAS_ID_HEADER")) drop; or something similar.  You could
>> easily expand that block to route-advance to your next carrier,
>> send_reply(499, "Something Else"), or whatever you makes sense for your
>> application.
>>
>>
>> - Jeff
>>
>> On Wed, Jun 2, 2021 at 10:19 AM Johan De Clercq  wrote:
>>
>>> that's because 302 is not an error.
>>> So I guess that drop() is the only way.
>>>
>>> Op wo 2 jun. 2021 om 15:42 schreef David Villasmil <
>>> david.villasmil.w...@gmail.com>:
>>>
>>>> Thanks Ben,
>>>>
>>>> That’s a good point. But only way I’ve found to jump over from oneply
>>>> to failure_route is by doing a drop(). If there’s another way, I’d love to
>>>> know about it!
>>>>
>>>> David
>>>>
>>>> On Wed, 2 Jun 2021 at 08:29, Ben Newlin  wrote:
>>>>
>>>>

Re: [OpenSIPS-Users] Getting header from 302

[Jeff Pyle]

If I arm both t_on_failure() and t_on_reply(), do a t_relay(), and a 302
comes back, I have access to the reply in the onreply_route, then the
failure_route.  From a SIP perspective, a 302 is a failure since it's not
2xx-series, no?  I don't do a drop() in the onreply_route.  It just
naturally follows its course to the failure_route.

David, in your case, since you're trying to drop any 302 that doesn't have
an Identity header, I'd check for its presence in the onreply_route and set
a flag if there accordingly.  And, capture its value in an AVP if you
need.  Next, in the failure_route, if (t_check_status("302") &&
!isflagset("302_HAS_ID_HEADER")) drop; or something similar.  You could
easily expand that block to route-advance to your next carrier,
send_reply(499, "Something Else"), or whatever you makes sense for your
application.


- Jeff

On Wed, Jun 2, 2021 at 10:19 AM Johan De Clercq  wrote:

> that's because 302 is not an error.
> So I guess that drop() is the only way.
>
> Op wo 2 jun. 2021 om 15:42 schreef David Villasmil <
> david.villasmil.w...@gmail.com>:
>
>> Thanks Ben,
>>
>> That’s a good point. But only way I’ve found to jump over from oneply to
>> failure_route is by doing a drop(). If there’s another way, I’d love to
>> know about it!
>>
>> David
>>
>> On Wed, 2 Jun 2021 at 08:29, Ben Newlin  wrote:
>>
>>> You still don’t need to call drop() as long as you are handling the
>>> request in failure_route. The 302 will not be sent back upstream as long as
>>> failure_route either creates a new branch request or sends back a different
>>> reply code. Only if failure_route exits without doing either of these
>>> things would the downstream 302 be sent back upstream as-is.
>>>
>>>
>>>
>>> In fact, as far as I know drop() has no functionality for responses >=
>>> 200.
>>>
>>>
>>>
>>> Ben Newlin
>>>
>>>
>>>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MS teams, reinvite after ACK

[Jeff Pyle]

Right.  Something like this:

if (list_hdr_has_option("Allow", "REFER"))
list_hdr_remove_option("Allow", "REFER");

We've used blind transfer successfully.  If I remember correctly it will
utilize re-INVITEs, possibly with Replaces.  I don't know that we've tested
attended transfer.

OpenSIPS is just a proxy (in this case), so it will pass the REFER just
fine.  You'd probably have to do a lot of cleanup of the Refer-to value to
make it usable in this case...I haven't checked.  It all depends on what
you have upstream and what it can handle.  We opted to strip REFER for
simplicity.


- Jeff


On Wed, Jun 2, 2021 at 5:38 AM Miha via Users 
wrote:

> yes. Thank you.
>
> is there any way to get also attended transfer working?
>
> Johan De Clercq je 6/2/2021 ob 11:21 AM napisal:
>
> remove Refer from your supported methods.
> Do note that attended transfer will not work in this case.
>
> wkr,
>
> Op wo 2 jun. 2021 om 10:15 schreef Miha via Users <
> users@lists.opensips.org>:
>
>> Hello
>>
>> i manage to fix this. I did not do t_relay() also seq Invites, after this
>> everything works ok.
>>
>> Just on question, regarding transfers, i see that MS Teams send REFER in
>> which trafter is defined. How do you deal with this? You do not allow REFER
>> from MS teams and hope that MS teams will send new INVITE?
>>
>>
>> thank you
>> miha
>>
>> Jeff Pyle je 6/1/2021 ob 3:26 PM napisal:
>>
>> Miha,
>>
>> First, do you need to use "mtsbc.test.com:5060" in the first
>> record_route_preset() param?  Can you use the IP address of your proxy
>> instead?  FQDNs are legal of course, but outside of MS Teams'
>> implementation, they're rarely required.  It's just another thing to go
>> wrong.  Especially while testing.
>>
>> The ACK to the 200 OK is a sequential (in-dialog) request.  It's not part
>> of the original INVITE transaction.  Your script will have a section like
>>
>> if (has_totag()) {
>> if (loose_route()) {
>> t_relay();
>> }
>> }
>>
>> for sequential requests through a loose-routing proxy.  This is very
>> oversimplified and yours will have more.  In this section, however, is
>> where you'll process the ACK because it has a to-tag (line 293) and a route
>> header (line 298) so the conditions match.
>>
>> Use xlogs or the debug tool of your choice to diagnose what's happening
>> in this section with the ACK.  In my scripts, I use global flag 0 to
>> indicate when I want logging.  So, I might have something like this:
>>
>>if (has_totag()) {
>>if (is_gflag(0)) xlog("L_NOTICE", " ...in-dialog $rm
>> request\n");
>># ...do all the things...maybe more logging like the line
>> above...
>>
>>
>> - Jeff
>>
>>
>> On Tue, Jun 1, 2021 at 4:57 AM Miha via Users 
>> wrote:
>>
>>> Hello
>>>
>>>
>>> I have an issue and I am unable to find out what is wrong. Incoming
>>> calls are working but when doing outbound call after 200OK, which is send
>>> to Teams I get back ACK and after that Teams do again initial. I guess this
>>> is not ok.
>>>
>>> I am doing this for outband calls:
>>>
>>>
>>> xlog("L_INFO", "rtp rtps record route");
>>> record_route_preset("mtsbc.test.com:5060","mtsbc.test.com
>>> :5061;transport=tls");
>>> add_rr_param(";r2=on");
>>>
>>> I am pasting here trace. Opensips is in the middle.
>>>
>>> Thank you for help!
>>>
>>> https://pastebin.com/qM0dMiCc
>>> ___
>>> 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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Getting header from 302

[Jeff Pyle]

Oh!  Understood.


- Jeff


On Tue, Jun 1, 2021 at 2:42 PM David Villasmil <
david.villasmil.w...@gmail.com> wrote:

> The thing is I _want_ to drop the 302, I don't want to do anything else
> with it.
>
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
>
>
> On Tue, Jun 1, 2021 at 6:46 PM Jeff Pyle  wrote:
>
>> In my experience you don't need drop() in the reply route.  Just store
>> the AVP and move on.  Something like this:
>>
>> onreply_route[collect_identity] {
>> if (is_present_hf("Identity")) {
>> $avp(identity) := $hdr(Identity);
>> setflag("GOT_IDENTITY");
>> }
>> }
>>
>> If you've armed both the reply and failure routes with t_on_reply() and
>> t_on_failure(), the $avp(identity) variable set here will be available in
>> the failure_route.  The GOT_IDENTITY flag, too.
>>
>>
>> - Jeff
>>
>>
>>
>> - Jeff
>>
>>
>> On Tue, Jun 1, 2021 at 11:20 AM David Villasmil <
>> david.villasmil.w...@gmail.com> wrote:
>>
>>> Yes, I see it is documented.
>>>
>>> So the reply header is only availanble on the "onreply" route, not on
>>> the "failure" route. That was my problem. I do indeed use an avp to store
>>> the header.
>>> I ended up getting the header on the "onreply" and storing it in an avp,
>>> set a flag and then drop(). I noticed the "failure" route is then executed.
>>> From there I can send the processing to the invite route and by
>>> checking the flag, adding the header from the avp.
>>>
>>> Thanks for your help!
>>>
>>> Regards,
>>>
>>> David Villasmil
>>> email: david.villasmil.w...@gmail.com
>>> phone: +34669448337
>>>
>>>
>>> On Tue, Jun 1, 2021 at 3:52 PM Ben Newlin 
>>> wrote:
>>>
>>>> It’s documented that it works this way. The message being processed in
>>>> failure_route is the original request; in reply_route it’s the reply. [1]
>>>>
>>>>
>>>>
>>>> You can use variable context to access the reply from failure_route
>>>> [2]. Another option would be to extract the header value into and AVP in
>>>> reply_route and then reference the AVP from failure_route.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> [1] - https://www.opensips.org/Documentation/Script-Routes-3-2
>>>>
>>>> [2] - https://www.opensips.org/Documentation/Script-CoreVar-3-2
>>>>
>>>>
>>>>
>>>> Ben Newlin
>>>>
>>>>
>>>>
>>>> *From: *Users  on behalf of David
>>>> Villasmil 
>>>> *Date: *Tuesday, June 1, 2021 at 10:43 AM
>>>> *To: *OpenSIPS users mailling list 
>>>> *Subject: *Re: [OpenSIPS-Users] Getting header from 302
>>>>
>>>> Yeah, my thing is when i use the failure route i can in theory grab the
>>>> response header and ignore the 302 and send to the invite route again to
>>>> actually send the call out via do_routing.
>>>>
>>>> What I'm trying to do is:
>>>>
>>>> - On receiving an invite: forward to an endpoint.
>>>>
>>>> - This endpoint will simply reply with 302 including a header.
>>>>
>>>> - I want to grab that header and continue routing normally (do_routing)
>>>>
>>>>
>>>>
>>>> I could do that with the failure route, but not so sure about the
>>>> onreply route.
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>>
>>>> David Villasmil
>>>>
>>>> email: david.villasmil.w...@gmail.com
>>>>
>>>> phone: +34669448337
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jun 1, 2021 at 2:34 PM Jeff Pyle  wrote:
>>>>
>>>> I don't think you're doing anything wrong.  I think I found the same
>>>> thing, that headers on the reply were available only in a reply route and
>>>> not in a failure route.  If you know where to look for them to populate the
>>>> AVP, I suppose it doesn't matter much.
>>>>
>>>>
>>>>
>>>> I haven't looked at the code but I suspect all the routes other than

Re: [OpenSIPS-Users] Getting header from 302

[Jeff Pyle]

In my experience you don't need drop() in the reply route.  Just store the
AVP and move on.  Something like this:

onreply_route[collect_identity] {
if (is_present_hf("Identity")) {
$avp(identity) := $hdr(Identity);
setflag("GOT_IDENTITY");
}
}

If you've armed both the reply and failure routes with t_on_reply() and
t_on_failure(), the $avp(identity) variable set here will be available in
the failure_route.  The GOT_IDENTITY flag, too.


- Jeff



- Jeff


On Tue, Jun 1, 2021 at 11:20 AM David Villasmil <
david.villasmil.w...@gmail.com> wrote:

> Yes, I see it is documented.
>
> So the reply header is only availanble on the "onreply" route, not on the
> "failure" route. That was my problem. I do indeed use an avp to store the
> header.
> I ended up getting the header on the "onreply" and storing it in an avp,
> set a flag and then drop(). I noticed the "failure" route is then executed.
> From there I can send the processing to the invite route and by  checking
> the flag, adding the header from the avp.
>
> Thanks for your help!
>
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
>
>
> On Tue, Jun 1, 2021 at 3:52 PM Ben Newlin  wrote:
>
>> It’s documented that it works this way. The message being processed in
>> failure_route is the original request; in reply_route it’s the reply. [1]
>>
>>
>>
>> You can use variable context to access the reply from failure_route [2].
>> Another option would be to extract the header value into and AVP in
>> reply_route and then reference the AVP from failure_route.
>>
>>
>>
>>
>>
>> [1] - https://www.opensips.org/Documentation/Script-Routes-3-2
>>
>> [2] - https://www.opensips.org/Documentation/Script-CoreVar-3-2
>>
>>
>>
>> Ben Newlin
>>
>>
>>
>> *From: *Users  on behalf of David
>> Villasmil 
>> *Date: *Tuesday, June 1, 2021 at 10:43 AM
>> *To: *OpenSIPS users mailling list 
>> *Subject: *Re: [OpenSIPS-Users] Getting header from 302
>>
>> Yeah, my thing is when i use the failure route i can in theory grab the
>> response header and ignore the 302 and send to the invite route again to
>> actually send the call out via do_routing.
>>
>> What I'm trying to do is:
>>
>> - On receiving an invite: forward to an endpoint.
>>
>> - This endpoint will simply reply with 302 including a header.
>>
>> - I want to grab that header and continue routing normally (do_routing)
>>
>>
>>
>> I could do that with the failure route, but not so sure about the onreply
>> route.
>>
>>
>> Regards,
>>
>>
>>
>> David Villasmil
>>
>> email: david.villasmil.w...@gmail.com
>>
>> phone: +34669448337
>>
>>
>>
>>
>>
>> On Tue, Jun 1, 2021 at 2:34 PM Jeff Pyle  wrote:
>>
>> I don't think you're doing anything wrong.  I think I found the same
>> thing, that headers on the reply were available only in a reply route and
>> not in a failure route.  If you know where to look for them to populate the
>> AVP, I suppose it doesn't matter much.
>>
>>
>>
>> I haven't looked at the code but I suspect all the routes other than an
>> onreply_route give you access to the requests headers, and onreply_route
>> gives you access to the reply headers.  Makes sense I guess.
>>
>>
>>
>>
>>
>> - Jeff
>>
>>
>>
>>
>>
>> On Tue, Jun 1, 2021 at 9:31 AM David Villasmil <
>> david.villasmil.w...@gmail.com> wrote:
>>
>> Thanks Jeff,
>>
>>
>>
>> MMM, that's strange, I was using it on failure route and the route was
>> being executed, but the data wasn't there. I put it on the onreply route
>> and that one is now executed with the data correctly there...
>>
>>
>>
>> I probably did something wrong.
>>
>>
>>
>> Thanks again Jeff!
>>
>>
>> Regards,
>>
>>
>>
>> David Villasmil
>>
>> email: david.villasmil.w...@gmail.com
>>
>> phone: +34669448337
>>
>>
>>
>>
>>
>> On Tue, Jun 1, 2021 at 12:37 PM Jeff Pyle  wrote:
>>
>> In which route are you trying to use if (is_present_hf("Identity"))?
>> Since the 302 is both a reply and a "failure", I suggest seeing if it
>> appears in either the armed onreply_route or failure_route.
>>
>>
>>
>&g

Re: [OpenSIPS-Users] Getting header from 302

[Jeff Pyle]

I don't think you're doing anything wrong.  I think I found the same thing,
that headers on the reply were available only in a reply route and not in a
failure route.  If you know where to look for them to populate the AVP, I
suppose it doesn't matter much.

I haven't looked at the code but I suspect all the routes other than an
onreply_route give you access to the requests headers, and onreply_route
gives you access to the reply headers.  Makes sense I guess.


- Jeff


On Tue, Jun 1, 2021 at 9:31 AM David Villasmil <
david.villasmil.w...@gmail.com> wrote:

> Thanks Jeff,
>
> MMM, that's strange, I was using it on failure route and the route was
> being executed, but the data wasn't there. I put it on the onreply route
> and that one is now executed with the data correctly there...
>
> I probably did something wrong.
>
> Thanks again Jeff!
>
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
>
>
> On Tue, Jun 1, 2021 at 12:37 PM Jeff Pyle  wrote:
>
>> In which route are you trying to use if (is_present_hf("Identity"))?
>> Since the 302 is both a reply and a "failure", I suggest seeing if it
>> appears in either the armed onreply_route or failure_route.
>>
>> I think From is available because it was present in the original request
>> route.
>>
>>
>> - Jeff
>>
>> On Tue, Jun 1, 2021 at 5:39 AM David Villasmil <
>> david.villasmil.w...@gmail.com> wrote:
>>
>>> Anyone has any idea about this? Appreciate your help.
>>>
>>> On Mon, 31 May 2021 at 21:11, David Villasmil <
>>> david.villasmil.w...@gmail.com> wrote:
>>>
>>>> So weird,
>>>> I can get the From header, but not "Identity"...
>>>>
>>>> Regards,
>>>>
>>>> David Villasmil
>>>> email: david.villasmil.w...@gmail.com
>>>> phone: +34669448337
>>>>
>>>>
>>>> On Mon, May 31, 2021 at 8:22 PM David Villasmil <
>>>> david.villasmil.w...@gmail.com> wrote:
>>>>
>>>>> This is really weird,
>>>>>
>>>>> if (is_present_hf("Identity"))
>>>>>
>>>>> says it is not present, but it is!
>>>>>
>>>>> Regards,
>>>>>
>>>>> David Villasmil
>>>>> email: david.villasmil.w...@gmail.com
>>>>> phone: +34669448337
>>>>>
>>>>>
>>>>> On Mon, May 31, 2021 at 7:47 PM David Villasmil <
>>>>> david.villasmil.w...@gmail.com> wrote:
>>>>>
>>>>>> Hello Guys,
>>>>>>
>>>>>> I'm getting a header on a 302 which i'm trying to get, but for some
>>>>>> reason I can't.
>>>>>>
>>>>>> This is an example 302:
>>>>>>
>>>>>> 2021/05/31 18:42:36.499157 10.231.32.237:5060 -> 10.231.57.11:6075
>>>>>> SIP/2.0 302 Redirect
>>>>>> Via: SIP/2.0/UDP 1.2.3.4:
>>>>>> 6075;branch=z9hG4bKd8e8.50036ee6.0;received=10.231.57.11
>>>>>> Via: SIP/2.0/UDP
>>>>>> 10.231.33.135;branch=z9hG4bKd8e8.fe2738f41d26b2b68328691c326a077a.0
>>>>>> v:SIP/2.0/UDP 10.231.49.211:6060
>>>>>> ;received=10.231.49.211;rport=6060;branch=z9hG4bK68SgceeareaUa
>>>>>> f:"+1888333";tag=ZBQ713X9pgD5S
>>>>>> t:>>>>> >;tag=9dd61ff61e802d8e2bef5f14621ef3c2.50cf6b6c
>>>>>> i:cf649a38-3ce2-123a-eaad-122eaa5d9655
>>>>>> CSeq:36689486 INVITE
>>>>>> Identity:
>>>>>> eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9vcHMtc3RhdGljLnMzLmFtYXpvbmF3cy5jb20vc3Rpci1zaGFrZW4vZWMyNTYtcHVibGljLnBlbSJ9.eyJhdHRlc3QiO
>>>>>>
>>>>>> BIiwiZGVzdCI6eyJ0biI6WyIxNzg2NDEwNzgzNyJdfSwiaWF0IjoxNjIyNDg2NTU2LCJvcmlnIjp7InRuIjoiKzEzMTU5ODUyNTk0In0sIm9yaWdpZCI6IjhlZGE4M2Q1LWY1MjEtNDQzZC1iNDI0LWIzNDQ3MDc4ZjYxZCJ9.cjIz9VwlS9_6qA
>>>>>>
>>>>>> 6mmDgottk41BLpQcA40HdvV_6jAPqQ1EIL3_jLWl25oHeVEWOzTMhcERp4Jn-JZ4vP_n3w;info=<
>>>>>> https://somedomain.com/stir-shaken/ec256-public.pem
>>>>>> >;alg=ES256;ppt=shaken
>>>>>> Server: kamailio (5.5.0 (x86_64/linux))
>>>>>> Content-Length: 0
>>>>>>
>>>>>> I'm trying to get the "Identity" header with:
>>>>>>
>>>>>> $avp(identity_header) = $(hdr(Identity));
>>>>>>
>>>>>> But It's coming up 
>>>>>>
>>>>>> Any ideas of what I'm doing wrong?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> David Villasmil
>>>>>> email: david.villasmil.w...@gmail.com
>>>>>> phone: +34669448337
>>>>>>
>>>>> --
>>> Regards,
>>>
>>> David Villasmil
>>> email: david.villasmil.w...@gmail.com
>>> phone: +34669448337
>>> ___
>>> 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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MS teams, reinvite after ACK

[Jeff Pyle]

Miha,

First, do you need to use "mtsbc.test.com:5060" in the first
record_route_preset() param?  Can you use the IP address of your proxy
instead?  FQDNs are legal of course, but outside of MS Teams'
implementation, they're rarely required.  It's just another thing to go
wrong.  Especially while testing.

The ACK to the 200 OK is a sequential (in-dialog) request.  It's not part
of the original INVITE transaction.  Your script will have a section like

if (has_totag()) {
if (loose_route()) {
t_relay();
}
}

for sequential requests through a loose-routing proxy.  This is very
oversimplified and yours will have more.  In this section, however, is
where you'll process the ACK because it has a to-tag (line 293) and a route
header (line 298) so the conditions match.

Use xlogs or the debug tool of your choice to diagnose what's happening in
this section with the ACK.  In my scripts, I use global flag 0 to indicate
when I want logging.  So, I might have something like this:

   if (has_totag()) {
   if (is_gflag(0)) xlog("L_NOTICE", " ...in-dialog $rm
request\n");
   # ...do all the things...maybe more logging like the line
above...


- Jeff


On Tue, Jun 1, 2021 at 4:57 AM Miha via Users 
wrote:

> Hello
>
>
> I have an issue and I am unable to find out what is wrong. Incoming calls
> are working but when doing outbound call after 200OK, which is send to
> Teams I get back ACK and after that Teams do again initial. I guess this is
> not ok.
>
> I am doing this for outband calls:
>
>
> xlog("L_INFO", "rtp rtps record route");
> record_route_preset("mtsbc.test.com:5060","mtsbc.test.com
> :5061;transport=tls");
> add_rr_param(";r2=on");
>
> I am pasting here trace. Opensips is in the middle.
>
> Thank you for help!
>
> https://pastebin.com/qM0dMiCc
> ___
> 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] Getting header from 302

[Jeff Pyle]

In which route are you trying to use if (is_present_hf("Identity"))?  Since
the 302 is both a reply and a "failure", I suggest seeing if it appears in
either the armed onreply_route or failure_route.

I think From is available because it was present in the original request
route.


- Jeff

On Tue, Jun 1, 2021 at 5:39 AM David Villasmil <
david.villasmil.w...@gmail.com> wrote:

> Anyone has any idea about this? Appreciate your help.
>
> On Mon, 31 May 2021 at 21:11, David Villasmil <
> david.villasmil.w...@gmail.com> wrote:
>
>> So weird,
>> I can get the From header, but not "Identity"...
>>
>> Regards,
>>
>> David Villasmil
>> email: david.villasmil.w...@gmail.com
>> phone: +34669448337
>>
>>
>> On Mon, May 31, 2021 at 8:22 PM David Villasmil <
>> david.villasmil.w...@gmail.com> wrote:
>>
>>> This is really weird,
>>>
>>> if (is_present_hf("Identity"))
>>>
>>> says it is not present, but it is!
>>>
>>> Regards,
>>>
>>> David Villasmil
>>> email: david.villasmil.w...@gmail.com
>>> phone: +34669448337
>>>
>>>
>>> On Mon, May 31, 2021 at 7:47 PM David Villasmil <
>>> david.villasmil.w...@gmail.com> wrote:
>>>
 Hello Guys,

 I'm getting a header on a 302 which i'm trying to get, but for some
 reason I can't.

 This is an example 302:

 2021/05/31 18:42:36.499157 10.231.32.237:5060 -> 10.231.57.11:6075
 SIP/2.0 302 Redirect
 Via: SIP/2.0/UDP 1.2.3.4:
 6075;branch=z9hG4bKd8e8.50036ee6.0;received=10.231.57.11
 Via: SIP/2.0/UDP
 10.231.33.135;branch=z9hG4bKd8e8.fe2738f41d26b2b68328691c326a077a.0
 v:SIP/2.0/UDP 10.231.49.211:6060
 ;received=10.231.49.211;rport=6060;branch=z9hG4bK68SgceeareaUa
 f:"+1888333";tag=ZBQ713X9pgD5S
 t:>>> >;tag=9dd61ff61e802d8e2bef5f14621ef3c2.50cf6b6c
 i:cf649a38-3ce2-123a-eaad-122eaa5d9655
 CSeq:36689486 INVITE
 Identity:
 eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9vcHMtc3RhdGljLnMzLmFtYXpvbmF3cy5jb20vc3Rpci1zaGFrZW4vZWMyNTYtcHVibGljLnBlbSJ9.eyJhdHRlc3QiO

 BIiwiZGVzdCI6eyJ0biI6WyIxNzg2NDEwNzgzNyJdfSwiaWF0IjoxNjIyNDg2NTU2LCJvcmlnIjp7InRuIjoiKzEzMTU5ODUyNTk0In0sIm9yaWdpZCI6IjhlZGE4M2Q1LWY1MjEtNDQzZC1iNDI0LWIzNDQ3MDc4ZjYxZCJ9.cjIz9VwlS9_6qA

 6mmDgottk41BLpQcA40HdvV_6jAPqQ1EIL3_jLWl25oHeVEWOzTMhcERp4Jn-JZ4vP_n3w;info=<
 https://somedomain.com/stir-shaken/ec256-public.pem
 >;alg=ES256;ppt=shaken
 Server: kamailio (5.5.0 (x86_64/linux))
 Content-Length: 0

 I'm trying to get the "Identity" header with:

 $avp(identity_header) = $(hdr(Identity));

 But It's coming up 

 Any ideas of what I'm doing wrong?

 Regards,

 David Villasmil
 email: david.villasmil.w...@gmail.com
 phone: +34669448337

>>> --
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
> ___
> 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] Ignore redirect?

[Jeff Pyle]

David,

You catch the 302 in the failure_route, decide if it's what you want, and
if not just send to another route block for do_routing and such?


- Jeff

On Tue, May 25, 2021 at 5:12 PM David Villasmil <
david.villasmil.w...@gmail.com> wrote:

> Hello guys,
>
> I'm receiving an INVITE which I forward to a redirect server. When this
> redirect server's response is not what i need, i need to continue
> processing the call normally, i.e.: No forward to redirect.
>
> I'm able to forward to the redirect server and get the 302 properly. But
> when the 302 is not what I need, how can I continue processing the call
> normally? i.e. using do_routing.
>
> Thanks all,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Tips for troubleshooting OpenSIPS as a Teams SBC

[Jeff Pyle]

John,

This has worked brilliantly -- the domain module took care of teaching
OpenSIPS what's local.  As far as a single versus double RR, the problem
turned out to be with a downstream SBC that couldn't resolve the domain
name properly.  Once fixed, the single RR works as expected.


Regards,
Jeff


On Tue, May 11, 2021 at 7:07 AM John Quick 
wrote:

> Jeff,
>
> Regarding the first issue you mention, have you tried:
> record_route_preset(“SBC_FQDN:5061;transport=tls”);
>
> In other words, have you tried it with a single rather than a double RR
> header?
> You would need to remove the ";r2=on" parameter of course.
>
> In theory, if the SBC_FQDN resolves to the IP address and everything
> communicating with your SBC is (a) capable of resolving the FQDN and (b)
> capable of routing to the SBC, then it should work.
>
> In my script I added " AS SBC_FQDN:5061" on the end of the tls
> listen/socket statement. I cannot remember if that was essential for it to
> work, but I leave it there on the basis that it cannot do any harm and
> might do some good.
>
> John Quick
> Smartvox Limited
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MS team issue

[Jeff Pyle]

For inbound from Teams, I use the permissions module with the following:

MariaDB [opensips_teamsproxy]> select * from address where grp=1;
++-+-+--+--+---+-+--+
| id | grp | ip  | mask | port | proto | pattern | context_info |
++-+-+--+--+---+-+--+
|  1 |   1 | 13.107.64.0 |   18 |0 | tls   | NULL| NULL |
|  2 |   1 | 52.120.0.0  |   14 |0 | tls   | NULL| NULL |
|  3 |   1 | 52.112.0.0  |   14 |0 | tls   | NULL| NULL |
++-+-+--+--+---+-+--+
3 rows in set (0.001 sec)

These are the ranges that Microsoft will send traffic from.  In the script,
I use

if (check_address(1, "$si", 0, "$socket_in(proto)")) {
setflag("FROM_MS");

to match inbound traffic to the above table, and then check for the FROM_MS
flag to make routing decisions.

For outbound to Teams, I use the drouting module with the following (using
FQDNs):

MariaDB [opensips_teamsproxy]> select gwid,type,address,probe_mode from
dr_gateways where gwid like 'ms%';
+--+--+++
| gwid | type | address| probe_mode |
+--+--+++
| ms1  |0 | sip.pstnhub.microsoft.com  |  2 |
| ms2  |0 | sip2.pstnhub.microsoft.com |  2 |
| ms3  |0 | sip3.pstnhub.microsoft.com |  2 |
+--+--+++
3 rows in set (0.001 sec)

You may need to populate the socket column or others I haven't shown here
according to your needs.  Also:

MariaDB [opensips_teamsproxy]> select * from dr_carriers where carrierid
like 'ms%';
+++-+---+--+---+---++
| id | carrierid  | gwlist  | flags | sort_alg | state | attrs |
description|
+++-+---+--+---+---++
|  2 | ms_pstnhub | ms1,ms2,ms3 | 0 | N| 0 | NULL  |
Microsoft PSTN Hub |
+++-+---+--+---+---++
1 row in set (0.001 sec)

This gateway ordering makes sense for someone in North America.  You'll
want to check sip, sip2 and sip3 to see which is closest to you and order
the gwlist accordingly.

In the script, I use the following with this 'carrier':

if (!route_to_carrier("ms_pstnhub")) {
xlog("L_NOTICE", "[teamsproxy] NOTICE: couldn't
route to 'ms_pstnhub' carrier\n");
send_reply(500, "Internal Server Error - RtC");
exit;
}

This is just one way to accomplish it.  I suspect there are many others
that work just as well based on unique needs.


- Jeff

On Tue, May 11, 2021 at 3:51 AM Miha via Users 
wrote:

> hello
>
> i tried to put this in address table:
> "*.pstnhub.microsoft.com" but it does not work.
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Tips for troubleshooting OpenSIPS as a Teams SBC

[Jeff Pyle]

John,

This is great, especially along side Alexey's blog post.  I'm having a
problem related to multi-tenant configuration.  I suspect it's the result
of something basic I've overlooked since I don't see it covered in your
article.

An ancillary issue that I have is where I must use the FQDN *and* the IP in
the added Record-Route header even though it's the same interface in both
cases, and the domain resolves to the IP of the local interface.  Something
goes awry in the call setup, I believe something with replies.  I haven't
isolated it specifically yet.  Calls do set up properly if I use something
like record_route_preset( “SBC_FQDN:5061;transport=tls”, “SBC_IP:5061;
transport=tls”); however.

The more significant issue is related to alias= definitions and customer
tenant domains.  I've been testing by with aliases defined for my carrier
tenant and a single customer tenant domain.  So far there's been a
reasonable amount of success.  The problem occurs when I send a call to
Teams on a customer domain I don't have an alias defined for, using that
domain in the Record-Route header as is required.  Sequential requests'
routing fails when OpenSIPS tries to route the call to the domain, which is
really to itself but OpenSIPS doesn't realize it's local, and
then...badness.  Am I missing a way to define a wildcard alias of sorts?  I
was hoping the dns=yes option would resolve those domains in real time and
match the defined IP, but that didn't seem to work either.

I feel like I'm missing something simple.


Regards,
Jeff


On Tue, Apr 6, 2021 at 5:44 AM John Quick  wrote:

>  Hello all,
> The article I published last week talks about common issues you might
> encounter when commissioning a Microsoft Teams SBC solution built using
> OpenSIPS.
> It is designed to be read alongside the article by Alexey Vasilyev.
>
> https://kb.smartvox.co.uk/opensips/opensips-as-ms-teams-sbc/
>
> John Quick
> Smartvox Limited
>
>
>
> ___
> 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] Dialogs with fix_nated_contact() have wrong RURI domain on sequential requests

[Jeff Pyle]

John,

Certainly.


- Jeff


On Thu, Feb 18, 2021 at 10:47 AM John Quick 
wrote:

> Jeff,
>
> Would it be okay if I included this as an interesting 'special case' to my
> recently published article?
> The article is all about fixing Contact headers - when and how to do it,
> when not to do it, etc.
>
> https://kb.smartvox.co.uk/opensips/nat-contact-and-via-fixing-in-sip-part-3/
>
> John Quick
> Smartvox Limited
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] where to catch CANCELs in script for branches canceled by tm module

[Jeff Pyle]

A week ago I asked the question where the CANCELs appear in the script when
tm sends then to cancel losing branches after a winning one presents
itself.  No takers so far.  Any thoughts?


- Jeff


On Fri, Feb 5, 2021 at 1:01 PM Jeff Pyle  wrote:

> Hello,
>
> This is on OpenSIPS 3.1.1 (abe7ab7c7).  I use t_relay() after lookup() to
> relay INVITEs to all registered contacts for an AOR.  I use
> rtpengine_offer() per-branch, and I keep track of the branches with
> rtpengine's extra_id_pv modparam and via-branches=extra.  To do this right
> I should use rtpengine_delete() on the losing/canceled branches.  I can't
> find where tm's CANCELs hits the script.  I expected them in local_route
> but I don't see them there.  I don't see the corresponding 487s in the
> failure_route, either.  What am I missing?
>
>
> - Jeff
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Dialogs with fix_nated_contact() have wrong RURI domain on sequential requests

[Jeff Pyle]

Now that I'm finished tripping over my own mistakes, and it appears to be
working well, I'll document it in case someone else has the same
application with the same cranky CPE devices.

On the initial request, I save the caller contact before any nathelper
modules change it:

$var(ct_uri) = $(ct.fields(uri){nameaddr.uri});


After the dialog is created (by topology_hiding() in my case), I stuff this
value into the dialog:

$dlg_val(caller_private_contact) = $var(ct_uri);


In my case I have multiple registered contacts per AOR, so I have this in
the branch_route:

$bavp(callee_private_contact) = $ru;


Then, in onreply_route, I stuff the dialog value with the original contact
of the willing branch:

if (t_check_status("200")) {
$dlg_val(callee_private_contact) = $bavp(callee_private_contact);
}


At this point the dialog has the original callee and caller values.

In the section that handles sequential requests (beneath
topology_hiding_match() in my case), I have basically what Răzvan suggested:

$du = $ru;
if ($DLG_dir == "upstream") {
$ru = $dlg_val(caller_private_contact);
} else {
$ru = $dlg_val(caller_private_contact);
}


And voilà, $du preserves the routing destination while $ru contains the
original contact before NAT mangling.  Excellent.


- Jeff


On Fri, Feb 5, 2021 at 2:58 PM Jeff Pyle  wrote:

> This makes sense.  I've been able to store the values, but I'm still
> experimenting with the right times to restore them.  Thanks, Răzvan.
>
>
>
> - Jeff
>
>
> On Thu, Feb 4, 2021 at 10:04 AM Răzvan Crainea 
> wrote:
>
>> Hi, Jeff!
>>
>> The only way to achieve this is to do it manually: store the contact on
>> the request/replies in a dialog variable, and *after*
>> topology_hiding_match(), set each of them:
>>
>> $du = $ru;
>> if ($DLG_dir == "downstream") {
>>  $ru = $dlg_val(caller_private_contact);
>> } else {
>>  $ru = $dlg_val(callee_private_contact);
>> }
>>
>> Hope this helps,
>>
>> Răzvan Crainea
>> OpenSIPS Core Developer
>> http://www.opensips-solutions.com
>>
>> On 1/26/21 6:36 PM, Jeff Pyle wrote:
>> > Hi Johan,
>> >
>> > There typically isn't loose_route() in my script because there
>> > is topology_hiding_match() instead.  But, I've tested without topology
>> > hiding (using loose_route for sequential requests) and there is no
>> > difference.
>> >
>> > The docs for fix_route_dialog()
>> > <
>> https://opensips.org/html/docs/modules/3.1.x/dialog.html#func_fix_route_dialog>
>>
>> > say that it "forces an in dialog SIP message to contain the ruri, route
>> > headers and dst_uri, as specified by the internal data of the dialog it
>> > belongs to."  That's not a problem here; the in-dialog request already
>> > has the same values as the internal data of the dialog it belongs to.
>> > This function looks more to prevent bad actors from doing nasty things
>> > in in-dialog requests.  In my case everyone is playing by the rules.
>> >
>> > The caller_contact and callee_contact from the "internal data of the
>> > dialog" (as viewed with the dlg_list MI command) contain the
>> > public/received IP and port rather than the internal/private IP and
>> port
>> > each UA provided.  That occurs because of the fix_nated_contact()
>> > function in the script prior to dialog creation.  In other words, by
>> the
>> > time the dialog is created, the internal IP:port is lost.
>> >
>> > My questions are:
>> >   - how to preserve the private/internal Contact info in the dialog, and
>> >   - use it for signaling in the RURI but continue to use the
>> > received/public info for routing for in-dialog requests
>> >
>> >
>> > - Jeff
>> >
>> > On Tue, Jan 26, 2021 at 11:04 AM Johan De Clercq > > <mailto:jo...@democon.be>> wrote:
>> >
>> > did you change the loose route part to fix route dialog ?
>> >
>> > Op di 26 jan. 2021 om 16:39 schreef Jeff Pyle > > <mailto:j...@ugnd.org>>:
>> >
>> > Hello,
>> >
>> > This is on OpenSIPS nightly 3.1.1~20210125~8bab0da7b-1.
>> >
>> > I have a registrar configured with basic call routing between
>> > the registered AORs.  I use topology_hiding("D") to create the
>> > dialog on calls and normal stuff like has_totag()
>> > and topology_hiding_match() for sequential reque

Re: [OpenSIPS-Users] (no subject)

[Jeff Pyle]

Elaine,

You can use the avp_db_query()

function to run queries to a database.  This is to manually query a
database table that OpenSIPS doesn't use automatically with one of its
modules.

The blacklist module loads its data from the table when OpenSIPS starts,
and keeps the values in memory from there.  You can force it to reload the
table into memory while it's running with reload_blacklist

MI command.


- Jeff


On Thu, Feb 4, 2021 at 7:25 PM Elaine Huang  wrote:

> Hi all,
>
> I would like to make opensips load a MySQL table, make queries and behave
> differently based on returned results.
>
> I'm trying to understand how userblacklist module works, but I'm a bit
> lost. For example, I don't see how it query the 'userblacklist' table or
> the 'globalblacklist' table.
>
> Could someone point me to some resource that can help me with
> understanding the mechanism?
>
>
> ___
> 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] Dialogs with fix_nated_contact() have wrong RURI domain on sequential requests

[Jeff Pyle]

This makes sense.  I've been able to store the values, but I'm still
experimenting with the right times to restore them.  Thanks, Răzvan.



- Jeff


On Thu, Feb 4, 2021 at 10:04 AM Răzvan Crainea  wrote:

> Hi, Jeff!
>
> The only way to achieve this is to do it manually: store the contact on
> the request/replies in a dialog variable, and *after*
> topology_hiding_match(), set each of them:
>
> $du = $ru;
> if ($DLG_dir == "downstream") {
>  $ru = $dlg_val(caller_private_contact);
> } else {
>  $ru = $dlg_val(callee_private_contact);
> }
>
> Hope this helps,
>
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
>
> On 1/26/21 6:36 PM, Jeff Pyle wrote:
> > Hi Johan,
> >
> > There typically isn't loose_route() in my script because there
> > is topology_hiding_match() instead.  But, I've tested without topology
> > hiding (using loose_route for sequential requests) and there is no
> > difference.
> >
> > The docs for fix_route_dialog()
> > <
> https://opensips.org/html/docs/modules/3.1.x/dialog.html#func_fix_route_dialog>
>
> > say that it "forces an in dialog SIP message to contain the ruri, route
> > headers and dst_uri, as specified by the internal data of the dialog it
> > belongs to."  That's not a problem here; the in-dialog request already
> > has the same values as the internal data of the dialog it belongs to.
> > This function looks more to prevent bad actors from doing nasty things
> > in in-dialog requests.  In my case everyone is playing by the rules.
> >
> > The caller_contact and callee_contact from the "internal data of the
> > dialog" (as viewed with the dlg_list MI command) contain the
> > public/received IP and port rather than the internal/private IP and port
> > each UA provided.  That occurs because of the fix_nated_contact()
> > function in the script prior to dialog creation.  In other words, by the
> > time the dialog is created, the internal IP:port is lost.
> >
> > My questions are:
> >   - how to preserve the private/internal Contact info in the dialog, and
> >   - use it for signaling in the RURI but continue to use the
> > received/public info for routing for in-dialog requests
> >
> >
> > - Jeff
> >
> > On Tue, Jan 26, 2021 at 11:04 AM Johan De Clercq  > <mailto:jo...@democon.be>> wrote:
> >
> > did you change the loose route part to fix route dialog ?
> >
> > Op di 26 jan. 2021 om 16:39 schreef Jeff Pyle  > <mailto:j...@ugnd.org>>:
> >
> > Hello,
> >
> > This is on OpenSIPS nightly 3.1.1~20210125~8bab0da7b-1.
> >
> > I have a registrar configured with basic call routing between
> > the registered AORs.  I use topology_hiding("D") to create the
> > dialog on calls and normal stuff like has_totag()
> > and topology_hiding_match() for sequential request handling.
> > All this seems fine.
> >
> > This appears high in the main route and appears to do exactly
> > what it should:
> >
> >  if (has_body("application/sdp")) {
> >  if (nat_uac_test(14)) {
> >  setflag("NAT_FLAG");
> >  }
> >  } else {
> >  if (nat_uac_test(6)) {
> >  setflag("NAT_FLAG");
> >  }
> >  }
> >
> >  if (isflagset("NAT_FLAG")) {
> >  force_rport();
> >  if ($rm == "REGISTER") {
> >  fix_nated_register();
> >  } else {
> >  fix_nated_contact();
> >  }
> >  }
> >
> > And, for replies:
> >
> > onreply_route [handle_rtprelay_onreply] {
> >  # rtpengine and such, omitted for brevity
> >  if (isbflagset("NAT_BFLAG")) {
> >  fix_nated_contact();
> >  }
> >
> >  exit;
> > }
> >
> > When one client calls another, everything works
> > fine.  lookup("location") works to update $rd with the original
> > (private) Contact provided upon registration, and $du contains

[OpenSIPS-Users] where to catch CANCELs in script for branches canceled by tm module

[Jeff Pyle]

Hello,

This is on OpenSIPS 3.1.1 (abe7ab7c7).  I use t_relay() after lookup() to
relay INVITEs to all registered contacts for an AOR.  I use
rtpengine_offer() per-branch, and I keep track of the branches with
rtpengine's extra_id_pv modparam and via-branches=extra.  To do this right
I should use rtpengine_delete() on the losing/canceled branches.  I can't
find where tm's CANCELs hits the script.  I expected them in local_route
but I don't see them there.  I don't see the corresponding 487s in the
failure_route, either.  What am I missing?


- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Dialogs with fix_nated_contact() have wrong RURI domain on sequential requests

[Jeff Pyle]

Hi Johan,

There typically isn't loose_route() in my script because there
is topology_hiding_match() instead.  But, I've tested without topology
hiding (using loose_route for sequential requests) and there is no
difference.

The docs for fix_route_dialog()
<https://opensips.org/html/docs/modules/3.1.x/dialog.html#func_fix_route_dialog>
say that it "forces an in dialog SIP message to contain the ruri, route
headers and dst_uri, as specified by the internal data of the dialog it
belongs to."  That's not a problem here; the in-dialog request already has
the same values as the internal data of the dialog it belongs to.  This
function looks more to prevent bad actors from doing nasty things in
in-dialog requests.  In my case everyone is playing by the rules.

The caller_contact and callee_contact from the "internal data of the
dialog" (as viewed with the dlg_list MI command) contain the
public/received IP and port rather than the internal/private IP and port
each UA provided.  That occurs because of the fix_nated_contact() function
in the script prior to dialog creation.  In other words, by the time the
dialog is created, the internal IP:port is lost.

My questions are:
 - how to preserve the private/internal Contact info in the dialog, and
 - use it for signaling in the RURI but continue to use the received/public
info for routing for in-dialog requests


- Jeff

On Tue, Jan 26, 2021 at 11:04 AM Johan De Clercq  wrote:

> did you change the loose route part to fix route dialog ?
>
> Op di 26 jan. 2021 om 16:39 schreef Jeff Pyle :
>
>> Hello,
>>
>> This is on OpenSIPS nightly 3.1.1~20210125~8bab0da7b-1.
>>
>> I have a registrar configured with basic call routing between the
>> registered AORs.  I use topology_hiding("D") to create the dialog on calls
>> and normal stuff like has_totag() and topology_hiding_match() for
>> sequential request handling.  All this seems fine.
>>
>> This appears high in the main route and appears to do exactly what it
>> should:
>>
>> if (has_body("application/sdp")) {
>> if (nat_uac_test(14)) {
>> setflag("NAT_FLAG");
>> }
>> } else {
>> if (nat_uac_test(6)) {
>> setflag("NAT_FLAG");
>> }
>> }
>>
>> if (isflagset("NAT_FLAG")) {
>> force_rport();
>> if ($rm == "REGISTER") {
>> fix_nated_register();
>> } else {
>> fix_nated_contact();
>> }
>> }
>>
>> And, for replies:
>>
>> onreply_route [handle_rtprelay_onreply] {
>> # rtpengine and such, omitted for brevity
>> if (isbflagset("NAT_BFLAG")) {
>> fix_nated_contact();
>> }
>>
>> exit;
>> }
>>
>> When one client calls another, everything works fine.  lookup("location")
>> works to update $rd with the original (private) Contact provided upon
>> registration, and $du contains the actual received source IP:port to get to
>> the device.  Excellent.  The INVITE goes out accordingly, and all is well.
>>
>> My problem occurs with sequential requests, say, re-INVITEs from on-hold
>> events.  The dialogs themselves save the received IP:port values as the
>> caller_contact and callee_contact values (from fix_nated_contact() above),
>> so when the requests pass through the sequential handling section of the
>> script and topology_hiding_match() does its fixups, the request URI domain
>> of the relayed request has the received IP:port values of the target UA
>> rather than the private IP:port values the UA provided during the initial
>> request that established the dialog.
>>
>> I can't wrap my head around how to fix this.  The initial requests work
>> because lookup() has the intelligence to distinguish the UAC's Contact from
>> the received IP:port at REGISTER-time, but I can't see how to achieve this
>> at dialog-creation time so sequential requests have the right RURI domain.
>> Force the caller_contact and callee_contact to the private values somehow,
>> and manage the route_set to point to the appropriate received IP:port?  I'm
>> not sure how to configure that if it is the solution.
>>
>> Any direction would be appreciated!
>>
>>
>> Regards,
>> 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

[OpenSIPS-Users] Dialogs with fix_nated_contact() have wrong RURI domain on sequential requests

[Jeff Pyle]

Hello,

This is on OpenSIPS nightly 3.1.1~20210125~8bab0da7b-1.

I have a registrar configured with basic call routing between the
registered AORs.  I use topology_hiding("D") to create the dialog on calls
and normal stuff like has_totag() and topology_hiding_match() for
sequential request handling.  All this seems fine.

This appears high in the main route and appears to do exactly what it
should:

if (has_body("application/sdp")) {
if (nat_uac_test(14)) {
setflag("NAT_FLAG");
}
} else {
if (nat_uac_test(6)) {
setflag("NAT_FLAG");
}
}

if (isflagset("NAT_FLAG")) {
force_rport();
if ($rm == "REGISTER") {
fix_nated_register();
} else {
fix_nated_contact();
}
}

And, for replies:

onreply_route [handle_rtprelay_onreply] {
# rtpengine and such, omitted for brevity
if (isbflagset("NAT_BFLAG")) {
fix_nated_contact();
}

exit;
}

When one client calls another, everything works fine.  lookup("location")
works to update $rd with the original (private) Contact provided upon
registration, and $du contains the actual received source IP:port to get to
the device.  Excellent.  The INVITE goes out accordingly, and all is well.

My problem occurs with sequential requests, say, re-INVITEs from on-hold
events.  The dialogs themselves save the received IP:port values as the
caller_contact and callee_contact values (from fix_nated_contact() above),
so when the requests pass through the sequential handling section of the
script and topology_hiding_match() does its fixups, the request URI domain
of the relayed request has the received IP:port values of the target UA
rather than the private IP:port values the UA provided during the initial
request that established the dialog.

I can't wrap my head around how to fix this.  The initial requests work
because lookup() has the intelligence to distinguish the UAC's Contact from
the received IP:port at REGISTER-time, but I can't see how to achieve this
at dialog-creation time so sequential requests have the right RURI domain.
Force the caller_contact and callee_contact to the private values somehow,
and manage the route_set to point to the appropriate received IP:port?  I'm
not sure how to configure that if it is the solution.

Any direction would be appreciated!


Regards,
Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Jeff Pyle]

Yes, and only when topology_hiding() is called later.  No t_newtran().

How can one see the fixed Contact in the script?  I've tried xlog with $ct,
but that always shows the original one.  I know it's being lost (or not)
only by looking at callee_contact from dlg_list.  If I can see the updated
one I can be more precise about where I'm losing it.


- Jeff




On Thu, Oct 29, 2020 at 5:45 AM Răzvan Crainea  wrote:

> Hi, Jeff!
>
> So you're claiming that the updated contact is lost even if you call
> fix_nated_contact() before topology_hiding(), but only for the second
> branch? Are you calling t_newtran() anywhere in your script?
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
>
> On 10/28/20 8:30 PM, Jeff Pyle wrote:
> > Liviu,
> >
> > It looks like the fixed/update contact is lost only when
> > topology_hiding() is involved.  Would you prefer a separate issue, or
> > shall I append the issue you referenced before?
> >
> >
> > - Jeff
> >
> >
> > On Wed, Oct 28, 2020 at 2:15 PM Jeff Pyle  > <mailto:j...@ugnd.org>> wrote:
> >
> > Hey Liviu,
> >
> > fix_nated_contact() before topology_hiding().  Got it.  As far as
> > losing the fixed contact during a serial fork, I'll do more testing
> > to localize exactly which combination of circumstances causes this
> > to surface and open a bug report.
> >
> >
> > - Jeff
> >
> >
> > On Wed, Oct 28, 2020 at 1:28 PM Liviu Chircu  > <mailto:li...@opensips.org>> wrote:
> >
> > Hi!
> >
> > On 28.10.2020 18:49, Jeff Pyle wrote:
> >> First, I lose the updated Contact from fix_nated_contact()
> >> after a serial fork.  Is this expected?
> > I would assume the `fix_nated_contact()` lump changes get backed
> > up into shared memory, then made available during the
> > failure_route. Anything else and IMHO it looks like a bug.
> > Opinions welcome.
> >>
> >> Second, I've determined that if the Contact URI is not wrapped
> >> in <>, that's when I get the "second attempt to change URI
> >> Contact" error when running fix_nated_contact() in the
> >> branch_route[]. This feels like a bug.
> >
> > This one is a known, documented issue.  Long story short: you
> > should always call fix_nated_contact() _before_
> > topology_hiding().  See this truth table for more info [1].
> >
> > [1]: https://github.com/OpenSIPS/opensips/issues/2172
> >
> > --
> > Liviu Chircu
> > www.twitter.com/liviuchircu  <http://www.twitter.com/liviuchircu>
> |www.opensips-solutions.com  <http://www.opensips-solutions.com>
> >
> > ___
> > Users mailing list
> > Users@lists.opensips.org <mailto: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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Jeff Pyle]

Liviu,

It looks like the fixed/update contact is lost only when topology_hiding()
is involved.  Would you prefer a separate issue, or shall I append the
issue you referenced before?


- Jeff


On Wed, Oct 28, 2020 at 2:15 PM Jeff Pyle  wrote:

> Hey Liviu,
>
> fix_nated_contact() before topology_hiding().  Got it.  As far as losing
> the fixed contact during a serial fork, I'll do more testing to localize
> exactly which combination of circumstances causes this to surface and open
> a bug report.
>
>
> - Jeff
>
>
> On Wed, Oct 28, 2020 at 1:28 PM Liviu Chircu  wrote:
>
>> Hi!
>>
>> On 28.10.2020 18:49, Jeff Pyle wrote:
>>
>> First, I lose the updated Contact from fix_nated_contact() after a
>> serial fork.  Is this expected?
>>
>> I would assume the `fix_nated_contact()` lump changes get backed up into
>> shared memory, then made available during the failure_route.  Anything else
>> and IMHO it looks like a bug.  Opinions welcome.
>>
>>
>> Second, I've determined that if the Contact URI is not wrapped in <>,
>> that's when I get the "second attempt to change URI Contact" error when
>> running fix_nated_contact() in the branch_route[].  This feels like a
>> bug.
>>
>> This one is a known, documented issue.  Long story short: you should
>> always call fix_nated_contact() _before_ topology_hiding().  See this truth
>> table for more info [1].
>>
>> [1]: https://github.com/OpenSIPS/opensips/issues/2172
>>
>> --
>> Liviu Chircuwww.twitter.com/liviuchircu | 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] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Jeff Pyle]

Hey Liviu,

fix_nated_contact() before topology_hiding().  Got it.  As far as losing
the fixed contact during a serial fork, I'll do more testing to localize
exactly which combination of circumstances causes this to surface and open
a bug report.


- Jeff


On Wed, Oct 28, 2020 at 1:28 PM Liviu Chircu  wrote:

> Hi!
>
> On 28.10.2020 18:49, Jeff Pyle wrote:
>
> First, I lose the updated Contact from fix_nated_contact() after a serial
> fork.  Is this expected?
>
> I would assume the `fix_nated_contact()` lump changes get backed up into
> shared memory, then made available during the failure_route.  Anything else
> and IMHO it looks like a bug.  Opinions welcome.
>
>
> Second, I've determined that if the Contact URI is not wrapped in <>,
> that's when I get the "second attempt to change URI Contact" error when
> running fix_nated_contact() in the branch_route[].  This feels like a bug.
>
> This one is a known, documented issue.  Long story short: you should
> always call fix_nated_contact() _before_ topology_hiding().  See this truth
> table for more info [1].
>
> [1]: https://github.com/OpenSIPS/opensips/issues/2172
>
> --
> Liviu Chircuwww.twitter.com/liviuchircu | 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] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Jeff Pyle]

It looks like I'm fighting two separate issues.  Here's what I know so far.

First, I lose the updated Contact from fix_nated_contact() after a serial
fork.  Is this expected?

Second, I've determined that if the Contact URI is not wrapped in <>,
that's when I get the "second attempt to change URI Contact" error when
running fix_nated_contact() in the branch_route[].  This feels like a bug.


- Jeff




- Jeff


On Tue, Oct 27, 2020 at 8:31 PM Jeff Pyle  wrote:

> Hello,
>
> This is on OpenSIPS 2.4.8.  Early in the script:
>
> if (nat_uac_test("34")) {   # 2, 32
> setflag(NAT_FLAG);
> fix_nated_contact();
> force_rport();
> }
>
> Later in the script I run topology_hiding("CD"), and then t_relay() an
> inbound initial INVITE upstream to another system that returns a 302 with
> Contacts.  I handle that in a failure_route[] by serializing the branches
> and relaying to them one at a time.  I don't have to go around this
> t_relay() -> failure_route[] loop much because the first Contact usually
> handles the request.
>
> The problem I notice is that the updated Contact from fix_nated_contact()
> early in the script is lost after I do the initial t_relay() to the
> redirector to get the 302.  To work around that, I've modified the script
> above to not fix_nated_contact() there, but do it in the branch_route[]
> relaying to the first Contact from the 302 and then only if NAT_FLAG is
> set.  That seems to be fine in most cases.
>
> I one case from one phone system where OpenSIPS complains:
>   ERROR:nathelper:fix_nated_contact_f: SCRIPT BUG - second attempt to
> change URI Contact
>
> This happens when I run fix_nated_contact() in the branch_route[] for the
> first and only time.  I can't duplicate it with my own traffic in the lab
> and it's maddening; it only happens with this one system that's not mine to
> play with.  I've captured the messaging and don't see anything different in
> the INVITEs coming into OpenSIPS, just some cosmetic stuff like one system
> includes :5060 on the From domain and one doesn't.  Nothing that should
> affect OpenSIPS' behavior in any of this.  It'll be very difficult to get a
> full OpenSIPS debug in this case because it's on a production system but
> there's got to be *something*.  Anyway...
>
> So, it appears I have some strange interaction between fix_nated_contact(),
> topology_hiding() and serial forking.  I mention topology_hiding()
> because it's the only thing I can think of in my scenario that would update
> the Contact outside of fix_nated_contact().
>
> I'm stumped.  Any thoughts?
>
>
> - Jeff
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Jeff Pyle]

Hello,

This is on OpenSIPS 2.4.8.  Early in the script:

if (nat_uac_test("34")) {   # 2, 32
setflag(NAT_FLAG);
fix_nated_contact();
force_rport();
}

Later in the script I run topology_hiding("CD"), and then t_relay() an
inbound initial INVITE upstream to another system that returns a 302 with
Contacts.  I handle that in a failure_route[] by serializing the branches
and relaying to them one at a time.  I don't have to go around this
t_relay() -> failure_route[] loop much because the first Contact usually
handles the request.

The problem I notice is that the updated Contact from fix_nated_contact()
early in the script is lost after I do the initial t_relay() to the
redirector to get the 302.  To work around that, I've modified the script
above to not fix_nated_contact() there, but do it in the branch_route[]
relaying to the first Contact from the 302 and then only if NAT_FLAG is
set.  That seems to be fine in most cases.

I one case from one phone system where OpenSIPS complains:
  ERROR:nathelper:fix_nated_contact_f: SCRIPT BUG - second attempt to
change URI Contact

This happens when I run fix_nated_contact() in the branch_route[] for the
first and only time.  I can't duplicate it with my own traffic in the lab
and it's maddening; it only happens with this one system that's not mine to
play with.  I've captured the messaging and don't see anything different in
the INVITEs coming into OpenSIPS, just some cosmetic stuff like one system
includes :5060 on the From domain and one doesn't.  Nothing that should
affect OpenSIPS' behavior in any of this.  It'll be very difficult to get a
full OpenSIPS debug in this case because it's on a production system but
there's got to be *something*.  Anyway...

So, it appears I have some strange interaction between fix_nated_contact(),
topology_hiding() and serial forking.  I mention topology_hiding() because
it's the only thing I can think of in my scenario that would update the
Contact outside of fix_nated_contact().

I'm stumped.  Any thoughts?


- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] can't get is_contact_registered() to return true

[Jeff Pyle]

Yes.  I want to compare everything I can between the INVITE I've just
received and the registration I authenticated previously to make sure
everything that is supposed to match does match.  I'd love to compare
User-Agent as well, for example, but it doesn't appear there's a way to
access that on lookup().  This use case may or may not be enough to
actually code it -- I'll happily defer that decision to you and the team!

Here's some context of how I use this.  In my case, I increment a memcache
counter with a relatively short TTL upon preauth failure, and after
*x* failures
in *y* seconds, I set a distinct memcache key with a relatively long TTL
that matches the source IP.  The presence of that key is checked early in
the script to ignore traffic from blacklisted source IP addresses.

Here's to 3.2!


- Jeff


On Thu, Oct 8, 2020 at 9:47 AM Liviu Chircu  wrote:

> On 08.10.2020 16:40, Jeff Pyle wrote:
> >
> > This loads the registered contacts as branches, which allows me to
> > iterate through each and compare 1) the base URI from the inbound
> > INVITE with the base URI of the registered contact, 2) the received IP
> > and 3) the received port.  Assuming one matches, that's enough to
> > satisfy me that we've received a message from a registered endpoint.
> > I'm calling this route on initial INVITEs and so far, so good.  There
> > are optimizations that could occur, such as exiting the while loop
> > once we've found a match, but at least this works.
>
> Interesting use case!  Maybe we can formalize this into one or more
> extensions, so you can just call the appropriate functions.  Here are
> your current problems which must be addressed:
>
> * is_ip_registered() is too imprecise, as it only takes the IP as input,
> while you'd want to match the URI and port as well.
> * is_contact_registered() is too precise, as it matches _everything_,
> including URI parameters which you'd like to skip.
>
> I've put this problem on the bucket list for 3.2 :)  Cheers!
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | 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] can't get is_contact_registered() to return true

[Jeff Pyle]

Here's what I have working so far, based on the remove_branch() example
<https://www.opensips.org/Documentation/Script-CoreFunctions-3-1#toc29>
from the documentation.

route {
*...things...*
# Preserve this before fix_nated_contact() breaks it
$var(ct_uri) = $(ct.fields(uri){nameaddr.uri});
*...other things...*
}

route[preauth] {
if (is_gflag(0)) xlog("L_NOTICE", "[C5] Entering preauth route $fU
-> $rU\n");

if (!lookup("location", "B", $fu)) {
if (is_gflag(0)) xlog("L_NOTICE", "[C5] ...lookup failed,
returning -1\n");
return(-1);
}

resetflag("PREAUTH_OK");
$var(i) = 0;
while ($(branch(uri)[$var(i)]) != null) {
if ($var(ct_uri) == $(branch(uri)[$var(i)]{nameaddr.uri})
&&
$si == $(branch(duri)[$var(i)]{uri.host}) &&
$sp == $(branch(duri)[$var(i)]{uri.port})) {
if (is_gflag(0)) xlog("L_NOTICE", "[C5] ...found
match $(branch(uri)[$var(i)]) ($(branch(duri)[$var(i)])) \n");
setflag("PREAUTH_OK");
}
$var(i) = $var(i) + 1;
}

$var(i) = 0;
while ($(branch(uri)[$var(i)]) != null) {
remove_branch($var(i));
}

if (isflagset("PREAUTH_OK")) {
return(1);
} else {
return(-1);
}
}

This loads the registered contacts as branches, which allows me to iterate
through each and compare 1) the base URI from the inbound INVITE with the
base URI of the registered contact, 2) the received IP and 3) the received
port.  Assuming one matches, that's enough to satisfy me that we've
received a message from a registered endpoint.  I'm calling this route on
initial INVITEs and so far, so good.  There are optimizations that could
occur, such as exiting the while loop once we've found a match, but at
least this works.


- Jeff



On Thu, Oct 8, 2020 at 3:58 AM Liviu Chircu  wrote:

> On 08.10.2020 00:42, Jeff Pyle wrote:
>
> The registered contact of a user is
> "sip:+12162454107@192.168.201.123:4135;rinstance=946433DE"
> .  When I place
> a call from that user, its INVITE's Contact is "
> sip:+12162454107@192.168.201.123:4135".  is_contact_registered() fails.
> Is that caused by the lack of the rinstance param, or something else?
>
> Indeed, the matching now fails strictly because of that extra chunk:
> ";rinstance=946433DE".  According to the RFC 3261 URI matching rules,
> they are indeed different contacts.
>
> However, if you really want to go the extra mile and tolerate those
> inconsistent INVITE Contacts (with the missing URI params) by somehow still
> matching them against Contact URIs with the params, I don't see a clean
> solution *)
>
> *) of course, you could use the local cache and store a
> "non-param-Contact: full-Contact" key-value pair on each REGISTER.  During
> INVITE processing, you would use the cache to look up and "fix" any
> non-param-Contact with its proper value, buffered in the local cache.
> However, it's still a hacky solution: what if you restart the registrar?
> Then, for a while, some INVITEs won't route out because the Contact
> conversion won't work until they re-register and populate the cache.
>
> --
> Liviu Chircuwww.twitter.com/liviuchircu | 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] can't get is_contact_registered() to return true

[Jeff Pyle]

Interesting!  I'm now storing $ct.fields(uri) before fix_nated_contact()
and it's working better, but it's revealed a new problem.

The registered contact of a user is
"sip:+12162454107@192.168.201.123:4135;rinstance=946433DE".
When I place a call from that user, its INVITE's Contact is "
sip:+12162454107@192.168.201.123:4135".  is_contact_registered() fails.  Is
that caused by the lack of the rinstance param, or something else?


- Jeff


On Wed, Oct 7, 2020 at 3:11 PM Liviu Chircu  wrote:

> On 07.10.2020 21:15, Jeff Pyle wrote:
>
> At call time:
>
>   $ct = 
>   $ct.fields(uri) = sip:+1216245@[PUBLIC_IP]:8490
>
> Am I expecting the wrong thing?
>
> Absolutely not.  You actually discovered an interesting, wacky effect of
> fix_nated_contact(), which does an in-place replacement of the private
> Contact with the public IP that has sourced the INVITE.  However, the
> original header pointers and data still stay unchanged (!!), hence why each
> variable now returns different pieces of data...
>
> To mitigate this effect, just make a backup of that $ct.fields(uri) value
> earlier in the INVITE processing, before calling fix_nated_contact().
>
>
> The only difference between $ct and the registered Contact is that $ct is
> wrapped in <>.  I wrote a nasty regex to strip the <> characters and it
> works with is_contact_registered(), at least from this phone.
>
> Probably $(ct{nameaddr.uri}) would have gotten the job done as well,
> however I'm not so sure it's equipped to ignore Contact header field
> parameters -- which makes the regexp-based approach more solid.
>
> --
> Liviu Chircuwww.twitter.com/liviuchircu | 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] can't get is_contact_registered() to return true

[Jeff Pyle]

Hi Liviu,

New problem.  $ct.fields(uri) returns the received address in the domain,
rather than what's in the Contact.

At call time:

  $ct = 
  $ct.fields(uri) = sip:+1216245@[PUBLIC_IP]:8490

Am I expecting the wrong thing?

The only difference between $ct and the registered Contact is that $ct is
wrapped in <>.  I wrote a nasty regex to strip the <> characters and it
works with is_contact_registered(), at least from this phone.


- Jeff


On Wed, Oct 7, 2020 at 10:38 AM Liviu Chircu  wrote:

> On 07.10.2020 17:18, Jeff Pyle wrote:
> > Am I missing something?
>
> Hi,
>
> Use "$ct.fields(uri)" instead of "$ct", so you extract the Contact URI
> instead of the entire header body.
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] can't get is_contact_registered() to return true

[Jeff Pyle]

Hello,

This is on OpenSIPS 3.1.0 git revision 499831928.

I'm attempting to verify an inbound message is coming from a registered
source.  is_registered("location") returns
true.  is_ip_registered("location", , $si) also returns
true.  is_contact_registered("location"), however, does not.  I've played
with various parameters and can't get it to do so.

The From of the inbound message matches the AOR I'm attempting to check.
That AOR has three registered contacts, and one of those contacts matches
the Contact arriving on the inbound message.  I expect the function to
return true in this case.  Am I missing something?


- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] learning the realm from authentication challenges

[Jeff Pyle]

I am not route-advancing in a typical way, so my application of credentials
is a bit different perhaps.

The environment I'm in has a variety of customer-facing platforms, over a
dozen at last count.  Some are for trunking, some hosted, some hybrid.  The
platform I'm writing on OpenSIPS is a testing one that will allow us to
send and receive test calls to and from all of them.  So, rather than
having a bunch of registrations on every test phone for every person who
might want to test, this allows each person to have one appearance to this
platform and select which upstream platform they want to send a call to via
dialed prefixes.

I use the uac_registrant module, and its registrant table, to handle the
platforms that require registrations and it works excellently.  At call
time, I'm working on the scripting right now that will query the registrant
table for the appropriate credentials based on where we've sent the call
and apply them in the failure_route upon receiving a 401 or 407.

Think of it this way:  when you configure a gateway in FreeSWITCH or a SIP
peer in Asterisk's chan_sip, do you need to define the realm ahead of
time?  No, you don't care; it's just a mechanism under the hood that's
necessary to complete the transaction.  That's where I'm at in OpenSIPS.
With Johan's parsing it looks like I'm about there, too.  Friggin' regex
gets me every time.


- Jeff

On Fri, Sep 25, 2020 at 10:25 AM Ben Newlin  wrote:

> I think you do need to have credentials associated with the different
> routes you have and load those properly. From your description, however, I
> don’t understand why it is dependent on identifying the realm in the
> response. If multiple downstream servers are all using the same realm (but
> have different credentials?) then how are you differentiating based on the
> realm value?
>
>
>
> The idea with uac_auth is that when you send, for example, to server
> broadworks1 you would load all the possible valid credentials for
> broadworks1, including the realm it will challenge with. When you then call
> uac_auth() from failure route, it will look through all the loaded
> credentials for one with a matching realm to the broadworks1 challenge and
> use that. If the call fails for any reason to broadworks1 and then you
> decide to route to server asterisk1, you would load all the possible
> credentials for that server into the auth AVPs the same way and failure
> route handling is the same.
>
>
>
> You could very well have a use case for verifying the realm in
> failure_route; I’m not saying you don’t. I don’t see it from what you’ve
> described, but I may be missing something. I think the reason there is no
> variable for pulling the challenge realm value directly is because normally
> with this mechanism it shouldn’t be needed.
>
>
>
> I would appreciate if someone could confirm that uac_auth() will match the
> realm as I’m asserting. I’m 95% sure this is how it worked in my testing,
> but that was a while ago and as I said the realm matching doesn’t appear to
> be documented. I’d hate to be steering you down a wrong path.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users 
> *Date: *Friday, September 25, 2020 at 10:15 AM
> *To: *OpenSIPS users mailling list 
> *Subject: *Re: [OpenSIPS-Users] learning the realm from authentication
> challenges
>
> Johan,
>
>   I will definitely try that.  Thank you!
>
>
>
> Ben,
>
>   The problem is I have multiple destinations with the same realm.  In my
> case, several different Broadworks app servers.  I haven't checked them
> exhaustively but I think they all reply with realm="BroadWorks" in their
> authentication headers.  I've got some Asterisk boxes in here, and I think
> they're all the domain of the SIP request URI in the case of an INVITE.  I
> think I'll have to choose ahead of time which credentials go with which
> route, no?  Unless I'm still not wrapping my head around how this is
> supposed to work.
>
>
>
>
>
> - Jeff
>
>
>
>
>
>
>
>
>
> On Fri, Sep 25, 2020 at 9:22 AM Ben Newlin  wrote:
>
> Jeff,
>
>
>
> My point was that the uac_auth() is supposed to handle the realm matching
> for you. If you simply load all of the auth data based on the call target
> as you already plan to do, uac_auth() should look through that data for you
> to find credentials with a matching realm. You don’t need to do that part
> yourself in the script.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users 
> *Date: *Thursday, September 24, 2020 at 11:14 PM
> *To: *OpenSIPS users mailling list 
> *Subject: *Re: [OpenSIPS-Users] learning the realm from authentication
> challenges
>
> Good catch on Proxy-Authorization vs Proxy-Authenticate.  I think I've
> been looking at this too long.  I checked the module and that's exactly
> what it is.
>
>
>
> My hope was to load the uac_auth user/pass AVPs ahead of time from a DB
> based on where I knew I was sending the call, load the realm one in the
> failure route based on what comes back in the header, and then fire the
> uac_auth() function.  I

Re: [OpenSIPS-Users] learning the realm from authentication challenges

[Jeff Pyle]

Johan,
  I will definitely try that.  Thank you!

Ben,
  The problem is I have multiple destinations with the same realm.  In my
case, several different Broadworks app servers.  I haven't checked them
exhaustively but I think they all reply with realm="BroadWorks" in their
authentication headers.  I've got some Asterisk boxes in here, and I think
they're all the domain of the SIP request URI in the case of an INVITE.  I
think I'll have to choose ahead of time which credentials go with which
route, no?  Unless I'm still not wrapping my head around how this is
supposed to work.


- Jeff




On Fri, Sep 25, 2020 at 9:22 AM Ben Newlin  wrote:

> Jeff,
>
>
>
> My point was that the uac_auth() is supposed to handle the realm matching
> for you. If you simply load all of the auth data based on the call target
> as you already plan to do, uac_auth() should look through that data for you
> to find credentials with a matching realm. You don’t need to do that part
> yourself in the script.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users 
> *Date: *Thursday, September 24, 2020 at 11:14 PM
> *To: *OpenSIPS users mailling list 
> *Subject: *Re: [OpenSIPS-Users] learning the realm from authentication
> challenges
>
> Good catch on Proxy-Authorization vs Proxy-Authenticate.  I think I've
> been looking at this too long.  I checked the module and that's exactly
> what it is.
>
>
>
> My hope was to load the uac_auth user/pass AVPs ahead of time from a DB
> based on where I knew I was sending the call, load the realm one in the
> failure route based on what comes back in the header, and then fire the
> uac_auth() function.  It looks like I may have to manually extract the
> realm from whichever header comes in.  Not ideal, but probably workable.
>
>
>
>
>
> - Jeff
>
>
>
>
>
> On Thu, Sep 24, 2020 at 9:58 PM Ben Newlin  wrote:
>
> This does not appear to be documented, but I believe uac_auth() looks
> through the AVPs configured in the UAC_AUTH module and uses the first one
> whose realm matches the challenge realm. So in order to authenticate any
> challenge, you must load all of the possible credentials into those AVPs.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users 
> *Date: *Thursday, September 24, 2020 at 9:53 PM
> *To: *OpenSIPS users mailling list 
> *Subject: *Re: [OpenSIPS-Users] learning the realm from authentication
> challenges
>
> According to the docs, $ar provides the realm from the “Authorization” or
> “Proxy-Authorization” headers. Not from the ”Proxy-Authenticate” header,
> which is what you have.
>
>
>
> https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc6
>
>
>
> Ben Newlin
>
>
>
> *From: *Users 
> *Date: *Thursday, September 24, 2020 at 9:31 PM
> *To: *OpenSIPS users mailling list 
> *Subject: *[OpenSIPS-Users] learning the realm from authentication
> challenges
>
> I'm trying to recover the realm of an auth challenge to OpenSIPS so I can
> respond to it with the uac_auth() function, and that requires knowing the
> realm.  The docs say that $ar
>  should
> provide that, perhaps written like $(ar) to get it in the right
> context.  I'm having some trouble getting the data.
>
> failure_route[relay_failure] {
> ...
>
> if (t_check_status("407")) {
> xlog("L_NOTICE", "[1] Proxy-Authenticate:
> $(hdr(Proxy-Authenticate))\n");
> xlog("L_NOTICE", "[2] Auth Realm: $(ar)\n");
>
> xlog("L_NOTICE", "[3] Auth Realm: $ar\n");
> }
>
> ...
>
> }
>
>
>
> The logs show:
>
> /usr/sbin/opensips[33044]: [1] Proxy-Authenticate: Digest
> realm="asterisk", nonce="5f6d4214936ad820dbcd452e6bcd145777e458dd46dd",
> qop="auth"
> /usr/sbin/opensips[33044]: [2] Auth Realm reply: 
> /usr/sbin/opensips[33044]: [3] Auth Realm: 
>
>
>
> Is it possible to get the realm?  Is it possible to build a response with
> uac_auth() for an arbitrary authentication challenge?
>
>
>
> This is on 3.1.0~20200923~88f89e941.
>
>
>
>
>
>
>
> - 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] learning the realm from authentication challenges

[Jeff Pyle]

Good catch on Proxy-Authorization vs Proxy-Authenticate.  I think I've been
looking at this too long.  I checked the module and that's exactly what it
is.

My hope was to load the uac_auth user/pass AVPs ahead of time from a DB
based on where I knew I was sending the call, load the realm one in the
failure route based on what comes back in the header, and then fire the
uac_auth() function.  It looks like I may have to manually extract the
realm from whichever header comes in.  Not ideal, but probably workable.


- Jeff


On Thu, Sep 24, 2020 at 9:58 PM Ben Newlin  wrote:

> This does not appear to be documented, but I believe uac_auth() looks
> through the AVPs configured in the UAC_AUTH module and uses the first one
> whose realm matches the challenge realm. So in order to authenticate any
> challenge, you must load all of the possible credentials into those AVPs.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users 
> *Date: *Thursday, September 24, 2020 at 9:53 PM
> *To: *OpenSIPS users mailling list 
> *Subject: *Re: [OpenSIPS-Users] learning the realm from authentication
> challenges
>
> According to the docs, $ar provides the realm from the “Authorization” or
> “Proxy-Authorization” headers. Not from the ”Proxy-Authenticate” header,
> which is what you have.
>
>
>
> https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc6
>
>
>
> Ben Newlin
>
>
>
> *From: *Users 
> *Date: *Thursday, September 24, 2020 at 9:31 PM
> *To: *OpenSIPS users mailling list 
> *Subject: *[OpenSIPS-Users] learning the realm from authentication
> challenges
>
> I'm trying to recover the realm of an auth challenge to OpenSIPS so I can
> respond to it with the uac_auth() function, and that requires knowing the
> realm.  The docs say that $ar
>  should
> provide that, perhaps written like $(ar) to get it in the right
> context.  I'm having some trouble getting the data.
>
> failure_route[relay_failure] {
> ...
>
> if (t_check_status("407")) {
> xlog("L_NOTICE", "[1] Proxy-Authenticate:
> $(hdr(Proxy-Authenticate))\n");
> xlog("L_NOTICE", "[2] Auth Realm: $(ar)\n");
>
> xlog("L_NOTICE", "[3] Auth Realm: $ar\n");
> }
>
> ...
>
> }
>
>
>
> The logs show:
>
> /usr/sbin/opensips[33044]: [1] Proxy-Authenticate: Digest
> realm="asterisk", nonce="5f6d4214936ad820dbcd452e6bcd145777e458dd46dd",
> qop="auth"
> /usr/sbin/opensips[33044]: [2] Auth Realm reply: 
> /usr/sbin/opensips[33044]: [3] Auth Realm: 
>
>
>
> Is it possible to get the realm?  Is it possible to build a response with
> uac_auth() for an arbitrary authentication challenge?
>
>
>
> This is on 3.1.0~20200923~88f89e941.
>
>
>
>
>
>
>
> - 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

[OpenSIPS-Users] learning the realm from authentication challenges

[Jeff Pyle]

I'm trying to recover the realm of an auth challenge to OpenSIPS so I can
respond to it with the uac_auth() function, and that requires knowing the
realm.  The docs say that $ar
 should
provide that, perhaps written like $(ar) to get it in the right
context.  I'm having some trouble getting the data.

failure_route[relay_failure] {
...
if (t_check_status("407")) {
xlog("L_NOTICE", "[1] Proxy-Authenticate:
$(hdr(Proxy-Authenticate))\n");
xlog("L_NOTICE", "[2] Auth Realm: $(ar)\n");
xlog("L_NOTICE", "[3] Auth Realm: $ar\n");
}
...
}

The logs show:

/usr/sbin/opensips[33044]: [1] Proxy-Authenticate: Digest realm="asterisk",
nonce="5f6d4214936ad820dbcd452e6bcd145777e458dd46dd", qop="auth"
/usr/sbin/opensips[33044]: [2] Auth Realm reply: 
/usr/sbin/opensips[33044]: [3] Auth Realm: 

Is it possible to get the realm?  Is it possible to build a response with
uac_auth() for an arbitrary authentication challenge?

This is on 3.1.0~20200923~88f89e941.



- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] opensips-cli connection problems

[Jeff Pyle]

I am not using apparmor.  Not intentionally, anyway.  I see the
libapparmor1 package is installed but that's about it.

# echo FOOBAR >>/tmp/opensips-class4_fifo
bash: /tmp/opensips-class4_fifo: Permission denied

Huh.  Why would root not be able to write to a file with 0666 permissions?
That's weird to me.

Looking back now I'm not sure where I found the "url" type.  If I come
across it again, I'll let you know.  "http" is working great!


- Jeff




On Thu, Sep 24, 2020 at 10:28 AM Liviu Chircu  wrote:

> On 24.09.2020 17:15, Jeff Pyle wrote:
>
> If I try fifo, I get a permissions problem...
>
> PermissionError: [Errno 13] Permission denied: '/tmp/opensips-class4_fifo'
>
> ...even though:
>
> # ls -lh /tmp/opensips-class4_fifo
> prw-rw-rw- 1 opensips opensips 0 Sep 24 10:05 /tmp/opensips-class4_fifo
>
> I don't have a big clue on this one, unfortunately, as it should work
> given your info.  Some hints:
>
> * manually ensure the user you're running opensips-cli with can write to
> the FIFO file, even if it's gibberish.  Example:
>
> echo FOOBAR >>/tmp/opensips-class4_fifo
>
> * make sure FIFO access isn't blocked by some security layer, such as
> apparmor.  If you're using apparmor, check the logs.
>
> Cheers,
>
> --
> Liviu Chircuwww.twitter.com/liviuchircu | 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

[OpenSIPS-Users] opensips-cli connection problems

[Jeff Pyle]

Hello,

I'm having a rough time getting opensips-cli to connect to my OpenSIPS
instance.

If I try fifo, I get a permissions problem...

PermissionError: [Errno 13] Permission denied: '/tmp/opensips-class4_fifo'

...even though:

# ls -lh /tmp/opensips-class4_fifo
prw-rw-rw- 1 opensips opensips 0 Sep 24 10:05 /tmp/opensips-class4_fifo

If I try url, I get a module problem:

ERROR: cannot import 'url' handler: No module named
'opensipscli.communication.url'
ERROR: no module 'mi' loaded

I'm using this config file:

[default]
log_level: WARNING
prompt_name: opensips-cli4
prompt_intro: Welcome to OpenSIPS Command Line Interface - Class 4!
prompt_emptyline_repeat_cmd: False
history_file: ~/.opensips-cli4.history
history_file_size: 1000
output_type: pretty-print
communication_type: url *# or 'fifo', depending what I'm testing at
the moment*
fifo_file: /tmp/opensips-class4_fifo
url: http://127.0.0.1:8884/mi

OpenSIPS' mi_http and mi_fifo modules are configured with the correct URL
and 0666, respectively.  I don't think it matters to me whether I connect
URL or FIFO.  Getting one of them to work would sure be helpful!  What am I
missing?


- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Command cannot be used in the block

[Jeff Pyle]

Hello,

I'm using 3.1.0~20200919~c5ef382ac-1 from the 3.1-nightly APT repo.  I'm
porting over a config from 2.4 that works well.  The problem I'm having is
with the gflags module, specifically the is_gflag() function.  I get an
error when I try to use it in onreply_route, failure_route or branch_route:

  Command  cannot be used in the block

Is this expected?  The documentation says it's supposed to work pretty much
everywhere, and it did in 2.4.


- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] opensips-cli permissions problem on database creation

[Jeff Pyle]

No customizations to any opensips-cli.cfg anywhere.  It doesn't exist on
this system.

MariaDB [(none)]> create user `opensips`@`localhost` identified by
'opensipsrw';
Query OK, 0 rows affected (0.001 sec)

MariaDB [(none)]> grant all privileges on opensips.* to
`opensips`@`localhost`;
Query OK, 0 rows affected (0.001 sec)

MariaDB [(none)]> quit
Bye
root@opensips:~# opensips-cli -x database create
Password for admin MySQL user (root):
INFO: connected to DB, 'opensips' user is already created
INFO: Running standard-create.sql...
INFO: Running acc-create.sql...
INFO: Running alias_db-create.sql...
INFO: Running auth_db-create.sql...
INFO: Running avpops-create.sql...
INFO: Running clusterer-create.sql...
INFO: Running dialog-create.sql...
INFO: Running dialplan-create.sql...
INFO: Running dispatcher-create.sql...
INFO: Running domain-create.sql...
INFO: Running drouting-create.sql...
INFO: Running group-create.sql...
INFO: Running load_balancer-create.sql...
INFO: Running msilo-create.sql...
INFO: Running permissions-create.sql...
INFO: Running rtpproxy-create.sql...
INFO: Running rtpengine-create.sql...
INFO: Running speeddial-create.sql...
INFO: Running tls_mgm-create.sql...
INFO: Running usrloc-create.sql...

That's better.  Looks like it does just fine on Debian 10 with the
exception of the user creation.

I connected to my training VM, did a dump of the mysql table, and tried to
use the INSERT it created for the opensips@localhost user directly on my
local database.  It said the number of columns didn't match up.  So,
something has definitely changed between MariaDB 10.1.45 and 10.3.23.
Perhaps that's related to the opensips-cli failure.


- Jeff


On Thu, Sep 17, 2020 at 8:21 AM Liviu Chircu  wrote:

> On 17.09.2020 15:18, Liviu Chircu wrote:
> > By default, the CLI should create the DB without requiring any config
> > file customizations.
>
> For the sake of completeness, it should also create the
> "opensips:opensipsrw" user.
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | 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

[OpenSIPS-Users] opensips-cli permissions problem on database creation

[Jeff Pyle]

Hello,

I'm attempting to use opensips-cli to create the initial databases for
OpenSIPS 3.1 with opensips-cli 0.1~20200901~524c020-1 installed from
3.1-nightly.  The database is MariaDB 10.3.23-0+deb10u1 installed from the
'default-mysql-server' package.  The system is Debian 10 on a container
created with 'lxc-create', which installs very few packages by default.  I
wonder if I'm experiencing a problem a stock Debian 10 install might not be
because I'm missing something that's normally there.

opensips-cli creates the `opensips` database successfully, but then fails
to populate any of the tables.  I see the following exception:

root@opensips:~# opensips-cli -x database create
Password for admin MySQL user (root):
Traceback (most recent call last):
 File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line
2228, in _wrap_pool_connect
   return fn()
 File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 365, in
unique_connection
   return _ConnectionFairy._checkout(self)
 File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 822, in
_checkout
   fairy = _ConnectionRecord.checkout(pool)
 File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 554, in
checkout
   rec = pool._do_get()
 File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 1250, in
_do_get
   self._dec_overflow()
 File "/usr/lib/python3/dist-packages/sqlalchemy/util/langhelpers.py", line
67, in __exit__
   compat.reraise(exc_type, exc_value, exc_tb)
 File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 277,
in reraise
   raise value
 File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 1247, in
_do_get
   return self._create_connection()
 File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 370, in
_create_connection
   return _ConnectionRecord(self)
 File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 499, in
__init__
   self.__connect(first_connect_check=True)
 File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 701, in
__connect
   connection = pool._invoke_creator(self)
 File "/usr/lib/python3/dist-packages/sqlalchemy/engine/strategies.py",
line 114, in connect
   return dialect.connect(*cargs, **cparams)
 File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line
437, in connect
   return self.dbapi.connect(*cargs, **cparams)
 File "/usr/lib/python3/dist-packages/MySQLdb/__init__.py", line 86, in
Connect
   return Connection(*args, **kwargs)
 File "/usr/lib/python3/dist-packages/MySQLdb/connections.py", line 204, in
__init__
   super(Connection, self).__init__(*args, **kwargs2)
_mysql_exceptions.OperationalError: (1698, "Access denied for user
'opensips'@'localhost'")

There are a few more exceptions after this but I think the key is the last
line in this one.  I checked the mysql.user table and there is no
'opensips' user, so if anything, that's failing to be created and
everything dies afterwards.

The database gets created but there are no tables in it.  I can run
'opensips-cli -x database drop' and that works alright.  I've got to be
missing something simple.


- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] drouting probe_mode in active/passive cluster

[Jeff Pyle]

Hi Alexey,

I see the "dr_enable_probing" MI command; that's great!  Is there an
equivalent modparam I can add to default to 0, so that it will only probe
when we know it has the IP (when enabled by MI)?

It will be some time until I'm able to cherry-pick and test.  The two
proxies are currently running from the published APT repo and it will take
a moment to convert them to source or construct a local repo.


- Jeff

On Sat, Apr 11, 2020 at 9:29 AM Alexey Vasilyev 
wrote:

> Hi Jeff.
>
> I made one solution for 2.4. You can cherry-pick
>
> https://github.com/OpenSIPS/opensips/commit/05ca54a37d82c605e2cd6d10e5a62fb4f7c35b78
>
> And may be this:
>
> https://github.com/OpenSIPS/opensips/commit/94a3ede1e276984a91f93f6ece832d174b071ab8
>
> There is documentation in commits.
>
>
>
> -
> ---
> Alexey Vasilyev
> --
> Sent from:
> http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html
>
> ___
> 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

[OpenSIPS-Users] drouting probe_mode in active/passive cluster

[Jeff Pyle]

Hello,

On v2.4.7 I have a two-node cluster configured as active/standby with
keepalived managing which side has the IP.  I want to use drouting
probe_mode=2, but I don't see how to prevent the passive side from trying
to ping the gateways even when it doesn't have the IP.  And, of course, it
fails:

/usr/sbin/opensips[2212445]: ERROR:core:get_out_socket: connect failed:
Network is unreachable
/usr/sbin/opensips[2212445]: ERROR:core:get_out_socket: no socket found
/usr/sbin/opensips[2212445]: ERROR:tm:t_uac: no corresponding socket for af
2
/usr/sbin/opensips[2212445]: ERROR:drouting:dr_prob_handler: unable to
execute dialog, disabling destination...

If I have status_replication_cluster configured, then the passive side
effectively poisons the active side by indicating the gateway is down.

How can I tell the passive side not to send pings?



- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] drouting gateway status with route_to_gw()

[Jeff Pyle]

Hello,

On v2.4.7 I'm using route_to_gw() to load routing for a particular
gateway.  It works well.  It also works when the gateway is in an
"Inactive" status, which surprises me.  I would expect the function to
return with an error code in that scenario, or at least have the option to
achieve that behavior.

I don't see any mention in the documentation of a way to manually check the
status of a gateway from the script (only from MI).  Is there?

Perhaps the gateway status is taken into consideration only with
do_routing()?  If that's the case, I'm wondering if I can emulate
route_to_gw() with do_routing() while specifying a gw_whitelist of only the
gateway I'm interested in routing to.

I thought I'd ask the experts before I get crazy with it.


- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] ratelimit network algorithm traffic limit

[Jeff Pyle]

This contradicts the documentation, which specifically mentions a
modparam.  I'll give it a shot anyway and see how it does.


- Jeff

On Mon, Mar 2, 2020 at 1:46 PM David Villasmil <
david.villasmil.w...@gmail.com> wrote:

> There we go
>
> On Mon, 2 Mar 2020 at 18:43, Ben Newlin  wrote:
>
>> The limit is set when the pipe is created the first time you call
>> rl_check as mentioned earlier. OpenSIPS doesn’t use a modparam to create
>> the pipes; instead they are created the first time they are referenced.
>>
>>
>>
>> https://opensips.org/docs/modules/3.0.x/ratelimit.html#func_rl_check
>>
>>
>>
>> “Check the current request against the pipe identified by name and
>> changes/updates the limit. If no pipe is found, then a new one is created
>> with the specified limit and algorithm, if specified.”
>>
>>
>>
>> Ben Newlin
>>
>>
>>
>> *From: *Users  on behalf of David
>> Villasmil 
>> *Reply-To: *OpenSIPS users mailling list 
>> *Date: *Monday, March 2, 2020 at 1:40 PM
>> *To: *OpenSIPS users mailling list 
>> *Subject: *Re: [OpenSIPS-Users] ratelimit network algorithm traffic limit
>>
>>
>>
>> But that’s Kamaililio. He’s talking about openSIPS, and I can’t see that
>> same param in opensips 2.4
>>
>>
>>
>> On Mon, 2 Mar 2020 at 18:24, Ovidiu Sas  wrote:
>>
>> Take a look at the pipe parameter:
>> https://kamailio.org/docs/modules/5.4.x/modules/ratelimit.html#idp49883756
>>
>> # define pipe 4 with a limit of 1 pending bytes in the rx_queue
>> # using NETWORK algorithm
>> modparam("ratelimit", "pipe", "4:NETWORK:1")
>>
>> Hope this helps!
>>
>> Regards,
>> Ovidiu Sas
>>
>> On Mon, Mar 2, 2020 at 12:53 PM Jeff Pyle  wrote:
>> >
>> > But how does it work for the NETWORK algorithm?  The docs specifically
>> mention a modparam, but even if that's not the case anymore, what unit is
>> the limit one might specify with rl_check()?
>> >
>> > More generally, how does one implement the NETWORK algorithm?
>> >
>> >
>> > - Jeff
>> >
>> >
>> > On Mon, Mar 2, 2020 at 12:19 PM David Villasmil <
>> david.villasmil.w...@gmail.com> wrote:
>> >>
>> >> Jeff,
>> >>
>> >> Yep, you’re totally right. The limit should be set when calling the
>> check, I.e:
>> >>
>> >> if (!rl_check("$rU", "50", "TAILDROP")) {
>> >> sl_send_reply("503", "Server Unavailable");
>> >> exit;
>> >> };
>> >>
>> >>
>> >>
>> >> On Mon, 2 Mar 2020 at 16:19, Jeff Pyle  wrote:
>> >>>
>> >>> This doesn't appear to have anything to do with a any type of limit
>> or the network algorithm.  In fact, it says, "...and only affects the
>> Taildrop and RED algorithms."  ?
>> >>>
>> >>>
>> >>> - Jeff
>> >>>
>> >>>
>> >>> On Mon, Mar 2, 2020 at 11:05 AM David Villasmil <
>> david.villasmil.w...@gmail.com> wrote:
>> >>>>
>> >>>>
>> https://opensips.org/html/docs/modules/2.4.x/ratelimit.html#param_limit_per_interval
>> >>>>
>> >>>>
>> >>>> On Mon, 2 Mar 2020 at 15:54, Jeff Pyle  wrote:
>> >>>>>
>> >>>>> Hello,
>> >>>>>
>> >>>>> The ratelimit doc page (v2.4) section 1.3.4 says the following:
>> "If the returned amount exceeds the limit specified in the modparam,
>> rl_check returns an error."  The problem is I don't see a modparam to
>> define the limit.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> - Jeff
>> >>>>>
>> >>>>> ___
>> >>>>> Users mailing list
>> >>>>> Users@lists.opensips.org
>> >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >>>>
>> >>>> --
>> >>>> Regards,
>> >>>>
>> >>>> David Villasmil
>> >>>> email: david.villasmil.w...@gmail.com
>> >>>> phone: +34669448337
>> >>>>
>> >>>> __

Re: [OpenSIPS-Users] ratelimit network algorithm traffic limit

[Jeff Pyle]

But how does it work for the NETWORK algorithm?  The docs specifically
mention a modparam, but even if that's not the case anymore, what unit is
the limit one might specify with rl_check()?

More generally, how does one implement the NETWORK algorithm?


- Jeff


On Mon, Mar 2, 2020 at 12:19 PM David Villasmil <
david.villasmil.w...@gmail.com> wrote:

> Jeff,
>
> Yep, you’re totally right. The limit should be set when calling the check,
> I.e:
>
> if (!rl_check("$rU", "50", "TAILDROP")) {
>   sl_send_reply("503", "Server Unavailable");
>   exit;
>   };
>
>
>
> On Mon, 2 Mar 2020 at 16:19, Jeff Pyle  wrote:
>
>> This doesn't appear to have anything to do with a any type of limit or
>> the network algorithm.  In fact, it says, "...and only affects the Taildrop
>> and RED algorithms."  ?
>>
>>
>> - Jeff
>>
>>
>> On Mon, Mar 2, 2020 at 11:05 AM David Villasmil <
>> david.villasmil.w...@gmail.com> wrote:
>>
>>>
>>> https://opensips.org/html/docs/modules/2.4.x/ratelimit.html#param_limit_per_interval
>>>
>>>
>>> On Mon, 2 Mar 2020 at 15:54, Jeff Pyle  wrote:
>>>
>>>> Hello,
>>>>
>>>> The ratelimit doc page (v2.4) section 1.3.4 says the following:  "If
>>>> the returned amount exceeds the limit specified in the modparam, rl_check
>>>> returns an error."  The problem is I don't see a modparam to define the
>>>> limit.
>>>>
>>>>
>>>>
>>>> - Jeff
>>>>
>>>> ___
>>>> Users mailing list
>>>> Users@lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>> --
>>> Regards,
>>>
>>> David Villasmil
>>> email: david.villasmil.w...@gmail.com
>>> phone: +34669448337
>>>
>> 
>>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> --
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
> ___
> 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] ratelimit network algorithm traffic limit

[Jeff Pyle]

This doesn't appear to have anything to do with a any type of limit or the
network algorithm.  In fact, it says, "...and only affects the Taildrop and
RED algorithms."  ?


- Jeff


On Mon, Mar 2, 2020 at 11:05 AM David Villasmil <
david.villasmil.w...@gmail.com> wrote:

>
> https://opensips.org/html/docs/modules/2.4.x/ratelimit.html#param_limit_per_interval
>
>
> On Mon, 2 Mar 2020 at 15:54, Jeff Pyle  wrote:
>
>> Hello,
>>
>> The ratelimit doc page (v2.4) section 1.3.4 says the following:  "If the
>> returned amount exceeds the limit specified in the modparam, rl_check
>> returns an error."  The problem is I don't see a modparam to define the
>> limit.
>>
>>
>>
>> - Jeff
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> --
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
> 
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] ratelimit network algorithm traffic limit

[Jeff Pyle]

Hello,

The ratelimit doc page (v2.4) section 1.3.4 says the following:  "If the
returned amount exceeds the limit specified in the modparam, rl_check
returns an error."  The problem is I don't see a modparam to define the
limit.



- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] HA ongoing call support in 2.4 - transaction replication

[Jeff Pyle]

Brett,

Yes, exactly.  Most of the components I'm familiar with are supposed to
live in the same rack with direct cabling between them for this kind of
thing.  People often separate them to some degree with various levels of
success, depending mostly upon the stability of the network between them.

In this case having the option would certainly be nice, and I would happily
accept the caveats.


- Jeff



On Thu, Feb 20, 2020 at 12:31 PM Brett Nemeroff  wrote:

> Jeff, I think a lot of the problem is the active chit-chat in the updates.
> It’s a lot. I can see however your use case makes a lot of sense and for a
> redundant pair sitting next to each other, I think it *could* make sense,
> if it is fast enough.
>
> I’m curious if Razvan would consider making it an option that can be
> turned on with the understanding that it doesn’t work well across DC
> boundaries because of the timing and need to happen quickly for
> synchronization. There are plenty of infrastructure components with this
> guideline for similar reasons.
>
>
>
> On Thu, Feb 20, 2020 at 10:48 AM Jeff Pyle  wrote:
>
>> Alexei,
>>
>> I see the article.  In summary, transactions are too complicated to
>> synchronize between nodes of a cluster because of their short timing
>> intervals and complex structures.  Instead the approach is to get the
>> messages of a transaction back to the individual node that owns the
>> transaction so it can process there.  Got it.
>>
>> For a cluster with many anycast nodes, this makes a lot of sense.  For a
>> simple active/standby setup, it prevents one from achieving a hitless
>> failover from one node to another if there are active transactions.
>> Bummer.  I'm sure Razvan and the team understood this when deciding on this
>> architecture.  Big picture their approach solves a lot more problems than
>> it creates, and it's very cool nonetheless.
>>
>>
>> - Jeff
>>
>>
>> On Thu, Feb 20, 2020 at 1:56 AM Alexey Vasilyev <
>> alexei.vasil...@gmail.com> wrote:
>>
>>> Hi Jeff,
>>>
>>> Transactions are not replicated.
>>> Here
>>>
>>> https://blog.opensips.org/2018/03/21/full-anycast-support-in-opensips-2-4/
>>> Razvan explains why. Section "Distributed transactions handling".
>>>
>>>
>>>
>>> -
>>> ---
>>> Alexey Vasilyev
>>> --
>>> Sent from:
>>> http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html
>>>
>>>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] HA ongoing call support in 2.4 - transaction replication

[Jeff Pyle]

Alexei,

I see the article.  In summary, transactions are too complicated to
synchronize between nodes of a cluster because of their short timing
intervals and complex structures.  Instead the approach is to get the
messages of a transaction back to the individual node that owns the
transaction so it can process there.  Got it.

For a cluster with many anycast nodes, this makes a lot of sense.  For a
simple active/standby setup, it prevents one from achieving a hitless
failover from one node to another if there are active transactions.
Bummer.  I'm sure Razvan and the team understood this when deciding on this
architecture.  Big picture their approach solves a lot more problems than
it creates, and it's very cool nonetheless.


- Jeff


On Thu, Feb 20, 2020 at 1:56 AM Alexey Vasilyev 
wrote:

> Hi Jeff,
>
> Transactions are not replicated.
> Here
> https://blog.opensips.org/2018/03/21/full-anycast-support-in-opensips-2-4/
> Razvan explains why. Section "Distributed transactions handling".
>
>
>
> -
> ---
> Alexey Vasilyev
> --
> Sent from:
> http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] HA ongoing call support in 2.4 - transaction replication

[Jeff Pyle]

Hello,

I'm attempting to implement an active/backup pair of OpenSIPS v2.4
proxies.  I'm using keepalived to move the IP between the two instances,
and clusterer module to allow the two proxies to talk to each other.  The
dialog module is replicating its information, and keepalived successfully
sets the "vip" shared dialog tag to active on the active proxy when it goes
live.  I can start a call on one proxy, failover to the other one, and
finish it.  Good.

I cannot, however, perform a failover mid-transaction and complete the
transaction on the newly active proxy.  It does not appear the proxies are
replicating transaction information as they do dialog information.

I do have:
  modparam("tm", "tm_replication_cluster", 1)

I've been following the information on the Clustering Ongoing Calls

page as well as the tm module's page Anycast Scenario

description.  The description concerns me some because I'm not running an
anycast implementation but rather active/backup.

Is what I'm attempting possible?  Is it possible to have the backup proxy
knowing all the active proxy's transactions, as it does the dialogs, so it
can take over at any moment with no disruption of ongoing transactions ?



- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] rtpengine + manual SDP manipulations

[Jeff Pyle]

Oops... I answered early.  You had more replies.

I've tried it everywhere.  Before, after, branch route, script route, etc.
The only combination I haven't tried is moving the rtpengine_offer call to
a script route from the branch route it's in now, and then doing my custom
replacements in the branch route.  That won't work for my case because I
need the rtpengine stuff in the branch unfortunately.


- Jeff


On Sat, Jan 18, 2020 at 11:17 AM David Villasmil <
david.villasmil.w...@gmail.com> wrote:

> Though reading through it, it may not be what your're looking for.
> I think the SDP gets replaced when you call the rtpengine manage command.
> Have you tried doing the replace _after_ calling the manage command?
>
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
>
>
> On Sat, Jan 18, 2020 at 4:15 PM David Villasmil <
> david.villasmil.w...@gmail.com> wrote:
>
>> with:
>>
>>
>> https://www.kamailio.org/docs/modules/stable/modules/rtpengine.html#rtpengine.f.rtpengine_offer
>>
>> 5.2.  rtpengine_offer([flags])
>> *replace-origin* - flags that IP from the origin description (o=) should
>> be also changed.
>>
>>
>>
>> Regards,
>>
>> David Villasmil
>> email: david.villasmil.w...@gmail.com
>> phone: +34669448337
>>
>>
>> On Sat, Jan 18, 2020 at 4:11 PM David Villasmil <
>> david.villasmil.w...@gmail.com> wrote:
>>
>>> I believe you can use this:
>>>
>>> replace
>>>
>>> Similar to the flags list. Controls which parts of the SDP body should
>>> be rewritten. Contains zero or more of:
>>>
>>>-
>>>
>>>origin
>>>
>>>Replace the address found in the *origin* (o=) line of the SDP body.
>>>Corresponds to *rtpproxy* o flag.
>>>-
>>>
>>>session connection or session-connection
>>>
>>>Replace the address found in the *session-level connection* (c=)
>>>line of the SDP body. Corresponds to *rtpproxy* c flag.
>>>
>>>
>>> Have you tried this?
>>>
>>> Regards,
>>>
>>> David Villasmil
>>> email: david.villasmil.w...@gmail.com
>>> phone: +34669448337
>>>
>>>
>>> On Sat, Jan 18, 2020 at 3:59 PM Jeff Pyle  wrote:
>>>
>>>> Hello,
>>>>
>>>> I'm running OpenSIPS 2.4 and rtpengine 7.0.  I have the following
>>>> commands in my script:
>>>>
>>>> route[sanitize_sdp] {
>>>> subst_body('/^o=\S+ /o=- /');
>>>> subst_body('/^s=.*/s=-\r/');
>>>> }
>>>>
>>>> This works fine, unless I'm also using rtpengine, in which case these
>>>> subst_body() changes are lost.  In the past with rtpproxy this worked as
>>>> expected.
>>>>
>>>> I understand the potential conflicts when manipulating the SDP using
>>>> multiple methods at the same time.  My question is if there is a way to
>>>> execute this type of manual manipulation in a way that's compatible with
>>>> rtpengine, or achieve similar results within the rtpengine module itself?
>>>> My purpose is to remove the origin and session text if possible to further
>>>> obfuscate source network information.
>>>>
>>>>
>>>> - 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] rtpengine + manual SDP manipulations

[Jeff Pyle]

David,

I have.  The "origin" flag replaces the IP address of the origin but
nothing before it.  The "session-connection" digs into the various sessions
that may be defined in the SDP and replaces all the c= lines (important for
RTP flows), but unfortunately it doesn't do anything for the s= (the
session name).



- Jeff


On Sat, Jan 18, 2020 at 11:12 AM David Villasmil <
david.villasmil.w...@gmail.com> wrote:

> I believe you can use this:
>
> replace
>
> Similar to the flags list. Controls which parts of the SDP body should be
> rewritten. Contains zero or more of:
>
>-
>
>origin
>
>Replace the address found in the *origin* (o=) line of the SDP body.
>Corresponds to *rtpproxy* o flag.
>-
>
>session connection or session-connection
>
>Replace the address found in the *session-level connection* (c=) line
>of the SDP body. Corresponds to *rtpproxy* c flag.
>
>
> Have you tried this?
>
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
>
>
> On Sat, Jan 18, 2020 at 3:59 PM Jeff Pyle  wrote:
>
>> Hello,
>>
>> I'm running OpenSIPS 2.4 and rtpengine 7.0.  I have the following
>> commands in my script:
>>
>> route[sanitize_sdp] {
>> subst_body('/^o=\S+ /o=- /');
>> subst_body('/^s=.*/s=-\r/');
>> }
>>
>> This works fine, unless I'm also using rtpengine, in which case these
>> subst_body() changes are lost.  In the past with rtpproxy this worked as
>> expected.
>>
>> I understand the potential conflicts when manipulating the SDP using
>> multiple methods at the same time.  My question is if there is a way to
>> execute this type of manual manipulation in a way that's compatible with
>> rtpengine, or achieve similar results within the rtpengine module itself?
>> My purpose is to remove the origin and session text if possible to further
>> obfuscate source network information.
>>
>>
>> - 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

[OpenSIPS-Users] rtpengine + manual SDP manipulations

[Jeff Pyle]

Hello,

I'm running OpenSIPS 2.4 and rtpengine 7.0.  I have the following commands
in my script:

route[sanitize_sdp] {
subst_body('/^o=\S+ /o=- /');
subst_body('/^s=.*/s=-\r/');
}

This works fine, unless I'm also using rtpengine, in which case these
subst_body() changes are lost.  In the past with rtpproxy this worked as
expected.

I understand the potential conflicts when manipulating the SDP using
multiple methods at the same time.  My question is if there is a way to
execute this type of manual manipulation in a way that's compatible with
rtpengine, or achieve similar results within the rtpengine module itself?
My purpose is to remove the origin and session text if possible to further
obfuscate source network information.


- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] mid_registrar mode=0 expires problem

[Jeff Pyle]

Hello,

This is on OpenSIPS 2.4.5 from the apt.opensips.org repo.

I'm running mid_registrar in mode=0 with all parameters default.  The
REGISTER message comes from the client towards OpenSIPS with an
expires=3600 in the Contact.  I run mid_registrar_save("location") and
relay the REGISTER upstream to the main registrar with the same
expires=3600.  The main registrar responds with a 200 OK, with an
expires=600.  When OpenSIPS relays the 200 OK to the client, it rewrites
the expires to 3600.  OpenSIPS hangs onto the registration in usrloc for
3600, but the main registrar only for 600.

Am I missing something with mid_registrar's operation, or is this a bug?
How do I set OpenSIPS to honor the main registrar's expires value for its
own usrloc entry and relay that back to the client?


- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] combining topology_hiding and mid_registrar

[Jeff Pyle]

Hello,

My v2.4 implementation is a type of SBC suitable for the edge of a customer
network.  I have topology_hiding working for INVITEs.  I have mid_registrar
working for REGISTERs.  I do not have them working together.  I'd like to
completely hide the topology of the inside network when sending traffic to
the outside main registrar / ITSP.  topology_hiding does a nice job with
that for INVITEs, but mid_registrar still leaks details through Via headers
and such.  Is it possible to combine them?



- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] benchmark bm_start_timer / bm_log_timer across async functions

[Jeff Pyle]

Never mind.  It helps if you bm_start_timer() and bm_stop_timer() with the
same name!



- Jeff

On Tue, Sep 18, 2018 at 5:54 PM Jeff Pyle  wrote:

> Hello,
>
> On 2.4.2 I'm running bm_start_timer("db_query_time") right before I call
> async(avp_db_query()), and bm_log_timer("db_query_time") first thing in the
> resume route.  The results are strange:
>
> benchmark (timer db_query_time [1]): 1537307242867591 [
> msgs/total/min/max/avg - LR:
> 1/1537307242867591/4294967295/1537307242867591/1537307242867591.00 |
> GB: 1/1537307242867591/4294967295/1537307242867591/1537307242867591.00]
> benchmark (timer db_query_time [1]): 1537307278764967 [
> msgs/total/min/max/avg - LR:
> 1/1537307278764967/4294967295/1537307278764967/1537307278764967.00 |
> GB: 2/3074614521632558/4294967295/1537307278764967/1537307260816279.00]
> benchmark (timer db_query_time [1]): 1537307283581219 [
> msgs/total/min/max/avg - LR:
> 1/1537307283581219/4294967295/1537307283581219/1537307283581219.00 |
> GB: 3/4611921805213777/4294967295/1537307283581219/1537307268404592.25]
>
> This is with granularity=1 for testing where the actual DB delay was
> probably 40-50ms.  I'm thinking I can't run timers across async functions?
> Or...?
>
>
> Regards,
> Jeff
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] benchmark bm_start_timer / bm_log_timer across async functions

[Jeff Pyle]

Hello,

On 2.4.2 I'm running bm_start_timer("db_query_time") right before I call
async(avp_db_query()), and bm_log_timer("db_query_time") first thing in the
resume route.  The results are strange:

benchmark (timer db_query_time [1]): 1537307242867591 [
msgs/total/min/max/avg - LR:
1/1537307242867591/4294967295/1537307242867591/1537307242867591.00 |
GB: 1/1537307242867591/4294967295/1537307242867591/1537307242867591.00]
benchmark (timer db_query_time [1]): 1537307278764967 [
msgs/total/min/max/avg - LR:
1/1537307278764967/4294967295/1537307278764967/1537307278764967.00 |
GB: 2/3074614521632558/4294967295/1537307278764967/1537307260816279.00]
benchmark (timer db_query_time [1]): 1537307283581219 [
msgs/total/min/max/avg - LR:
1/1537307283581219/4294967295/1537307283581219/1537307283581219.00 |
GB: 3/4611921805213777/4294967295/1537307283581219/1537307268404592.25]

This is with granularity=1 for testing where the actual DB delay was
probably 40-50ms.  I'm thinking I can't run timers across async functions?
Or...?


Regards,
Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Add Contact parameters

[Jeff Pyle]

Hello,

Is it possible to add a parameter to the Contact header as a message passes
through the proxy?  Specifically I need to add at least one parameter to
the Contact user.  I realize this isn't as simple as it seems on the
surface since it would probably have to be managed on every message passing
through the proxy, not unlike how the uac_replace_from() manages changing
the From header.

In my application completely rewriting the Contact header topology_hiding()
style is fine as well as long as I can manipulate the new parameters at the
time of the initial INVITE.


Regards,
Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] codec_delete_except_re() has no effect

[Jeff Pyle]

Dragomir,

If Zoiper speaks only G.729, and SIP.js speaks only G.711, rtpengine isn't
going to help.  It doesn't transcode.  From its github page
<https://github.com/sipwise/rtpengine>:

*Rtpengine* does not (yet) support:


   - Repacketization or transcoding


Is iLBC an option for you in SIP.js and Zoiper?  It's license free and
sounds a little bitter.  If not, Asterisk or FreeSWITCH could perform this
task with the appropriate G.729 licenses.




Răzvan,

Is there any effect of using either the codec manipulation or rtpengine in
a branch route?  I ask this admittedly not understanding the buffers in use.




- Jeff






On Tue, Apr 18, 2017 at 12:39 PM, Dragomir Haralambiev 
wrote:

> Hi Razvan,
>
> How to make follow connection using rtpengine?
>
> Zoiper(g729) <-> Opensips(rtpengine) <> browser (SIP.JS with
> g711)
>
> 2017-04-18 19:10 GMT+03:00 Răzvan Crainea :
>
>> Hi, Jeff!
>>
>> Unfortunately you can't use both rtpengine and codec_delete_*, that's
>> because each change different buffers. The codec_delete_* function runs on
>> the initial SDP received, then rtpengine completely overwrites the SDP with
>> whatever rtpengine replied.
>> The only way you can do something like this (although it may be very
>> ugly) is to store the rtpengine reply in a pvar using the 3rd[1] parameter
>> of the rtpengine_* functions and perform some text replaces[2] on it, then
>> replace the body "manually".
>>
>> [1] http://www.opensips.org/html/docs/modules/2.3.x/rtpengine.ht
>> ml#rtpengine.f.rtpengine_offer
>> [2] http://www.opensips.org/html/docs/modules/2.3.x/textops#idp5907728
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutionswww.opensips-solutions.com
>>
>> On 04/18/2017 06:49 PM, Jeff Pyle wrote:
>>
>> Hello,
>>
>> This is on OpenSIPS 2.3, downloaded from git and compiled today.
>>
>> An INVITE arrives over TLS with the following SDP:
>>
>> v=0
>> o=- 1492528621 1492528621 IN IP4 172.22.202.191
>> s=Polycom IP Phone
>> c=IN IP4 172.22.202.191
>> t=0 0
>> m=audio 16852 RTP/SAVP 115 9 0 8 110 18 127
>> a=rtpmap:115 G7221/32000
>> a=fmtp:115 bitrate=48000
>> a=rtpmap:9 G722/8000
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:110 iLBC/8000
>> a=fmtp:110 mode=20
>> a=rtpmap:18 G729/8000
>> a=fmtp:18 annexb=no
>> a=rtpmap:127 telephone-event/8000
>> a=rtcp:16853
>> a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:[stripped]
>> a=setup:actpass
>> a=fingerprint:sha-1 [stripped]
>> m=audio 16888 RTP/AVP 115 9 0 8 110 18 127
>> a=rtpmap:115 G7221/32000
>> a=fmtp:115 bitrate=48000
>> a=rtpmap:9 G722/8000
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:110 iLBC/8000
>> a=fmtp:110 mode=20
>> a=rtpmap:18 G729/8000
>> a=fmtp:18 annexb=no
>> a=rtpmap:127 telephone-event/8000
>> a=rtcp:16889
>>
>> I run
>>   codec_delete_expect_re(PCMU|PCMA|telephone-event)
>> but it doesn't have any effect.  The INVITE leaving after t_relay() over
>> UDP to localhost on a different port is the same as when it came in (with
>> the exception of the c= line because of rtpengine).
>>
>> At log_level=6 the only log entry I see is
>>   DBG:sipmsgops:create_codec_lumps: creating 0 streams
>>
>> I'm not sure where to go from here.
>>
>>
>> - Jeff
>>
>>
>>
>> ___
>> Users mailing 
>> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] codec_delete_except_re() has no effect

[Jeff Pyle]

Hello,

This is on OpenSIPS 2.3, downloaded from git and compiled today.

An INVITE arrives over TLS with the following SDP:

v=0
o=- 1492528621 1492528621 IN IP4 172.22.202.191
s=Polycom IP Phone
c=IN IP4 172.22.202.191
t=0 0
m=audio 16852 RTP/SAVP 115 9 0 8 110 18 127
a=rtpmap:115 G7221/32000
a=fmtp:115 bitrate=48000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:110 iLBC/8000
a=fmtp:110 mode=20
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:127 telephone-event/8000
a=rtcp:16853
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:[stripped]
a=setup:actpass
a=fingerprint:sha-1 [stripped]
m=audio 16888 RTP/AVP 115 9 0 8 110 18 127
a=rtpmap:115 G7221/32000
a=fmtp:115 bitrate=48000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:110 iLBC/8000
a=fmtp:110 mode=20
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:127 telephone-event/8000
a=rtcp:16889

I run
  codec_delete_expect_re(PCMU|PCMA|telephone-event)
but it doesn't have any effect.  The INVITE leaving after t_relay() over
UDP to localhost on a different port is the same as when it came in (with
the exception of the c= line because of rtpengine).

At log_level=6 the only log entry I see is
  DBG:sipmsgops:create_codec_lumps: creating 0 streams

I'm not sure where to go from here.


- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] unixodbc connection problem - gnutls /dev/urandom error

[Jeff Pyle]

Of course after playing with this for 2 days I find the solution right after I 
post to the list.

It was a tds_version issue.  For whatever reason FreeTDS configured with 
versions 7.1 and 7.2 don't connect from OpenSIPS, but they do from isql.  4.2, 
7.3 and 7.4 work fine from both.  In my case it's to a MS SQL Server 2014 so 
7.4 appropriate<http://www.freetds.org/userguide/choosingtdsprotocol.htm>.  The 
default tds_version is 8.0, an alias for 7.1, so that's why the default didn't 
work.



- Jeff



From: Users [users-boun...@lists.opensips.org] on behalf of Jeff Pyle
Sent: Friday, March 31, 2017 09:29
To: users@lists.opensips.org
Subject: [OpenSIPS-Users] unixodbc connection problem - gnutls /dev/urandom 
error

Hello,

I'm trying to connect OpenSIPS 2.2.3 to a MS SQL database for avpops through 
unixodbc + freetds on Debian 8.  I see the following OpenSIPS errors:

DBG:db_unixodbc:db_unixodbc_new_connection: opening connection: 
unixodbc://:@localhost/SQLMaster
ERROR:db_unixodbc:db_unixodbc_new_connection: failed to connect
ERROR:db_unixodbc:db_unixodbc_extract_error: 
unixodbc:SQLDriverConnect=08001:1:0:[unixODBC][FreeTDS][SQL Server]Unable to 
connect to data source
ERROR:db_unixodbc:db_unixodbc_extract_error: 
unixodbc:SQLDriverConnect=01000:2:20002:[unixODBC][FreeTDS][SQL Server]Adaptive 
Server connection failed

This only occurs within OpenSIPS.  Testing on isql with the same credentials 
and DSN works fine.

FreeTDS gives the following logs:

login.c:1057:detected flag 0
net.c:1259:GNUTLS: level 5:
  REC[0x21569b0]: Allocating epoch #0
net.c:1259:GNUTLS: level 3:
  ASSERT: gnutls_constate.c:586
net.c:1259:GNUTLS: level 5:
  REC[0x21569b0]: Allocating epoch #1
net.c:1259:GNUTLS: level 2:
  Failed to read /dev/urandom: Bad file descriptor
net.c:1259:GNUTLS: level 3:
  ASSERT: rnd.c:174
net.c:1259:GNUTLS: level 3:
  ASSERT: rnd.c:291
...and so on.

/dev/urandom is present, has crw-rw-rw- permissions, and works properly 
according to rngtest from rng-tools.

I've seen some posts indicating this may be a gnutls bug and recompiling 
freetds with openssl is required.  I tried that - no change.

Since this only occurs within OpenSIPS I thought I'd pose the question here.  
Any insight is greatly appreciated.



- Jeff

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] unixodbc connection problem - gnutls /dev/urandom error

[Jeff Pyle]

Hello,

I'm trying to connect OpenSIPS 2.2.3 to a MS SQL database for avpops through 
unixodbc + freetds on Debian 8.  I see the following OpenSIPS errors:

DBG:db_unixodbc:db_unixodbc_new_connection: opening connection: 
unixodbc://:@localhost/SQLMaster
ERROR:db_unixodbc:db_unixodbc_new_connection: failed to connect
ERROR:db_unixodbc:db_unixodbc_extract_error: 
unixodbc:SQLDriverConnect=08001:1:0:[unixODBC][FreeTDS][SQL Server]Unable to 
connect to data source
ERROR:db_unixodbc:db_unixodbc_extract_error: 
unixodbc:SQLDriverConnect=01000:2:20002:[unixODBC][FreeTDS][SQL Server]Adaptive 
Server connection failed

This only occurs within OpenSIPS.  Testing on isql with the same credentials 
and DSN works fine.

FreeTDS gives the following logs:

login.c:1057:detected flag 0
net.c:1259:GNUTLS: level 5:
  REC[0x21569b0]: Allocating epoch #0
net.c:1259:GNUTLS: level 3:
  ASSERT: gnutls_constate.c:586
net.c:1259:GNUTLS: level 5:
  REC[0x21569b0]: Allocating epoch #1
net.c:1259:GNUTLS: level 2:
  Failed to read /dev/urandom: Bad file descriptor
net.c:1259:GNUTLS: level 3:
  ASSERT: rnd.c:174
net.c:1259:GNUTLS: level 3:
  ASSERT: rnd.c:291
...and so on.

/dev/urandom is present, has crw-rw-rw- permissions, and works properly 
according to rngtest from rng-tools.

I've seen some posts indicating this may be a gnutls bug and recompiling 
freetds with openssl is required.  I tried that - no change.

Since this only occurs within OpenSIPS I thought I'd pose the question here.  
Any insight is greatly appreciated.



- Jeff

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] siptrace picks incorrect source socket

[Jeff Pyle]

Bogdan,

Yes.  Here's a Homer DB record written on the capture server from the HEP
packet:

  date: 2017-02-10 09:08:04
method: REGISTER
 via_1: SIP/2.0/TLS
[2607:FB90:1234:5678:9ABC:DEF0:955D:F1E5]:60640;branch=z9hG4bKo9TPB60p8Y2aQLbm;rport
 source_ip: 2607:FB90:1234:5678:9ABC:DEF0:955D:F1E5
destination_ip: 2607:FB90:1234:5678:9ABC:DEF0:955D:F1E5

(IPs mangled to protect the guilty.)


- Jeff


On Wed, Feb 8, 2017 at 4:21 PM, Bogdan-Andrei Iancu 
wrote:

> Jeff,
>
> So, for the REGISTER request, in HEP, you have as both src and dst the
> incoming IP of the request ??
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 02/08/2017 11:12 PM, Jeff Pyle wrote:
>
> Bogdan and team,
>
> This does appear to fix the source interface issue ... at least for IPv4.
> On IPv6, the errors are gone, but the source address is being reported as
> both the source and destination address for a message in siptrace.
>
> I'm using the following:
>
> listen=hep_udp:127.0.0.1:4530 children=1
> listen=hep_udp:[::1]:4530 children=1 # Not doing anything
>
> loadmodule "proto_hep.so"
> modparam("proto_hep", "hep_id", "[heppy] 127.0.0.1:9060; version=3;
> transport=udp")
>
> loadmodule "siptrace.so"
> modparam("siptrace", "trace_on", 1)
> modparam("siptrace", "trace_id", "[tid]uri=hep:heppy")
>
>
> I was looking at a registration in this particular case captured with
> sip_trace("tid", "t").
>
>
> - Jeff
>
>
> On Tue, Feb 7, 2017 at 3:08 AM, Ionut Ionita 
> wrote:
>
>> It's not that syntax anymore, but the docs weren't updated. Now you have
>> to declare an hep_id
>>
>> in proto_hep like:
>>
>> *modparam("proto_hep", "hep_id", "[heppy] 10.0.0.135:6061
>> <http://10.0.0.135:6061>; version=3; transport=tcp")*
>>
>> then in sip_trace you have to declare a trace_id like:
>>
>>   *  modparam("siptrace", "trace_id", "[hep_id]uri=hep:heppy")*
>>
>> The docs will be updated soon.
>>
>> Regards,
>>
>> Ionut Ionita
>> OpenSIPS Developer
>>
>> On 02/07/2017 04:27 AM, Jeff Pyle wrote:
>>
>> Hi Bogdan,
>>
>> Now it won't start.  I see the following errors on config check:
>>
>> Feb  6 21:21:03 [30051] ERROR:siptrace:parse_siptrace_uri: Invalid key
>>  in trace id!
>> Feb  6 21:21:03 [30051] ERROR:siptrace:parse_siptrace_id: invalid uri
>> <3;transport=udp;>
>> Feb  6 21:21:03 [30051] ERROR:siptrace:parse_trace_id: failed to parse
>> siptrace uri [3;transport=udp;]
>> Feb  6 21:21:03 [30051] CRITICAL:core:yyerror: parse error in config file
>> /usr/local//etc/opensips/opensips.cfg, line 225, column 20-21: Parameter
>>  not found in module  - can't set
>> Feb  6 21:21:03 [30051] ERROR:core:main: bad config file (1 errors)
>> Feb  6 21:21:03 [30051] NOTICE:core:main: Exiting
>>
>>
>> The script has:
>>
>>223 loadmodule "siptrace.so"
>>224 modparam("siptrace", "trace_on", 1)
>>225 modparam("siptrace", "trace_id", "[tid]uri=hep:127.0.0.1:9060;v
>> ersion=3;transport=udp;")
>>
>>
>> This is on 2.3/devel git revision 2bcf891 from around 01:00 UTC Feb 07.
>>
>>
>>
>> - Jeff
>>
>>
>> On Sun, Feb 5, 2017 at 11:00 AM, Bogdan-Andrei Iancu <
>> bog...@opensips.org> wrote:
>>
>>> Hi Jeff,
>>>
>>> Thank you for detailed report. I was able to reproduce and fix it.
>>> Please see:
>>> https://github.com/OpenSIPS/opensips/commit/b30af734cdb84991
>>> e1f906e3920a94e87c33ea04
>>>
>>> If you confirm the fix, I will do the backporting to 2.2 too.
>>>
>>> Thanks and Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>
>>> On 02/04/2017 04:41 AM, Jeff Pyle wrote:
>>>
>>> Hello,
>>> I recently enabled siptrace on an OpenSIPS 2.2.2 system acting as a
>>> registrar and a proxy.  It has one IPv4 address with several ports for UDP,
>>> TCP and TLS.  In a case where the INVITE is relayed from TLS to UDP, the
>>> replies to the UAC are incorrectly being reported as coming from the UDP
>>> socket.
>>> In the below scenario the UAC is at 64.65.66.67, and its ephemeral TCP

Re: [OpenSIPS-Users] siptrace picks incorrect source socket

[Jeff Pyle]

Bogdan and team,

This does appear to fix the source interface issue ... at least for IPv4.
On IPv6, the errors are gone, but the source address is being reported as
both the source and destination address for a message in siptrace.

I'm using the following:

listen=hep_udp:127.0.0.1:4530 children=1
listen=hep_udp:[::1]:4530 children=1 # Not doing anything

loadmodule "proto_hep.so"
modparam("proto_hep", "hep_id", "[heppy] 127.0.0.1:9060; version=3;
transport=udp")

loadmodule "siptrace.so"
modparam("siptrace", "trace_on", 1)
modparam("siptrace", "trace_id", "[tid]uri=hep:heppy")


I was looking at a registration in this particular case captured with
sip_trace("tid", "t").


- Jeff


On Tue, Feb 7, 2017 at 3:08 AM, Ionut Ionita 
wrote:

> It's not that syntax anymore, but the docs weren't updated. Now you have
> to declare an hep_id
>
> in proto_hep like:
>
> *modparam("proto_hep", "hep_id", "[heppy] 10.0.0.135:6061
> <http://10.0.0.135:6061>; version=3; transport=tcp")*
>
> then in sip_trace you have to declare a trace_id like:
>
>   *  modparam("siptrace", "trace_id", "[hep_id]uri=hep:heppy")*
>
> The docs will be updated soon.
>
> Regards,
>
> Ionut Ionita
> OpenSIPS Developer
>
> On 02/07/2017 04:27 AM, Jeff Pyle wrote:
>
> Hi Bogdan,
>
> Now it won't start.  I see the following errors on config check:
>
> Feb  6 21:21:03 [30051] ERROR:siptrace:parse_siptrace_uri: Invalid key
>  in trace id!
> Feb  6 21:21:03 [30051] ERROR:siptrace:parse_siptrace_id: invalid uri
> <3;transport=udp;>
> Feb  6 21:21:03 [30051] ERROR:siptrace:parse_trace_id: failed to parse
> siptrace uri [3;transport=udp;]
> Feb  6 21:21:03 [30051] CRITICAL:core:yyerror: parse error in config file
> /usr/local//etc/opensips/opensips.cfg, line 225, column 20-21: Parameter
>  not found in module  - can't set
> Feb  6 21:21:03 [30051] ERROR:core:main: bad config file (1 errors)
> Feb  6 21:21:03 [30051] NOTICE:core:main: Exiting
>
>
> The script has:
>
>223 loadmodule "siptrace.so"
>224 modparam("siptrace", "trace_on", 1)
>225 modparam("siptrace", "trace_id", "[tid]uri=hep:127.0.0.1:9060;
> version=3;transport=udp;")
>
>
> This is on 2.3/devel git revision 2bcf891 from around 01:00 UTC Feb 07.
>
>
>
> - Jeff
>
>
> On Sun, Feb 5, 2017 at 11:00 AM, Bogdan-Andrei Iancu 
> wrote:
>
>> Hi Jeff,
>>
>> Thank you for detailed report. I was able to reproduce and fix it. Please
>> see:
>> https://github.com/OpenSIPS/opensips/commit/b30af734cdb84991
>> e1f906e3920a94e87c33ea04
>>
>> If you confirm the fix, I will do the backporting to 2.2 too.
>>
>> Thanks and Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>> On 02/04/2017 04:41 AM, Jeff Pyle wrote:
>>
>> Hello,
>> I recently enabled siptrace on an OpenSIPS 2.2.2 system acting as a
>> registrar and a proxy.  It has one IPv4 address with several ports for UDP,
>> TCP and TLS.  In a case where the INVITE is relayed from TLS to UDP, the
>> replies to the UAC are incorrectly being reported as coming from the UDP
>> socket.
>> In the below scenario the UAC is at 64.65.66.67, and its ephemeral TCP
>> client port for this call is 61235.  The OpenSIPS proxy is at
>> 131.132.133.134 listening on UDP 5060 and TLS 5061.  Also on
>> 131.132.133.134 there is a Freeswitch media server listening on UDP 5080.
>> The UAC sends an INVITE to the proxy over TLS which routes it to the media
>> server over UDP.  The replies relayed to the UAC are reported as having
>> come from port 5060 over UDP when in reality they have come from port 5061
>> over TCP (TLS).
>> My config:
>>
>> listen=udp:131.132.133.134:5060
>> listen=tls:131.132.133.134:5061
>> listen=hep_udp:127.0.0.1:9030
>> loadmodule "siptrace.so"
>> modparam("siptrace", "trace_on", 1)
>> modparam("siptrace", "trace_id", "[hep]uri=hep:127.0.0.1:9060;t
>> ransport=udp;")
>>
>> Debugs:
>>
>> INVITE in from UAC over TLS
>> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24673]:
>> DBG:siptrace:pipport2su: proto 22, host 64.65.66.67 , port 61235
>> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24673]:
>> DBG:siptrace:pipport2su: proto 22, host 131.132.133.134 , port 5061
>> INVITE out to media 

Re: [OpenSIPS-Users] siptrace picks incorrect source socket

[Jeff Pyle]

Hi Bogdan,

Now it won't start.  I see the following errors on config check:

Feb  6 21:21:03 [30051] ERROR:siptrace:parse_siptrace_uri: Invalid key
 in trace id!
Feb  6 21:21:03 [30051] ERROR:siptrace:parse_siptrace_id: invalid uri
<3;transport=udp;>
Feb  6 21:21:03 [30051] ERROR:siptrace:parse_trace_id: failed to parse
siptrace uri [3;transport=udp;]
Feb  6 21:21:03 [30051] CRITICAL:core:yyerror: parse error in config file
/usr/local//etc/opensips/opensips.cfg, line 225, column 20-21: Parameter
 not found in module  - can't set
Feb  6 21:21:03 [30051] ERROR:core:main: bad config file (1 errors)
Feb  6 21:21:03 [30051] NOTICE:core:main: Exiting


The script has:

   223 loadmodule "siptrace.so"
   224 modparam("siptrace", "trace_on", 1)
   225 modparam("siptrace", "trace_id", "[tid]uri=hep:127.0.0.1:9060
;version=3;transport=udp;")


This is on 2.3/devel git revision 2bcf891 from around 01:00 UTC Feb 07.



- Jeff


On Sun, Feb 5, 2017 at 11:00 AM, Bogdan-Andrei Iancu 
wrote:

> Hi Jeff,
>
> Thank you for detailed report. I was able to reproduce and fix it. Please
> see:
> https://github.com/OpenSIPS/opensips/commit/
> b30af734cdb84991e1f906e3920a94e87c33ea04
>
> If you confirm the fix, I will do the backporting to 2.2 too.
>
> Thanks and Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 02/04/2017 04:41 AM, Jeff Pyle wrote:
>
> Hello,
>
> I recently enabled siptrace on an OpenSIPS 2.2.2 system acting as a
> registrar and a proxy.  It has one IPv4 address with several ports for UDP,
> TCP and TLS.  In a case where the INVITE is relayed from TLS to UDP, the
> replies to the UAC are incorrectly being reported as coming from the UDP
> socket.
>
> In the below scenario the UAC is at 64.65.66.67, and its ephemeral TCP
> client port for this call is 61235.  The OpenSIPS proxy is at
> 131.132.133.134 listening on UDP 5060 and TLS 5061.  Also on
> 131.132.133.134 there is a Freeswitch media server listening on UDP 5080.
> The UAC sends an INVITE to the proxy over TLS which routes it to the media
> server over UDP.  The replies relayed to the UAC are reported as having
> come from port 5060 over UDP when in reality they have come from port 5061
> over TCP (TLS).
>
> My config:
>
> listen=udp:131.132.133.134:5060
> listen=tls:131.132.133.134:5061
> listen=hep_udp:127.0.0.1:9030
>
> loadmodule "siptrace.so"
> modparam("siptrace", "trace_on", 1)
> modparam("siptrace", "trace_id", "[hep]uri=hep:127.0.0.1:9060;
> transport=udp;")
>
>
>
> Debugs:
>
>
> INVITE in from UAC over TLS
> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24673]:
> DBG:siptrace:pipport2su: proto 22, host 64.65.66.67 , port 61235
> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24673]:
> DBG:siptrace:pipport2su: proto 22, host 131.132.133.134 , port 5061
>
> INVITE out to media server over UDP
> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24673]:
> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24673]:
> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080
>
> 100 Trying in from media server over UDP
> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24650]:
> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080
> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24650]:
> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
>
> 180 Ringing in from media server over UDP
> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080
> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
>
> 180 Ringing out to UAC over TLS (even though it reports UDP)
> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
> DBG:siptrace:pipport2su: proto 22, host 64.65.66.67 , port 61235
>
> 200 OK in from media server over UDP
> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080
> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
>
> 200 OK out to UAC over TLS (even though it reports udp)
> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
> DBG:siptrace:pipport2su:

[OpenSIPS-Users] siptrace picks incorrect source socket

[Jeff Pyle]

Hello,

I recently enabled siptrace on an OpenSIPS 2.2.2 system acting as a
registrar and a proxy.  It has one IPv4 address with several ports for UDP,
TCP and TLS.  In a case where the INVITE is relayed from TLS to UDP, the
replies to the UAC are incorrectly being reported as coming from the UDP
socket.

In the below scenario the UAC is at 64.65.66.67, and its ephemeral TCP
client port for this call is 61235.  The OpenSIPS proxy is at
131.132.133.134 listening on UDP 5060 and TLS 5061.  Also on
131.132.133.134 there is a Freeswitch media server listening on UDP 5080.
The UAC sends an INVITE to the proxy over TLS which routes it to the media
server over UDP.  The replies relayed to the UAC are reported as having
come from port 5060 over UDP when in reality they have come from port 5061
over TCP (TLS).

My config:

listen=udp:131.132.133.134:5060
listen=tls:131.132.133.134:5061
listen=hep_udp:127.0.0.1:9030

loadmodule "siptrace.so"
modparam("siptrace", "trace_on", 1)
modparam("siptrace", "trace_id", "[hep]uri=hep:127.0.0.1:9060
;transport=udp;")



Debugs:


INVITE in from UAC over TLS
Feb  3 21:20:22 testproxy /usr/sbin/opensips[24673]:
DBG:siptrace:pipport2su: proto 22, host 64.65.66.67 , port 61235
Feb  3 21:20:22 testproxy /usr/sbin/opensips[24673]:
DBG:siptrace:pipport2su: proto 22, host 131.132.133.134 , port 5061

INVITE out to media server over UDP
Feb  3 21:20:22 testproxy /usr/sbin/opensips[24673]:
DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
Feb  3 21:20:22 testproxy /usr/sbin/opensips[24673]:
DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080

100 Trying in from media server over UDP
Feb  3 21:20:22 testproxy /usr/sbin/opensips[24650]:
DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080
Feb  3 21:20:22 testproxy /usr/sbin/opensips[24650]:
DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060

180 Ringing in from media server over UDP
Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080
Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060

180 Ringing out to UAC over TLS (even though it reports UDP)
Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
DBG:siptrace:pipport2su: proto 22, host 64.65.66.67 , port 61235

200 OK in from media server over UDP
Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080
Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060

200 OK out to UAC over TLS (even though it reports udp)
Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
DBG:siptrace:pipport2su: proto 22, host 64.65.66.67 , port 61235

ACK in from UAC over TLS
Feb  3 21:20:23 testproxy /usr/sbin/opensips[24673]:
DBG:siptrace:pipport2su: proto 22, host 64.65.66.67 , port 61235
Feb  3 21:20:23 testproxy /usr/sbin/opensips[24673]:
DBG:siptrace:pipport2su: proto 22, host 131.132.133.134 , port 5061

ACK out to media server over UDP
Feb  3 21:20:23 testproxy /usr/sbin/opensips[24673]:
DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
Feb  3 21:20:23 testproxy /usr/sbin/opensips[24673]:
DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080


Everything routes properly, but it isn't reported by siptrace properly.  Is
this a bug or am I doing something wrong?



- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] IPv6 causing problems with HEP in siptrace

[Jeff Pyle]

Hello,

I have a simple dual-stack OpenSIPS 2.2.2 configuration.  It includes a
registrar and basic routing between locally registered users.  These users
have a mix of IPv4 and IPv6 contacts.  All is well.  I recently added Homer
to the mix.  The siptrace module is acting as a capture agent, duplicating
messages over HEPv3 to an upstream Homer capture server.

When one of the clients is IPv6, duplication fails.  I see this message:

ERROR:siptrace:trace_send_hep_duplicate: ERROR: trace_send_hep_duplicate:
interworking detected ?
ERROR:siptrace:save_siptrace: Failed to duplicate with hep to <:>

I'd like to duplicate messages regardless whether they've IPv4 or IPv6, as
many dialogs are both.  The Homer capture server is IPv6-enabled and can
receive HEP messages either (I think).  I've tried to configure the
siptrace trace_id with an IPv6 address but it doesn't look like it's able
to parse it.

What am I missing?



- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] 2.2 crash with async, db_virtual and unixodbc

[Jeff Pyle]

Hi Răzvan ,

Ok.  I found this on the 2.2 release info page:

2.27  DB_VIRTUAL module
  added async raw query support

I thought I might be able to wrap db_virtual around unixodbc and get it to 
work.  Apparently not!  Or, at least not yet.

My application is to attempt to replace an aging Kamailio proxy with an 
OpenSIPS one in async mode.  Unfortunately I don't have control over the data 
or where it lives; it's stuck in an MSSQL server.  Actually, in a few 
geographically distributed but otherwise equal MSSQL servers so the db_virtual 
layer was perfect.

rest_get is mentioned as an available to async.  I don't know much about rest 
but I'll look at writing a wrapper of sorts to get to the stored procedure that 
way.  I'm open to any suggestions!


- Jeff


From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Razvan Crainea
Sent: Wednesday, September 07, 2016 4:07 AM
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] 2.2 crash with async, db_virtual and unixodbc

Hi, Jeff!

Unfortunately async operations are only supported by the MySQL backend, 
therefore it won't work with unixodbc or other backends. Now it crashes because 
of a mishandling in the db_virtual module. We are working on a fix for the 
crash, but even after the fix, you will still be unable to run async queries 
with unixodbc.
If you really want to do it async, then you should use MySQL backend. Also, 
don't forget to open a feature request on the issues page[1] to support async 
queries for unixodbc.

[1] https://github.com/OpenSIPS/opensips/issues

Best regards,


Răzvan Crainea

OpenSIPS Solutions

www.opensips-solutions.com<http://www.opensips-solutions.com>
On 09/07/2016 04:16 AM, Jeff Pyle wrote:

Hello,



I'm working from the 2.2 nightly build repo on Debian Jessie, 64-bit, 
specifically, 2.2.1~20160830~7261cf0-1.



I have a simple test script that runs a stored procedure on a Microsoft SQL 
2014 server and xlogs the returned AVPs.  This works fine.  When I break it up 
into an async() function and a return route block, I get a crash every time.



Script:



route {

xlog("L_INFO", "Sending query...\n");

async(avp_db_query("exec dbo.doStuff '1','2','3','4'",

"$avp(db1);$avp(db2);$avp(db3)"), post_db_dip);

}



route [post_db_dip] {

xlog("L_INFO", "Back from query.\n");



while (is_avp_set("$avp(db1)") && is_avp_set("$avp(db2)") && 
is_avp_set("$avp(db3)")) {

xlog("L_INFO", "db1=$avp(db1), db2=$avp(db2), 
db3=$avp(db3)\n");

avp_delete("$avp(db1)");

avp_delete("$avp(db2)");

avp_delete("$avp(db3)");

}



xlog("L_INFO", "End of processing.\n");



sl_send_reply("600", "Road Closed");

exit;

}



The debug=6:



...

/usr/sbin/opensips[19887]: DBG:avpops:ops_async_dbquery: query [exec 
dbo.doStuff '1','2','3','4']

/usr/sbin/opensips[19887]: DBG:db_virtual:db_virtual_async_raw_query: f call 
handle size = 1

/usr/sbin/opensips[19887]: DBG:db_virtual:try_reconnect: try reconnect

/usr/sbin/opensips[19887]: DBG:db_virtual:db_virtual_async_raw_query: flags1 = 3

/usr/sbin/opensips[19883]: DBG:core:handle_sigs: status = 11

/usr/sbin/opensips[19883]: INFO:core:handle_sigs: child process 19887 exited by 
a signal 11

/usr/sbin/opensips[19883]: INFO:core:handle_sigs: core was not generated

/usr/sbin/opensips[19883]: INFO:core:handle_sigs: terminating due to SIGCHLD

/usr/sbin/opensips[19890]: INFO:core:sig_usr: signal 15 received

/usr/sbin/opensips[19889]: INFO:core:sig_usr: signal 15 received

/usr/sbin/opensips[19888]: INFO:core:sig_usr: signal 15 received

/usr/sbin/opensips[19886]: INFO:core:sig_usr: signal 15 received

/usr/sbin/opensips[19885]: INFO:core:sig_usr: signal 15 received

/usr/sbin/opensips[19884]: INFO:core:sig_usr: signal 15 received

/usr/sbin/opensips[19883]: INFO:core:cleanup: cleanup

...and so forth.



The process that crashes, 19887 in this particular case, is a listener process. 
 I never see the "Back from xlog" xlog appear.  OpenSIPS immediately respawns 
but I suspect that's systemd.



Am I doing something wrong, or is this a bug?





- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] 2.2 crash with async, db_virtual and unixodbc

[Jeff Pyle]

Hello,



I'm working from the 2.2 nightly build repo on Debian Jessie, 64-bit, 
specifically, 2.2.1~20160830~7261cf0-1.



I have a simple test script that runs a stored procedure on a Microsoft SQL 
2014 server and xlogs the returned AVPs.  This works fine.  When I break it up 
into an async() function and a return route block, I get a crash every time.



Script:



route {

xlog("L_INFO", "Sending query...\n");

async(avp_db_query("exec dbo.doStuff '1','2','3','4'",

"$avp(db1);$avp(db2);$avp(db3)"), post_db_dip);

}



route [post_db_dip] {

xlog("L_INFO", "Back from query.\n");



while (is_avp_set("$avp(db1)") && is_avp_set("$avp(db2)") && 
is_avp_set("$avp(db3)")) {

xlog("L_INFO", "db1=$avp(db1), db2=$avp(db2), 
db3=$avp(db3)\n");

avp_delete("$avp(db1)");

avp_delete("$avp(db2)");

avp_delete("$avp(db3)");

}



xlog("L_INFO", "End of processing.\n");



sl_send_reply("600", "Road Closed");

exit;

}



The debug=6:



...

/usr/sbin/opensips[19887]: DBG:avpops:ops_async_dbquery: query [exec 
dbo.doStuff '1','2','3','4']

/usr/sbin/opensips[19887]: DBG:db_virtual:db_virtual_async_raw_query: f call 
handle size = 1

/usr/sbin/opensips[19887]: DBG:db_virtual:try_reconnect: try reconnect

/usr/sbin/opensips[19887]: DBG:db_virtual:db_virtual_async_raw_query: flags1 = 3

/usr/sbin/opensips[19883]: DBG:core:handle_sigs: status = 11

/usr/sbin/opensips[19883]: INFO:core:handle_sigs: child process 19887 exited by 
a signal 11

/usr/sbin/opensips[19883]: INFO:core:handle_sigs: core was not generated

/usr/sbin/opensips[19883]: INFO:core:handle_sigs: terminating due to SIGCHLD

/usr/sbin/opensips[19890]: INFO:core:sig_usr: signal 15 received

/usr/sbin/opensips[19889]: INFO:core:sig_usr: signal 15 received

/usr/sbin/opensips[19888]: INFO:core:sig_usr: signal 15 received

/usr/sbin/opensips[19886]: INFO:core:sig_usr: signal 15 received

/usr/sbin/opensips[19885]: INFO:core:sig_usr: signal 15 received

/usr/sbin/opensips[19884]: INFO:core:sig_usr: signal 15 received

/usr/sbin/opensips[19883]: INFO:core:cleanup: cleanup

...and so forth.



The process that crashes, 19887 in this particular case, is a listener process. 
 I never see the "Back from xlog" xlog appear.  OpenSIPS immediately respawns 
but I suspect that's systemd.



Am I doing something wrong, or is this a bug?





- Jeff


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] return code from perl_exec() versus perl_exec_simple()

[Jeff Pyle]

Hi Bogdan,

The patch gives errors.

I have two perl functions:

sub return1 {
return 1;
}

sub returnminus1 {
return -1;
}

In the OpenSIPS script I have:

route {
perl_exec_simple("return1");
xlog("L_INFO", "$retcode\n");
perl_exec_simple("returnminus1");
xlog("L_INFO", "$retcode\n");

perl_exec("return1");
xlog("L_INFO", "$retcode\n");
perl_exec("returnminus1");
xlog("L_INFO", "$retcode\n");

sl_send_reply("600", "Road Closed");
drop;
exit;
}

Syslog shows:

 /usr/sbin/opensips[22354]: ERROR:perl:perl_exec_simple: function return1
failed to return anything
 /usr/sbin/opensips[22354]: -1
 /usr/sbin/opensips[22354]: ERROR:perl:perl_exec_simple: function
returnminus1 failed to return anything
 /usr/sbin/opensips[22354]: -1
 /usr/sbin/opensips[22354]: 1
 /usr/sbin/opensips[22354]: -1

perl_exec() still works okay, but perl_exec_simple() gives errors.


- Jeff





On Thu, Jul 7, 2016 at 5:44 AM, Bogdan-Andrei Iancu 
wrote:

> Hi Jeff,
>
> I think the difference is a mis. Could you please test the attached patch.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 07.07.2016 04:42, Jeff Pyle wrote:
>
> Hello,
>
> I'm using 2.1 cloned from git earlier today.  I notice when I use
> perl_exec_simple(), the return code is always 1, regardless of the return
> code at the end of the perl function.  With perl_exec(), however, the
> return code matches the return code in the function.  Is this difference
> intentional?
>
>
> - Jeff
>
>
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] return code from perl_exec() versus perl_exec_simple()

[Jeff Pyle]

Hello,

I'm using 2.1 cloned from git earlier today.  I notice when I use
perl_exec_simple(), the return code is always 1, regardless of the return
code at the end of the perl function.  With perl_exec(), however, the
return code matches the return code in the function.  Is this difference
intentional?


- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] How to append header to stateless reply

[Jeff Pyle]

Hello,

How can I add a header to a stateless reply?  Or, if that's not possible,
to a transactional reply?

I'm trying to do something like this:

route {
  ...
  append_hf("P-Custom-Header: $avp(value)\r\n");
  sl_send_reply("123", "Custom Response");
  exit;
}

where P-Custom-Header appears in the 123 Custom Response reply.  The above
snippet would work only for a relayed request I believe, and since I
haven't received a network reply, I'm not sure how I could use an
onreply_route.  I'm stuck.



- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Ubuntu 16.04 can no longer access trusty packages at apt.opensips.org

[Jeff Pyle]

Looks good!  apt-get update completed without error, and:

$ apt-cache policy opensips
opensips:
  Installed: 2.1.2-1
  Candidate: 2.1.2-1
  Version table:
 2.1.2-1 500
500 http://apt.opensips.org xenial/2.1-releases amd64 Packages
 *** 2.1.2-1 100
100 /var/lib/dpkg/status


Thank you.


- Jeff




On Thu, May 12, 2016 at 2:50 AM, Nick Altmann 
wrote:

> Hi, Jeff!
>
> I’ve resigned the repository. Please, try again.
>
> --
> Nick
>
> 2016-05-11 16:26 GMT+02:00 Jeff Pyle :
>
>> Thanks, Nick.  That's great.
>>
>> I think I've broken something.  I can't get past this on an apt-get
>> update:
>>
>> E: Failed to fetch http://apt.opensips.org/dists/xenial/Release  No Hash
>> entry in Release file
>> /var/lib/apt/lists/partial/apt.opensips.org_dists_xenial_Release which is
>> considered strong enough for security purposes
>>
>> I've removed the /var/lib/apt/lists/partial/apt.opensips.org* files and
>> tried apt-get update again.  It still occurs.  I did re-import
>> the 81CE21E7049AD65B key.
>>
>> Do you have any suggestions?
>>
>>
>>
>> - Jeff
>>
>>
>>
>> On Wed, May 11, 2016 at 9:05 AM, Nick Altmann 
>> wrote:
>>
>>> Hi, Jeff
>>>
>>> I’ve changed GPG key to more secure and also I’ve added xenial builds.
>>> Please, test.
>>> We are not watching for new releases of ubuntu, but always glad to add
>>> them by request.
>>>
>>> --
>>> Nick
>>>
>>> 2016-05-01 2:23 GMT+02:00 Jeff Pyle :
>>>
>>>> Hello,
>>>>
>>>> First off, thanks to everyone who makes this repo possible.
>>>>
>>>> Ubuntu 15.10 works just fine with the trust repo at apt.opensips.org.
>>>>  16.04, however, disables support for SHA1:
>>>>
>>>> W: http://apt.opensips.org/dists/trusty/Release.gpg: Signature by key
>>>> 33FED9119AC17EB465F51BF001839BE75F2FBB7C uses weak digest algorithm (SHA1)
>>>> E: Failed to fetch http://apt.opensips.org/dists/trusty/Release  No
>>>> Hash entry in Release file
>>>> /var/lib/apt/lists/partial/apt.opensips.org_dists_trusty_Release which is
>>>> considered strong enough for security purposes
>>>> E: Some index files failed to download. They have been ignored, or old
>>>> ones used instead.
>>>>
>>>>
>>>> I've tried disabling GPG checks with "APT::Get::AllowUnauthenticated
>>>> "true";" and the like but it doesn't seem to help.
>>>>
>>>> Now that 16.04 is out, and it's LTS, I was curious when we might see a
>>>> xenial repo available.
>>>>
>>>>
>>>> - Jeff
>>>>
>>>>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Ubuntu 16.04 can no longer access trusty packages at apt.opensips.org

[Jeff Pyle]

Thanks, Nick.  That's great.

I think I've broken something.  I can't get past this on an apt-get update:

E: Failed to fetch http://apt.opensips.org/dists/xenial/Release  No Hash
entry in Release file
/var/lib/apt/lists/partial/apt.opensips.org_dists_xenial_Release which is
considered strong enough for security purposes

I've removed the /var/lib/apt/lists/partial/apt.opensips.org* files and
tried apt-get update again.  It still occurs.  I did re-import
the 81CE21E7049AD65B key.

Do you have any suggestions?



- Jeff



On Wed, May 11, 2016 at 9:05 AM, Nick Altmann 
wrote:

> Hi, Jeff
>
> I’ve changed GPG key to more secure and also I’ve added xenial builds.
> Please, test.
> We are not watching for new releases of ubuntu, but always glad to add
> them by request.
>
> --
> Nick
>
> 2016-05-01 2:23 GMT+02:00 Jeff Pyle :
>
>> Hello,
>>
>> First off, thanks to everyone who makes this repo possible.
>>
>> Ubuntu 15.10 works just fine with the trust repo at apt.opensips.org.
>>  16.04, however, disables support for SHA1:
>>
>> W: http://apt.opensips.org/dists/trusty/Release.gpg: Signature by key
>> 33FED9119AC17EB465F51BF001839BE75F2FBB7C uses weak digest algorithm (SHA1)
>> E: Failed to fetch http://apt.opensips.org/dists/trusty/Release  No Hash
>> entry in Release file
>> /var/lib/apt/lists/partial/apt.opensips.org_dists_trusty_Release which is
>> considered strong enough for security purposes
>> E: Some index files failed to download. They have been ignored, or old
>> ones used instead.
>>
>>
>> I've tried disabling GPG checks with "APT::Get::AllowUnauthenticated
>> "true";" and the like but it doesn't seem to help.
>>
>> Now that 16.04 is out, and it's LTS, I was curious when we might see a
>> xenial repo available.
>>
>>
>> - 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

[OpenSIPS-Users] Ubuntu 16.04 can no longer access trusty packages at apt.opensips.org

[Jeff Pyle]

Hello,

First off, thanks to everyone who makes this repo possible.

Ubuntu 15.10 works just fine with the trust repo at apt.opensips.org.
 16.04, however, disables support for SHA1:

W: http://apt.opensips.org/dists/trusty/Release.gpg: Signature by key
33FED9119AC17EB465F51BF001839BE75F2FBB7C uses weak digest algorithm (SHA1)
E: Failed to fetch http://apt.opensips.org/dists/trusty/Release  No Hash
entry in Release file
/var/lib/apt/lists/partial/apt.opensips.org_dists_trusty_Release which is
considered strong enough for security purposes
E: Some index files failed to download. They have been ignored, or old ones
used instead.


I've tried disabling GPG checks with "APT::Get::AllowUnauthenticated
"true";" and the like but it doesn't seem to help.

Now that 16.04 is out, and it's LTS, I was curious when we might see a
xenial repo available.


- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Can I use loop back when there is no network link ?

[Jeff Pyle]

Rodrigo,

I've run OpenSIPS on the loopback interface to talk to other SIP-speaking
entities on the same system.  I haven't had any problems.

If your co-workers' project has OpenSIPS and a softphone, with no network
connectivity, who are they going to call?



- Jeff



On Fri, Apr 29, 2016 at 2:37 PM, Rodrigo Pimenta Carvalho  wrote:

> Hi.
>
>
> Some co-workers are today creating a project that will use OpenSIPS and a
> softphone. All in a same hardware. That is, they want to put the softphone
> communicating with the SIP proxy without any network interface or link.
> That is, there will not be a network interface from where OpenSIPS could
> listen to UPD or TCP packets. In this case, they intend to use a kind of
> loop back. So, in the opensips.cfg file they intend to write "lo" in spite
> of "eth0" or "wlan0". But, doing it, the OpenSIPS doesn't works when it
> receives a SIP INVITE, for example.
>
>
> So, what is the best way to run OpenSIPS and let it listen to a kind of
> loop back interface?
>
>
> Any hint will be very helpful!
>
>
> Best regards.
>
>
> RODRIGO PIMENTA CARVALHO
> Inatel Competence Center
> Software
> Ph: +55 35 3471 9200 RAMAL 979
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Processing calling-name(CNAM) from PRI

[Jeff Pyle]

Zahid,

You'd have to receive the initial INVITE, place it on hold somehow (not the
SIP RFC sense of "hold", but just "in timeout", "on ice", "go stand in the
corner until I tell you to leave", etc), wait for the INFO message, parse
the information elements you want, recover the initial INVITE, update the
fields you need (RPID/PAI, From, etc) and continue on about your business.
I'm not sure how I would handle the putting-it-on-hold part, or the
subsequent recovery.  A proxy's job is generally to relay messages, and in
this case, you want it to store a message for a period, then recover it and
continue processing.  That's not something a proxy normally does.  So,
that's a tricky one.


- Jeff


On Fri, Dec 18, 2015 at 10:12 AM, Zahid Mehmood  wrote:

> Hi Jeff,
>Thanks for your response.  From what I understand from Cisco
> documentation, gateway seems to act that way when using H323 but, sadly,
> not for SIP.  I will push Cisco about this.
>
> Assuming the worst, Is there any thing I can try on the proxy side to get
> the desired results?
>
> Regards,
> --
> Zahid
>
>
> On Fri, Dec 18, 2015 at 9:44 AM, Jeff Pyle 
> wrote:
>
>> In Adtran TA900 series gateways (very Cisco-like) I'm able to configure
>> the PRI interface to wait for the FACILITY message before sending the
>> initial INVITE.  When the INVITE does leave the gateway towards the proxy,
>> it has full caller name information.  Perhaps something like this is
>> available on the Cisco.  I hope so, because if not, you're going to have a
>> difficult time integrating the INFO message.
>>
>>
>> - Jeff
>>
>>
>> On Thu, Dec 17, 2015 at 2:53 PM, Zahid Mehmood  wrote:
>>
>>> Hi,
>>>I am having trouble figuring out how to process the calling-name
>>> coming from the PRI. In my setup, PRI is connected to a Cisco media gateway
>>> which sends traffic to the proxy servers.  Calling name is not coming  in
>>> the ISDN setup message.  It is actually provided in a separate facility
>>> message [1].
>>>
>>> Cisco gateway processes this secondary messages and generates a INFO
>>> message.  Polycom phone sends the 200 ok message but there is no change in
>>> the visible caller id.
>>>
>>> Does anyone have a working example or suggestion of how this is supposed
>>> to work?
>>>
>>> Invite:
>>>
>>> U 2015/12/17 14:20:31.215540 10.10.1.1:50975 -> 10.10.2.2:5060
>>> INVITE sip:10301@10.10.2.2:5060 SIP/2.0.
>>> Via: SIP/2.0/UDP 10.10.1.1:5060;branch=z9hG4bK3A2284.
>>> Remote-Party-ID: "111222" >> >;party=calling;screen=yes;privacy=off.
>>> From: "111222" ;tag=5745CCC-1C72.
>>> To: .
>>> Date: Thu, 17 Dec 2015 19:20:31 GMT.
>>> Call-ID: 12968BB5-A42A11E5-8062F2AF-E28C686E@10.10.1.1.
>>> Supported: 100rel,timer,resource-priority,replaces,sdp-anat.
>>> Min-SE:  1800.
>>> Cisco-Guid: 0311776101-2754220517-2148597785-1445067520.
>>> User-Agent: Cisco-SIPGateway/IOS-12.x.
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>> SUBSCRIBE, NOTIFY, INFO, REGISTER.
>>> CSeq: 101 INVITE.
>>> Max-Forwards: 70.
>>> Timestamp: 1450380031.
>>> Contact: .
>>> Expires: 180.
>>> Allow-Events: telephone-event.
>>> Content-Type: application/sdp.
>>> Content-Disposition: session;handling=required.
>>> Content-Length: 279.
>>> .
>>> v=0.
>>> o=CiscoSystemsSIP-GW-UserAgent 3918 6190 IN IP4 10.10.1.1.
>>> s=SIP Call.
>>> c=IN IP4 10.10.1.1.
>>> t=0 0.
>>> m=audio 18854 RTP/AVP 0 18 101.
>>> c=IN IP4 10.10.1.1.
>>> a=rtpmap:0 PCMU/8000.
>>> a=rtpmap:18 G729/8000.
>>> a=fmtp:18 annexb=no.
>>> a=rtpmap:101 telephone-event/8000.
>>> a=fmtp:101 0-16.
>>>
>>> Invite messages:
>>>
>>> U 2015/12/17 14:20:31.546310 10.10.1.1:50975 -> 10.10.2.2:5060
>>> INFO sip:10301@10.219.136.69:5060 SIP/2.0.
>>> Via: SIP/2.0/UDP 10.10.1.1:5060;branch=z9hG4bK3C1EC0.
>>> From: "111222" ;tag=5745CCC-1C72.
>>> To: ;tag=1768D8EC-CCDB1323.
>>> Date: Thu, 17 Dec 2015 19:20:31 GMT.
>>> Call-ID: 12968BB5-A42A11E5-8062F2AF-E28C686E@10.10.1.1.
>>> User-Agent: Cisco-SIPGateway/IOS-12.x.
>>> Max-Forwards: 70.
>>> Route: .
>>> Timestamp: 1450380031.
>>> CSeq: 103 INFO.
>>> Contact: .
>>> Remote-Party-I

Re: [OpenSIPS-Users] Processing calling-name(CNAM) from PRI

[Jeff Pyle]

In Adtran TA900 series gateways (very Cisco-like) I'm able to configure the
PRI interface to wait for the FACILITY message before sending the initial
INVITE.  When the INVITE does leave the gateway towards the proxy, it has
full caller name information.  Perhaps something like this is available on
the Cisco.  I hope so, because if not, you're going to have a difficult
time integrating the INFO message.


- Jeff


On Thu, Dec 17, 2015 at 2:53 PM, Zahid Mehmood  wrote:

> Hi,
>I am having trouble figuring out how to process the calling-name coming
> from the PRI. In my setup, PRI is connected to a Cisco media gateway which
> sends traffic to the proxy servers.  Calling name is not coming  in the
> ISDN setup message.  It is actually provided in a separate facility message
> [1].
>
> Cisco gateway processes this secondary messages and generates a INFO
> message.  Polycom phone sends the 200 ok message but there is no change in
> the visible caller id.
>
> Does anyone have a working example or suggestion of how this is supposed
> to work?
>
> Invite:
>
> U 2015/12/17 14:20:31.215540 10.10.1.1:50975 -> 10.10.2.2:5060
> INVITE sip:10301@10.10.2.2:5060 SIP/2.0.
> Via: SIP/2.0/UDP 10.10.1.1:5060;branch=z9hG4bK3A2284.
> Remote-Party-ID: "111222"  >;party=calling;screen=yes;privacy=off.
> From: "111222" ;tag=5745CCC-1C72.
> To: .
> Date: Thu, 17 Dec 2015 19:20:31 GMT.
> Call-ID: 12968BB5-A42A11E5-8062F2AF-E28C686E@10.10.1.1.
> Supported: 100rel,timer,resource-priority,replaces,sdp-anat.
> Min-SE:  1800.
> Cisco-Guid: 0311776101-2754220517-2148597785-1445067520.
> User-Agent: Cisco-SIPGateway/IOS-12.x.
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER.
> CSeq: 101 INVITE.
> Max-Forwards: 70.
> Timestamp: 1450380031.
> Contact: .
> Expires: 180.
> Allow-Events: telephone-event.
> Content-Type: application/sdp.
> Content-Disposition: session;handling=required.
> Content-Length: 279.
> .
> v=0.
> o=CiscoSystemsSIP-GW-UserAgent 3918 6190 IN IP4 10.10.1.1.
> s=SIP Call.
> c=IN IP4 10.10.1.1.
> t=0 0.
> m=audio 18854 RTP/AVP 0 18 101.
> c=IN IP4 10.10.1.1.
> a=rtpmap:0 PCMU/8000.
> a=rtpmap:18 G729/8000.
> a=fmtp:18 annexb=no.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
>
> Invite messages:
>
> U 2015/12/17 14:20:31.546310 10.10.1.1:50975 -> 10.10.2.2:5060
> INFO sip:10301@10.219.136.69:5060 SIP/2.0.
> Via: SIP/2.0/UDP 10.10.1.1:5060;branch=z9hG4bK3C1EC0.
> From: "111222" ;tag=5745CCC-1C72.
> To: ;tag=1768D8EC-CCDB1323.
> Date: Thu, 17 Dec 2015 19:20:31 GMT.
> Call-ID: 12968BB5-A42A11E5-8062F2AF-E28C686E@10.10.1.1.
> User-Agent: Cisco-SIPGateway/IOS-12.x.
> Max-Forwards: 70.
> Route: .
> Timestamp: 1450380031.
> CSeq: 103 INFO.
> Contact: .
> Remote-Party-ID: "WIRELESS CALLER"  >;party=calling;screen=no;privacy=off.
> Content-Length: 0.
> .
>
>
> Best Regards,
>
> --
> Zahid
>
> [1]
> http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/sip/configuration/15-mt/sip-config-15-mt-book/voi-sip-isdn.html#GUID-53D5C9AB-AAC4-4178-8158-0DAEFB5BC33E
> (figure 2 is close to what we are seeing)
>
> ___
> 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] How to view bitrate, sampling rate and frame size during a SIP call?

[Jeff Pyle]

I believe the absence of a ptime means a default of 20ms.  That may be
codec dependent; I don't recall.


- Jeff


On Wed, Dec 9, 2015 at 1:11 AM, Nabeel  wrote:

> Hi Jeff,
>
> Thanks for the information.  I checked the SDPs, however mine does not
> have the 'a:ptime' line which could indicate the frame size.  Is there a
> way to enable this?  Here is an example of what I am seeing:
>
> v=0
>> o=user 0 0 IN IP4 162.212.130.252
>> s=Session SIP/SDP
>> c=IN IP4 162.212.130.252
>> t=0 0
>> a=ice-ufrag:171m3
>> a=ice-pwd:27g6nm2sol7btqvgper41odgjk
>> m=audio 55718 RTP/AVP 201 101
>> a=rtpmap:201 OPUS/48000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-15
>> a=candidate:1 1 udp 2130706431 10.53.232.161 21000 typ host
>> a=candidate:3 1 udp 1694498815 188.29.165.133 49190 typ srflx raddr
>> 10.53.232.161 rport 21000
>> a=candidate:2 1 udp 16777215 162.212.130.252 55718 typ relay raddr
>> 188.29.165.133 rport 49190
>> a=candidate:1 2 udp 2130706430 10.53.232.161 21001 typ host
>> a=candidate:3 2 udp 1694498814 188.29.165.133 49191 typ srflx raddr
>> 10.53.232.161 rport 21001
>> a=candidate:2 2 udp 16777214 162.212.130.252 57171 typ relay raddr
>> 188.29.165.133 rport 49191
>
>
>
> On 8 December 2015 at 14:21, Jeff Pyle 
> wrote:
>
>> OpenSIPS doesn't handle media so it has no knowledge of these things.
>> You could glean some of this information by inspecting the offer and answer
>> SDPs as they pass through.  For example, here is an answer SDP that passed
>> through reply_route attached to a 200 OK:
>>
>> v=0.
>> o=FreeSWITCH 1449573019 1449573020 IN IP4 192.168.5.5.
>> s=FreeSWITCH.
>> c=IN IP4 192.168.5.5.
>> t=0 0.
>> m=audio 11158 RTP/AVP 9 101.
>> a=rtpmap:9 G722/8000.
>> a=rtpmap:101 telephone-event/8000.
>> a=fmtp:101 0-16.
>> a=ptime:20.
>>
>> From this data you know it's 8khz sampling rate, since it's G722 you know
>> it's a 64kbps bitrate, and the ptime is 20ms.  You'd have to account for
>> future in-dialog requests (reINVITEs and UPDATEs) that may change these
>> parameters.
>>
>> In order to make this data available for live calls, you'd probably have
>> to store them in dialog variables.
>>
>> In other words, it may be possible to maintain this data from within
>> OpenSIPS, but it becomes complicated quickly depending on the variety of
>> endpoints and applications you use.  It is generally easier to gather this
>> data from the endpoints themselves but you've already said your app does
>> not have a way to do that.  That's unfortunate.
>>
>>
>> - Jeff
>>
>>
>> On Sat, Dec 5, 2015 at 11:21 PM, Nabeel  wrote:
>>
>>> Hello,
>>>
>>> I need to view the active sampling rate, bitrate and frame size during a
>>> SIP call.  The app currently does not have a user interface or custom
>>> function to display this.  Is there any other way I can view these
>>> parameters during a live call?  What is the simplest way to do this?
>>>
>>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Cachedb_local question

[Jeff Pyle]

Travis,

You don't really have to "tell" OpenSIPS if a client is unregistered.  In
the simple case, you'll do a lookup() within your script, and it will
return [1] with an error code of -1 if the contact is not registered.

If you want to run your logic when a client goes unregistered, rather than
detecting it during the script execution, you can use an event route [2].
Here's a simple one I use to throw a syslog entry for such an occasion:

event_route[E_UL_AOR_DELETE] {
$var(aor) = 0;
fetch_event_params("aor=$var(aor)");
xlog("L_NOTICE", "** $var(aor) is DOWN\n");
}

Hopefully that's helpful.

  [1]
http://www.opensips.org/html/docs/modules/2.1.x/registrar.html#id294366
  [2] http://www.opensips.org/html/docs/modules/2.1.x/usrloc.html#id295250


- Jeff


On Tue, Dec 8, 2015 at 11:07 AM, Travis Manson-Drake  wrote:

> Hello everyone!
>
> Hope you’re all doing well.
>
>
>
> Does anyone know of a way I might tell opensips when a UAC becomes un
> registered? Or what value I might tell it to parse to see if that UAC is
> unregistered?
>
>
>
> Really what I’m trying to do is have an if statement that preforms some
> logic if the UAC reports back unregistered or unavail.
>
>
>
> Any input is greatly appreciated!
>
>
>
> Happy Holidays!
>
>
>
>
>
> *Travis Manson-Drake*
>
> *Voice Systems Analyst L1*
>
> *Simply Bits, LLC*
>
> *Now You’re Thinkin’ Smart!*
>
> 5225 N. Sabino Canyon Road
> Tucson, AZ 85750
>
> *Phone:* 520-545-0311
>
> *Fax:* 520-545-7252
>
> *Support Hotline*: 5205450333
>
> www.simplybits.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] How to view bitrate, sampling rate and frame size during a SIP call?

[Jeff Pyle]

OpenSIPS doesn't handle media so it has no knowledge of these things.  You
could glean some of this information by inspecting the offer and answer
SDPs as they pass through.  For example, here is an answer SDP that passed
through reply_route attached to a 200 OK:

v=0.
o=FreeSWITCH 1449573019 1449573020 IN IP4 192.168.5.5.
s=FreeSWITCH.
c=IN IP4 192.168.5.5.
t=0 0.
m=audio 11158 RTP/AVP 9 101.
a=rtpmap:9 G722/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.

>From this data you know it's 8khz sampling rate, since it's G722 you know
it's a 64kbps bitrate, and the ptime is 20ms.  You'd have to account for
future in-dialog requests (reINVITEs and UPDATEs) that may change these
parameters.

In order to make this data available for live calls, you'd probably have to
store them in dialog variables.

In other words, it may be possible to maintain this data from within
OpenSIPS, but it becomes complicated quickly depending on the variety of
endpoints and applications you use.  It is generally easier to gather this
data from the endpoints themselves but you've already said your app does
not have a way to do that.  That's unfortunate.


- Jeff


On Sat, Dec 5, 2015 at 11:21 PM, Nabeel  wrote:

> Hello,
>
> I need to view the active sampling rate, bitrate and frame size during a
> SIP call.  The app currently does not have a user interface or custom
> function to display this.  Is there any other way I can view these
> parameters during a live call?  What is the simplest way to do this?
>
> ___
> 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] hide to_tag from upstream provider

[Jeff Pyle]

The to_tag is going to appear for any message beyond the initial request.
Short answer, no, you can't hide the to_tag.  It's very important to the
SIP message.

Still, if you want to change the to_tag to something different, you could
use B2BUA-based topology hiding[1].  You will need a separate OpenSIPS
instance for this.

Dialog-based topology hiding[2] may obfuscate the to_tag as well.  From the
doc page it doesn't appear so.  I'll include it for completeness.

Why you want to hide the to_tag?


  [1] http://www.opensips.org/Documentation/Tutorials-B2BUA#toc12
  [2]
http://www.opensips.org/html/docs/modules/2.1.x/topology_hiding.html#id293540


- Jeff


On Mon, Nov 30, 2015 at 4:25 AM, Søren Andersen  wrote:

> Hello,
>
>
>
> Is it posibleto hide the to_tag from my upstream provider? – fx. If I
> rewrite the call to another user my upstream will only see one to_tag in
> the 1xx response?
>
>
>
>
>
> /Søren
>
>
>
> ___
> 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] Knowing when a call was diverted

[Jeff Pyle]

If all endpoints in your SIP network supports REFER and INVITE with
Replaces correctly, all you have to do with OpenSIPS is route the SIP
messages between the endpoints for transfer to work correctly.  It's up to
the endpoints to understand what to do with the dialogs, media sessions,
etc.  In my experience this level of compatibility is rare unless you have
a completely private SIP network and control every endpoint.  I mean
phones, gateways, soft clients, everything that handles a media stream,
really.

If that is the case for you, then I would think all you need to do is
account the REFERs within the acc module.  Granted that's an initial
reaction and I haven't thought through it completely.

If you connect to the PSTN through a SIP-speaking carrier, chances are they
do not support REFER.  In this case you'll need something heavier duty in
your network than OpenSIPS, some type of a B2BUA (i.e. FreeSWTICH) that can
isolate segments of your network and handle the REFERs on behalf of the
elements that cannot.  Some may call this implementation an "SBC", although
that term is ambiguous at best.

Hopefully this helps illustrate what is and is not possible with OpenSIPS.

Attended transfer is quite involved at the SIP level.  If you want to try
it with OpenSIPS, you're going to have to get your hands dirty, so to
speak.  You'll want to check out a SIP ladder diagram[1] of what's
happening between the endpoints during such a transfer.  The good news is
that all OpenSIPS has to do is route the packets to the right place.  In
networking OSI terms, think of it as a layer 5 switch.

  [1] http://www.vocal.com/sip-2/call-transferring/   (one such diagram)


- Jeff

On Fri, Nov 27, 2015 at 5:11 AM, Aqs Younas  wrote:

> I don't thinks opensips can handle transfer. It just proxy invites and
> re-invites or may be someone more expert on mailing list can correct me.
> But you can achieve above by simply using freeswitch.
> On 26 Nov 2015 12:19, "Michele Pinassi"  wrote:
>
>> Hi all,
>>
>> i have a problem setting up a boss/secretary function with my OpenSIPS
>> router.
>>
>> Scenario:
>>
>> 5000 was the boss phone
>> 5002 was the secretary phone
>>
>> Only 5002 can call directly 5000 (the boss phone) and all call directed
>> to 5000 were diverted to 5002, that answer and decide if the call should
>> be transferred to the boss phone (5000) or not.
>>
>> Just imagine i'm 3000. And i call the 5000 (boss phone)
>>
>> 3000 ---> 5000 ---[DIVERT]---> 5002
>>
>> The secretary answer [5002] and call the boss > [5000] to ask
>> permission to forward the call. If the boss say YES, secretary TRASNFER
>> the call originated to 3000 (answered 5002) to 5000. And on OpenSIPS i
>> see the call originated from 3000 and directed to 5000, so DENIED.
>>
>> I try with brach flag, with AVP...no way, i cannot determine if a call
>> was firstly answered (and allowed) by 5002. Just for information, i'm
>> using SNOM 710/760 phones.
>>
>> Any hint/suggestions ?
>>
>> Thanks, Michele
>>
>> --
>> Michele Pinassi
>> Responsabile Telefonia di Ateneo
>> Servizio Reti, Sistemi e Sicurezza Informatica - Università degli Studi
>> di Siena
>> tel: 0577.(23)5000 - central...@unisi.it
>>
>> Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ
>> di Ateneo, http://www.faq.unisi.it
>>
>>
>>
>> ___
>> 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

[OpenSIPS-Users] OpenSIPS control panel user modify PHP error

[Jeff Pyle]

On the most recent version of the control panel, downloaded yesterday,
editing a user requires an email address to pass the PHP check and save any
changes.  Razvan saw this at the Austin training -- just documenting it
here.


- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] OpenSIPS + Ekiga + Linphone: Could not send message: Forbidden

[Jeff Pyle]

Alexander,

Your capture has two packets, a MESSAGE from Ekiga to Opensips, and a 407
Proxy Auth Required reply from Opensips to Ekiga.  When Ekiga tells
you "NOTICE: Could not send message: Unauthorised", it's correct given the
capture, but the real question is why Ekiga didn't try to use
authentication at that point.  Instead it just stopped and showed the error.

I can't speak any more to Ekiga; I've never tried it.  If you're looking
for other options, one may be Blink[1].  I've used it on Mac OSX with a lot
of success.  I've found its mailing list[2] to be active with prompt
responses from the developers.

[1] http://projects.ag-projects.com/projects/documentation/wiki/Repositories
[2] http://support.icanblink.com/


- Jeff


On Mon, Nov 2, 2015 at 7:41 PM, Alexander Shukaev <
opens...@alexander.shukaev.name> wrote:

> You are the Bo$$, Jeff.  Exactly, that was the case.  Although the data
> for the user registration was correct in Ekiga (and I also have no idea how
> the registration even passed), I decided to simply deregister and register
> again.  As a result, I can now call from Ekiga to Linphone too, but there
> is a still a problem with IM, a different one though.  Now Ekiga reports
> "NOTICE: Could not send message: Unauthorised" for IMs, and now I also
> understand why (thanks to your previous response): it does not send
> "Proxy-Authorization" anymore (see the attachment)!  I begin to think that
> Ekiga is merely bugged, though I've heard lots of positive reviews on it,
> including facts that it can be considered a mature piece of software.  So I
> still hope that this could be my misconfiguration on the OpenSIPS side and
> if anybody can point me to it, I'd be very grateful.  Otherwise, I guess I
> better off with another softphone client anyway.
>
> Kind regards,
> Alexander
>
> On 02.11.2015 21:54, Jeff Pyle wrote:
>
>> Alexander,
>>
>> First, let me say I do not use Opensips for instant message or related
>> operations.  Looking at your capture, however, I may have a thought.
>> Let's look at the headers from Ekiga's authenticated MESSAGE:
>>
>> U 2015/10/31 13:02:54.844064 192.168.2.109:5060 [1] ->
>>> 127.0.0.1:5060 [2]
>>>
>>> MESSAGE sip:5678@127.0.0.1 SIP/2.0.
>>>
>>> CSeq: 17 MESSAGE.
>>>
>>> Via: SIP/2.0/UDP
>>>
>>> 192.168.2.109:5060
>> ;branch=z9hG4bK4ef094e5-5e7e-e511-8953-0008cafa0605;rport.
>>
>>>
>>> User-Agent: Ekiga/4.0.1. [3]
>>>
>>> From: .
>>>
>>>
>>> Call-ID: 868b94e5-5e7e-e511-8953-0008cafa0605@G75VW.
>>>
>>> To: .
>>>
>>> Proxy-Authorization: Digest username="1234", realm="127.0.0.1",
>>> nonce="5634f45c000f04ee114e87bbede48ba1228797acae09",
>>> uri="sip:5678@127.0.0.1", algorithm=MD5,
>>> response="4f5373eb311376dad81cfae2e5122423".
>>>
>>> Expires: 5000.
>>>
>>> Content-Length: 2.
>>>
>>> Content-Type: text/plain;charset=UTF-8.
>>>
>>> Max-Forwards: 70.
>>>
>>
>> The From header says your Ekiga is configured with 5678, but you're
>> trying to authenticate as 1234 (Proxy-Authorization header).  I
>> believe that is why Opensips returns a 403 Forbidden Auth ID in the
>> subsequent packet.  You probably want 1234 in the From header since it
>> appears you're trying to send the message to 5678.  Perhaps this is a
>> misplaced value in Ekiga's configuration.  I'm surprised you're able
>> to completely a registration.
>>
>> Or, I could be completely wrong.  As I mentioned, I don't do IM over
>> SIP.
>>
>> - Jeff
>>
>> On Mon, Nov 2, 2015 at 2:49 PM, Alexander Shukaev
>>  wrote:
>>
>> Apologies, I don't want to look like a nasty bumper here, but I
>>> can't believe that nobody has a slightest idea how to approach the
>>> problem. I would be grateful even for a link to mailing
>>> list/forum/community where I could find help with this.
>>>
>>> Regards,
>>> Alexander
>>>
>>> On 31.10.2015 18:14, Alexander Shukaev wrote:
>>>
>>> Hello everyone,
>>>>
>>>> I'm testing a new setup of OpenSIPS. I have created two accounts
>>>> in
>>>> DB: 1234 and 5678. I run both, Ekiga and Linphone, to test
>>>> communication between these two accounts. So through Ekiga, I
>>>> register 1234 and add 5678 to contacts, while through Linphone, I
>

Re: [OpenSIPS-Users] OpenSIPS + Ekiga + Linphone: Could not send message: Forbidden

[Jeff Pyle]

Alexander,

First, let me say I do not use Opensips for instant message or related
operations.  Looking at your capture, however, I may have a thought.  Let's
look at the headers from Ekiga's authenticated MESSAGE:

U 2015/10/31 13:02:54.844064 192.168.2.109:5060 -> 127.0.0.1:5060
MESSAGE sip:5678@127.0.0.1 SIP/2.0.
CSeq: 17 MESSAGE.
Via: SIP/2.0/UDP 192.168.2.109:5060
;branch=z9hG4bK4ef094e5-5e7e-e511-8953-0008cafa0605;rport.
User-Agent: Ekiga/4.0.1.
From: .
Call-ID: 868b94e5-5e7e-e511-8953-0008cafa0605@G75VW.
To: .
Proxy-Authorization: Digest username="*1234*", realm="127.0.0.1",
nonce="5634f45c000f04ee114e87bbede48ba1228797acae09", uri="
sip:5678@127.0.0.1", algorithm=MD5,
response="4f5373eb311376dad81cfae2e5122423".
Expires: 5000.
Content-Length: 2.
Content-Type: text/plain;charset=UTF-8.
Max-Forwards: 70.


The From header says your Ekiga is configured with 5678, but you're trying
to authenticate as 1234 (Proxy-Authorization header).  I believe that is
why Opensips returns a 403 Forbidden Auth ID in the subsequent packet.  You
probably want 1234 in the From header since it appears you're trying to
send the message to 5678.  Perhaps this is a misplaced value in Ekiga's
configuration.  I'm surprised you're able to completely a registration.

Or, I could be completely wrong.  As I mentioned, I don't do IM over SIP.


- Jeff




On Mon, Nov 2, 2015 at 2:49 PM, Alexander Shukaev <
opens...@alexander.shukaev.name> wrote:

> Apologies, I don't want to look like a nasty bumper here, but I can't
> believe that nobody has a slightest idea how to approach the problem.  I
> would be grateful even for a link to mailing list/forum/community where I
> could find help with this.
>
> Regards,
> Alexander
>
>
> On 31.10.2015 18:14, Alexander Shukaev wrote:
>
>> Hello everyone,
>>
>> I'm testing a new setup of OpenSIPS.  I have created two accounts in
>> DB: 1234 and 5678.  I run both, Ekiga and Linphone, to test
>> communication between these two accounts.  So through Ekiga, I
>> register 1234 and add 5678 to contacts, while through Linphone, I
>> register 5678 and add 1234 to contacts.
>>
>> There are two problems that I experience.  First of all, within
>> Linphone I can do both, IM and call from 5678 to 1234 (Ekiga), and in
>> Ekiga I can read those IMs and accept calls accordingly, while within
>> Ekiga I can neither IM nor call from 1234 to 5678 (Linphone) as for
>> IMs I get "NOTICE: Could not send message: Forbidden" (for calls I
>> assume it's the same error, though not shown).  I attach the
>> corresponding Wireshark log.  Secondly, even though I can IM from
>> Linphone to Ekiga, the result is strange.  In particular, each IM
>> arrives twice to Ekiga.  In other words, in Linphone I see the IM
>> being typed once into chat, while in Ekiga I get two notifications for
>> each IM and that each IM appears two times in the chat.
>>
>> I'm new to OpenSIPS and VoIP in general, and I have no idea how to
>> deal with these quirks.  Any help is greatly appreciated.  Thanks in
>> advance.
>>
>> Regards,
>> Alexander
>> _
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Flexible daemon name for logging

[Jeff Pyle]

Perfect!  Thanks, Aron.


- Jeff


On Thu, Oct 1, 2015 at 1:43 PM, Podrigal, Aron 
wrote:

> Yes have a look here
> http://www.opensips.org/Documentation/Script-CoreParameters-2-1#toc64
> Hello,
>
> I will have multiple Opensips instances running on one box.  Is it
> possible to indicate the daemon name Opensips uses when logging?  Can I
> specify something other than, or in addition to, the default 'opensips' ?
>
>
> Regards,
> Jeff
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Flexible daemon name for logging

[Jeff Pyle]

Hello,

I will have multiple Opensips instances running on one box.  Is it possible
to indicate the daemon name Opensips uses when logging?  Can I specify
something other than, or in addition to, the default 'opensips' ?


Regards,
Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] OpenSIPS Data Base tables in a MySQL Cluster

[Jeff Pyle]

Short answer, yes.

I've used Opensips in a MySQL Cluster environment for years with much
success.  I did have to modify the table creation scripts to change the
type from MyISAM to NDB where appropriate.


- Jeff


On Thu, Jul 30, 2015 at 9:15 AM, Victor Medina 
wrote:

> Thanks Rik!
>
> 2015-07-30 8:10 GMT-04:30 Rik Broers :
>
>> Mysql cluster is very different from the galera solution.
>>
>>
>>
>> Mariadb offers a complete galera cluster package from their repo’s, and
>> as mariadb is going to be the default in Ubuntu we went for that J
>>
>>
>>
>> Met vriendelijke groet,
>>
>> *Rik Broers*
>> Voice Engineer
>>
>> *Van:* users-boun...@lists.opensips.org [mailto:
>> users-boun...@lists.opensips.org] *Namens *Victor Medina
>> *Verzonden:* donderdag 30 juli 2015 14:13
>> *Aan:* OpenSIPS users mailling list 
>> *Onderwerp:* Re: [OpenSIPS-Users] OpenSIPS Data Base tables in a MySQL
>> Cluster
>>
>>
>>
>> I saw the sql files and noted that they are all MyISAM. Ill guess I will
>> try MySQL Cluster and Galera.
>>
>> Any reason for going with maria db? Just your choice?
>>
>> Thanks!
>>
>>
>>
>> 2015-07-30 3:37 GMT-04:30 Rik Broers :
>>
>> I have it in a Mariadb Galera Cluster, so yeah it works.
>>
>> Make sure your DB-cluster solution is compatible with MyISAM as all sql
>> files default to that. (galera isn’t by default compatible with MyISAM)
>>
>>
>>
>> I had to change everything over to InnoDB to get it working well.
>>
>>
>>
>> Met vriendelijke groet,
>>
>> *Rik Broers*
>> Voice Engineer
>>
>> *Van:* users-boun...@lists.opensips.org [mailto:
>> users-boun...@lists.opensips.org] *Namens *Victor Medina
>> *Verzonden:* donderdag 30 juli 2015 1:05
>> *Aan:* OpenSIPS users mailling list 
>> *Onderwerp:* [OpenSIPS-Users] OpenSIPS Data Base tables in a MySQL
>> Cluster
>>
>>
>>
>> hi guys!
>>
>> is it possible to load opensips tables in a mysql cluster? Has anybody
>> tried? Any ideas?
>>
>>
>> --
>>
>>
>>
>>
>> Víctor E. Medina M.
>>
>> Platform Architect / Chief Infrastructure
>>
>> +58424 291 4561
>> BB #79A8AFA2
>> @VMCibersys
>>
>>
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>> --
>>
>>
>>
>>
>> Víctor E. Medina M.
>>
>> Platform Architect / Chief Infrastructure
>>
>> +58424 291 4561
>> BB #79A8AFA2
>> @VMCibersys
>>
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> --
>
>
>
> Víctor E. Medina M.
> Platform Architect / Chief Infrastructure
> +58424 291 4561
> BB #79A8AFA2
> @VMCibersys
>
>
> ___
> 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

[OpenSIPS-Users] OpenSIPS 2.x LTS ?

[Jeff Pyle]

Hello,

What is to be the first LTS version in the 2.x series?



- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Manually self generate failure

[Jeff Pyle]

Since the failure route is triggered by tm, I think you have to t_relay()
the request for the failure path to be taken.  Maybe you could t_relay() it
to another proxy with custom headers to indicate how you wanted it to fail,
or even t_relay() it to the same proxy with care to handle it as you see
fit.

Or, perhaps this.  Let's say you have

route[dostuff] {
stuff();
}

You could make your failure route available to the main script by writing
your failure route like this:

failure_route[failedstuff] {
route[dostuff];
}

So that way a true failure would run the same script as if you were to
manually invoke route[dostuff].

That's a lot of stuff.  Hopefully some of it fits your use case.



- Jeff


On Tue, Jun 30, 2015 at 8:14 PM, Podrigal, Aron 
wrote:

> Is there a way i can manually make a request fail so that my failure route
> would be invoked? I know this may sound weird, but i encountered some
> scenarios that this implementation came to my mind. So i want to know if
> this is possible.
>
> ___
> 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