[OpenSIPS-Users] [Livestream][ClueCon Weekly] OpenSIPS-FreeSWITCH integration discussion - Feb 21st @ 12:00 PM CST

[Liviu Chircu]

Hi all,

OpenSIPS is going to be live on the FreeSWITCH "ClueCon Weekly" 
conference tomorrow, February 21st @ 12 PM CST!


On this edition, the duty of representing the project falls on my 
shoulders. The main topic of discussion will revolve around the latest 
FreeSWITCH integration features that we've pushed into the development 
branch. So if you also use FreeSWITCH but you haven't caught up with 
them yet [1], tomorrow would be a good time to tune in and hear all 
about it. Towards the end, there will also be a Q/A section.


See you there!

Best regards,

[1]: 
https://blog.opensips.org/2018/01/17/how-to-script-advanced-freeswitch-integrations-with-opensips-2-4/


--
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com


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

[OpenSIPS-Users] Problem with simultaneous CANCEL + 200 OK

[Daniel Zanutti]

 Hey

I had a problem when receiving simultaneous CANCEL from customer and 200 OK
from gateway.

Seems that the first CANCEL was rejected, but the second CANCEL was
accepted. This second CANCEL did NOT go to the gateway, just Opensips
received and replied with 200 OK.

This is the log of the first CANCEL:
Feb 15 18:39:22 /sbin/opensips[28845]: SCRIPT:TRAFFIC:WARNING: method
CANCEL ( 7Qbq3O3CReMfPflAtl8NY3ddTqPVBHO2785126@2.2.2.2/ XAeG2xj278512T2 /
1839212581509953 ) not validated and not fixed ( code=-1 )

code -1 is the return of validate_dialog()

Second CANCEL didn't generated a log.

Shouldn't all CANCELs be rejected? On this case, just the first one was
rejected.

I'm using version 1.9.11.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] dr_is_gw parameters wrong when not using partitions

[Liviu Chircu]

Yup, it's included in 2.3.3. We'll look into the db_virtual issue asap.

Cheers,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 20.02.2018 18:23, Ben Newlin wrote:


My apologies. I tried to verify the change history for that file since 
I am not on the newest version and I didn’t see any commits after the 
one I reported. I must have been looking at it wrong. Was that commit 
included in 2.3.3?


I am currently testing the migration with 2.3.2 due to an 
incompatibility between db_virtual and avpops in 2.3.3. I have 
reported to this list already last week. So unfortunately this makes 
me stuck as I cannot use the newer version with the fix for this issue 
as it will break my DB access.


Thanks,

Ben Newlin

*From: *Users  on behalf of Liviu 
Chircu 

*Reply-To: *OpenSIPS users mailling list 
*Date: *Tuesday, February 20, 2018 at 11:04 AM
*To: *"users@lists.opensips.org" 
*Subject: *Re: [OpenSIPS-Users] dr_is_gw parameters wrong when not 
using partitions


Hi Ben,

I hope you're running off the release packages, because this 2.3 issue 
has been reported & fixed here [1], a month ago. Otherwise, we'll have 
to do some more digging.


Best regards,

[1]: https://github.com/OpenSIPS/opensips/commit/d448ab6e3599d

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 20.02.2018 17:51, Ben Newlin wrote:

Hi,

I am running into an issue migrating from 1.11 to 2.3. It appears
the dr_is_gw function is broken in 2.3.x.

When not using partitions, the function parameters are not being
translated properly before being passed to the internal function.
With this command:

dr_is_gw("$avp(src_uri)", "2", "inc", "$avp(gw_attr)");

I get the following error:

CRITICAL:core:fixup_get_svalue: bogus type 4 in gparam

ERROR:drouting:_is_dr_gw_w_part: invalid flags parameter

I believe the problem was introduced with this commit in master,
which was pulled back into 2.3:


https://github.com/OpenSIPS/opensips/commit/991b3ef4fabb4a21dd0f95ea18a5e934261be01c

This commit changed the parameters being passed through so that
the names matched what is expected, but when the partition is not
present all arguments must be shifted over by one. As far as I can
tell the logic was already correct prior to that commit.

Thanks,

Ben Newlin




___

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] dr_is_gw parameters wrong when not using partitions

[Ben Newlin]

My apologies. I tried to verify the change history for that file since I am not 
on the newest version and I didn’t see any commits after the one I reported. I 
must have been looking at it wrong. Was that commit included in 2.3.3?

I am currently testing the migration with 2.3.2 due to an incompatibility 
between db_virtual and avpops in 2.3.3. I have reported to this list already 
last week. So unfortunately this makes me stuck as I cannot use the newer 
version with the fix for this issue as it will break my DB access.

Thanks,
Ben Newlin


From: Users  on behalf of Liviu Chircu 

Reply-To: OpenSIPS users mailling list 
Date: Tuesday, February 20, 2018 at 11:04 AM
To: "users@lists.opensips.org" 
Subject: Re: [OpenSIPS-Users] dr_is_gw parameters wrong when not using 
partitions


Hi Ben,

I hope you're running off the release packages, because this 2.3 issue has been 
reported & fixed here [1], a month ago. Otherwise, we'll have to do some more 
digging.

Best regards,

[1]: 
https://github.com/OpenSIPS/opensips/commit/d448ab6e3599d

Liviu Chircu

OpenSIPS Developer

http://www.opensips-solutions.com
On 20.02.2018 17:51, Ben Newlin wrote:
Hi,

I am running into an issue migrating from 1.11 to 2.3. It appears the dr_is_gw 
function is broken in 2.3.x.

When not using partitions, the function parameters are not being translated 
properly before being passed to the internal function. With this command:

dr_is_gw("$avp(src_uri)", "2", "inc", "$avp(gw_attr)");

I get the following error:

CRITICAL:core:fixup_get_svalue: bogus type 4 in gparam
ERROR:drouting:_is_dr_gw_w_part: invalid flags parameter

I believe the problem was introduced with this commit in master, which was 
pulled back into 2.3:

https://github.com/OpenSIPS/opensips/commit/991b3ef4fabb4a21dd0f95ea18a5e934261be01c

This commit changed the parameters being passed through so that the names 
matched what is expected, but when the partition is not present all arguments 
must be shifted over by one. As far as I can tell the logic was already correct 
prior to that commit.

Thanks,
Ben Newlin








___

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] dr_is_gw parameters wrong when not using partitions

[Liviu Chircu]

Hi Ben,

I hope you're running off the release packages, because this 2.3 issue 
has been reported & fixed here [1], a month ago. Otherwise, we'll have 
to do some more digging.


Best regards,

[1]: https://github.com/OpenSIPS/opensips/commit/d448ab6e3599d

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 20.02.2018 17:51, Ben Newlin wrote:


Hi,

I am running into an issue migrating from 1.11 to 2.3. It appears the 
dr_is_gw function is broken in 2.3.x.


When not using partitions, the function parameters are not being 
translated properly before being passed to the internal function. With 
this command:


dr_is_gw("$avp(src_uri)", "2", "inc", "$avp(gw_attr)");

I get the following error:

CRITICAL:core:fixup_get_svalue: bogus type 4 in gparam

ERROR:drouting:_is_dr_gw_w_part: invalid flags parameter

I believe the problem was introduced with this commit in master, which 
was pulled back into 2.3:


https://github.com/OpenSIPS/opensips/commit/991b3ef4fabb4a21dd0f95ea18a5e934261be01c

This commit changed the parameters being passed through so that the 
names matched what is expected, but when the partition is not present 
all arguments must be shifted over by one. As far as I can tell the 
logic was already correct prior to that commit.


Thanks,

Ben Newlin



___
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] dr_is_gw parameters wrong when not using partitions

[Ben Newlin]

Hi,

I am running into an issue migrating from 1.11 to 2.3. It appears the dr_is_gw 
function is broken in 2.3.x.

When not using partitions, the function parameters are not being translated 
properly before being passed to the internal function. With this command:

dr_is_gw("$avp(src_uri)", "2", "inc", "$avp(gw_attr)");

I get the following error:

CRITICAL:core:fixup_get_svalue: bogus type 4 in gparam
ERROR:drouting:_is_dr_gw_w_part: invalid flags parameter

I believe the problem was introduced with this commit in master, which was 
pulled back into 2.3:

https://github.com/OpenSIPS/opensips/commit/991b3ef4fabb4a21dd0f95ea18a5e934261be01c

This commit changed the parameters being passed through so that the names 
matched what is expected, but when the partition is not present all arguments 
must be shifted over by one. As far as I can tell the logic was already correct 
prior to that commit.

Thanks,
Ben Newlin




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

[OpenSIPS-Users] How to avoid/solve TCP blocked connection?

[Rodrigo Pimenta Carvalho]

Hi.


My softphone is registered with the following AOR:


-

AOR:: g1r2u3p4o5
Contact:: sip:g1r2u3p4o5@127.0.0.1:50353;transport=TLS;ob Q=
Expires:: 10
Callid:: 53e387dc-81fe-45f9-a6f1-8a5cf4248d62
Cseq:: 37190
User-agent:: n/a
Received:: sip:127.0.0.1:49678;transport=TLS
State:: CS_SYNC
Flags:: 0
Cflags:: NAT
Socket:: tls:127.0.0.1:5061
Methods:: 8063
Attr:: in_same_network
SIP_instance:: 
-


Sometimes, when it receives a call and answers, the Opensips show the following 
error:


[21532] INFO:core:probe_max_sock_buff: using snd buffer of 320 kb
[21532] INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 22
[21532] ERROR:core:tcp_connect_blocking: poll error: flags 28 - 4 8 16 32
[21532] ERROR:core:tcp_connect_blocking: failed to retrieve SO_ERROR 
[server=127.0.0.1:50353] (111) Connection refused
[21532] ERROR:proto_tls:tls_sync_connect: tcp_blocking_connect failed
[21532] ERROR:proto_tls:proto_tls_send: connect failed
[21532] ERROR:core:msg_send: send() for proto 3 failed

Is there a way to avoid this kind of problem? That is, can I configure the 
OpenSIPS to renew some TCP connection?

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] How to avoid UDP usage in load_balancer module

[Răzvan Crainea]

Hi, Mirko!

Your solution works too, you can stick with it, it basically has the 
same effect.


Best regards,
Răzvan

On 02/20/2018 02:55 PM, Mirko Csiky wrote:

Hi Razvan,
in the meantime (yesterday), the problem was solved by using :
force_send_socket(tcp:192.168.12.175);
before t_relay()
In my database (i have 3 rows in load_balancer table only) it is so:
sip\:192.168.15.92
(\ as escape character for ":" DBTEXT syntax)
so, i think, it doesnt provide the transport parameter.
Thanks for hack idea ! It looks as better solution than mine: should i 
use it ? (or stay with force_send_socket(tcp ?)

best regards
Mirko




On Tue, Feb 20, 2018 at 9:07 AM, Răzvan Crainea > wrote:


Hi, Mirko!

If you provision a UDP URI in the database, then the outgoing INVITE
will be sent as UDP.
If you want to preserve the protocol, regardless the URI's protocol,
you'll have to explicitely hack it in the script by altering the
destination URI, something like:

if ($rP == "TCP")
     $du = $du + ";transport=tcp";

Note that this hack presumes that the URIs in your database are
always provisioned without a transport parameter;

Hope this helps.

Best regards,
Răzvan


On 02/19/2018 02:32 PM, Mirko Csiky wrote:

Hi guys,
i am playing with opensips and load balancer module, and it
seems like inital TCP invites will be forwarded (opensips relay
after load_balance(...) ) as UDP ? Can this behaviour be
deactivated ? (i tried to find some configuration options, but
without success)
It is also possible that my config is not ok and it is so
because of misconfiguration ...
Can anybody help me here ?
best regards
Mirko


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



-- 
Răzvan Crainea

OpenSIPS Core Developer
http://www.opensips-solutions.com 
OpenSIPS Summit 2018
http://www.opensips.org/events/Summit-2018Amsterdam


___
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



--
Răzvan Crainea
OpenSIPS Core Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

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

Re: [OpenSIPS-Users] How to avoid UDP usage in load_balancer module

[Mirko Csiky]

Hi Razvan,
in the meantime (yesterday), the problem was solved by using :
force_send_socket(tcp:192.168.12.175);
before t_relay()
In my database (i have 3 rows in load_balancer table only) it is so:
sip\:192.168.15.92
(\ as escape character for ":" DBTEXT syntax)
so, i think, it doesnt provide the transport parameter.
Thanks for hack idea ! It looks as better solution than mine: should i use
it ? (or stay with force_send_socket(tcp ?)
best regards
Mirko




On Tue, Feb 20, 2018 at 9:07 AM, Răzvan Crainea  wrote:

> Hi, Mirko!
>
> If you provision a UDP URI in the database, then the outgoing INVITE will
> be sent as UDP.
> If you want to preserve the protocol, regardless the URI's protocol,
> you'll have to explicitely hack it in the script by altering the
> destination URI, something like:
>
> if ($rP == "TCP")
> $du = $du + ";transport=tcp";
>
> Note that this hack presumes that the URIs in your database are always
> provisioned without a transport parameter;
>
> Hope this helps.
>
> Best regards,
> Răzvan
>
>
> On 02/19/2018 02:32 PM, Mirko Csiky wrote:
>
>> Hi guys,
>> i am playing with opensips and load balancer module, and it seems like
>> inital TCP invites will be forwarded (opensips relay after
>> load_balance(...) ) as UDP ? Can this behaviour be deactivated ? (i tried
>> to find some configuration options, but without success)
>> It is also possible that my config is not ok and it is so because of
>> misconfiguration ...
>> Can anybody help me here ?
>> best regards
>> Mirko
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
> --
> Răzvan Crainea
> OpenSIPS Core Developer
>   http://www.opensips-solutions.com
> OpenSIPS Summit 2018
>   http://www.opensips.org/events/Summit-2018Amsterdam
>
> ___
> 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] history-Info header manipulation

[xaled]

Hi Bogdan,

 

Mostly yes - single HI Header with multiple hi-entries. 

A general solution/advice that would work with both single and multiple HI
headers would be much appreciated. 

 

Thanks,

Xaled

 

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org] 
Sent: Tuesday, February 20, 2018 1:15 PM
To: OpenSIPS users mailling list ; xaled

Subject: Re: [OpenSIPS-Users] history-Info header manipulation

 

Hi Xaled,

You mean if a single History header contains multiple hi-entry instances ?

Regards,



Bogdan-Andrei Iancu
 
OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

On 02/19/2018 02:39 PM, xaled wrote:

Hi,

 

Is there any other/better way for the history-Info header manipulation like
adding or removing a hi-entry except subst? 

 

Thanks,

xaled






___
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] history-Info header manipulation

[Bogdan-Andrei Iancu]

Hi Xaled,

You mean if a single History header contains multiple hi-entry instances ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

On 02/19/2018 02:39 PM, xaled wrote:


Hi,

Is there any other/better way for the history-Info header manipulation 
like adding or removing a hi-entry except subst?


Thanks,

xaled



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

[Liviu Chircu]

Hi, volga!

Can you send a SIP trace of this failed call to my mailbox? It's one of 
those "it's working for me" situations. The mid_reg_lookup() should be 
smart enough to locate a contact based on its unique ContactID, when the 
call comes in from FS.


Regarding regid: it's completely gone now (even in 2.3), thanks for the 
heads up: I'll clean up the docs asap!


Cheers,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 19.02.2018 22:51, volga...@networklab.ca wrote:

Hello Everyone,
I am back to test mid registrar and having issue with


modparam("mid_registrar", "contact_match_param", "regid")
I so comment this parmater is obsolote what correct way to set it, 
because opensips reject calls with 404 on location lookup. I see that 
contact header is replaced with CallerID and when freeswitch send 
reply it can't locate the cantact.

Original contact
root@casbc00 ~> [/etc/opensips]# opensipsctl ul show
Domain:: location table=512 records=2
AOR:: 4300
    Contact:: sip:4300@192.168.89.227:34846;transport=tcp Q=
    ContactID:: 1205768431484279123
    Expires:: 1478
    Callid:: 567846761-2141...@bjc.bgi.ij.cch
    Cseq:: 2027
    User-agent:: Grandstream GXP2140 1.0.8.47
    State:: CS_NEW
    Flags:: 0
    Cflags::
    Socket:: tcp:158.69.151.95:5082
    Methods:: 6015

Feb 19 15:45:20 casbc00 /usr/sbin/opensips[2049]: looking up 
[sip:1205768431484279123@10.18.130.27:5060]
Feb 19 15:45:20 casbc00 /usr/sbin/opensips[2049]: 
ERROR:mid_registrar:mid_reg_lookup: no record found for 
sip:1205768431484279123@10.18.130.27:5060, ci: 
a413e68c-9058-1236-7e9c-5254003e39bb

Github report https://github.com/OpenSIPS/opensips/issues/


___
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 avoid UDP usage in load_balancer module

[Răzvan Crainea]

Hi, Mirko!

If you provision a UDP URI in the database, then the outgoing INVITE 
will be sent as UDP.
If you want to preserve the protocol, regardless the URI's protocol, 
you'll have to explicitely hack it in the script by altering the 
destination URI, something like:


if ($rP == "TCP")
$du = $du + ";transport=tcp";

Note that this hack presumes that the URIs in your database are always 
provisioned without a transport parameter;


Hope this helps.

Best regards,
Răzvan

On 02/19/2018 02:32 PM, Mirko Csiky wrote:

Hi guys,
i am playing with opensips and load balancer module, and it seems like 
inital TCP invites will be forwarded (opensips relay after 
load_balance(...) ) as UDP ? Can this behaviour be deactivated ? (i 
tried to find some configuration options, but without success)
It is also possible that my config is not ok and it is so because of 
misconfiguration ...

Can anybody help me here ?
best regards
Mirko


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



--
Răzvan Crainea
OpenSIPS Core Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

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