date:20170207

Re: [OpenSIPS-Users] Opensips backup

2017-02-07 Thread Johan De Clercq

as long as your sql instances are in perfect sync and if you use dialogs
with db in realtime, it should work.
I think however that it is much better to share an instance of mysql
instead of using one for each opensips with replication .

2017-02-08 7:55 GMT+01:00 Denis via Users :

> Hello!
>
> There is one consulting question.
>
> If i have a two instance of the Opensips which are working with
> active/standby mode and there is mysql replication between two instance.
>
> Suppose standby Opensips will run permanently because listen parameter
> will be, for example, udp:eth1:5060.
>
> So, the question is, if active Opensips will fail, will standby Opensips
> be handle dialogs properly which have been initiated on active one early?
>
> Thank you.
>
> --
> С уважением, Денис.
> Best regards, Denis
>
>
>
>
> ___
> 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 backup

2017-02-07 Thread Denis via Users

Hello! There is one consulting question. If i have a two instance of the Opensips which are working with active/standby mode and there is mysql replication between two instance. Suppose standby Opensips will run permanently because listen parameter will be, for example, udp:eth1:5060. So, the question is, if active Opensips will fail, will standby Opensips be handle dialogs properly which have been initiated on active one early? Thank you. -- С уважением, Денис.Best regards, Denis   

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

Re: [OpenSIPS-Users] ds_select_dst with algorithm 6 is not using the last destination

2017-02-07 Thread Pat Burke

Thanks to Liviu we got the issue resolve.

There were really two things.


1) I had read the flags parameter as being Uppercase = set and Lowercase = 
unset.  The flags are case insensitive.  I was trying to have flags "f" and "s" 
set and "u" and "d" unset, so I needed to use a value of "fs" instead of "FuSd".


2) When setting the default flag "d", the last destination is not being hit (at 
least not as a first value in the AVP - I didn't check to see if there were 
multiple values).  If I use the value of "fs" the system works as I was 
wanting, but with "fsd", it skips the last one.


Thanks again Liviu.

Regards,
Pat Burke



__
Direct: (402) 403-5121   |   Cell: (402) 443-8929  |   Email: 
p...@voxtelesys.com
1801 23rd Avenue North   |  Suite 217    |  Fargo, North Dakota 58102


-Original Message-
From: "Pat Burke" 
To: users@lists.opensips.org
Date: 02/06/17 23:21
Subject: ds_select_dst with algorithm 6 is not using the last destination


Hello,


It appears that 2.2.2 ds_select_dst with the parameters that I have below is 
not using the last destination in the set.  


...
if (!ds_select_dst("$avp(core_server_group)","6","FuSd")) {
...


Here is the results from ds_list full.


(with 2 destinations in the set)
PARTITION:: default
SET:: 10005
URI:: sip:216.147.191.143:5060 state=Active first_hit_counter=16
weight:: 1
priority:: 0
description:: DEV Ingress-DEV Core
URI:: sip:216.147.191.144:5060 state=Active first_hit_counter=0
weight:: 1
priority:: 0
description:: DEV Ingress-DEV Core
SET:: 10002




(with 3 destinations in the set)
PARTITION:: default
SET:: 10005
URI:: sip:216.147.191.143:5060 state=Active first_hit_counter=13
weight:: 1
priority:: 0
description:: DEV Ingress-DEV Core
URI:: sip:216.147.191.144:5060 state=Active first_hit_counter=15
weight:: 1
priority:: 0
description:: DEV Ingress-DEV Core
URI:: sip:216.147.191.142:5060 state=Active first_hit_counter=0
weight:: 1
priority:: 0
description:: DEV Ingress-DEV Core
SET:: 10002








What I am after is the functionality that I had in 1.11 which was a random use 
of all destinations in the set.  I had the following setting




modparam("dispatcher", "force_dst", 1)
modparam("dispatcher", "flags", 2)


and called using


...
    if (!ds_select_dst("$avp(core_server_group)","6")) {
...



Regards,
Pat Burke



__
Direct: (402) 403-5121   |   Cell: (402) 443-8929  |   Email: 
p...@voxtelesys.com
1801 23rd Avenue North   |  Suite 217    |  Fargo, North Dakota 58102


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

Re: [OpenSIPS-Users] limit of using $acc_extra() variables

2017-02-07 Thread Marco Hierl

Dear all,

there seems to be a limit of using $acc_extra() variables.

I'm using the ACC module to log accounting data into a file and it's working 
fine even with logging of extra_fields.
But when I come to the point that I used $acc_extra variables more often 
(around 45 times) in the config file, I get "not enough free pkg memory" during 
the OpenSIPS start.

Ok, so I set start option -M from 8 to 128... but the fault did not change.


Maybe this part of my config file can explain it better. It is running fine as 
long as I don't remove one of the "#"-signs below:

modparam("acc", "extra_fields", "log: switch; internal_ci; related_inc_cdrs; 
time; us; si; inroute; outroute; bno_in; bno_out; snr; ziel; tu; anum; fu; 
diverting_no; cpc; privacy; ua; received; p-germany-tariff; switch_dur; init; 
eos")

route{
...
   do_accounting("log", "missed|failed", "");

   $acc_extra(switch)="sitename";   ..(and couple of 
assignments/po's more) ...
   $acc_extra(si)="si";
   $acc_extra(ua)="ua";
xlog("L_DBG","+++ $acc_extra(ua)");

   #$acc_extra(ua)="ua";
   #$acc_extra(received)="yes";
   #xlog("L_DBG","+++ $acc_extra(ua)");

...
}

If I remove any of the "#" above I get:

Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Not starting opensips: invalid 
configuration file!
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: -e
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
INFO:core:tr_parse_re: preparing to parse param
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
INFO:cfgutils:shvar_init_locks: locks array size 16
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
INFO:core:tr_parse_re: preparing to parse param
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
INFO:core:tr_parse_re: preparing to parse param
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
INFO:core:tr_parse_re: preparing to parse param
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
INFO:core:tr_parse_re: preparing to parse param
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
INFO:core:fix_poll_method: using epoll_lt as the IO watch method (auto detected)
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:qm_malloc: not enough free pkg memory (64 bytes left), please 
increase the "-M" command line parameter!
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:new_sock_info: pkg memory allocation error
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:new_sock2list: new_sock_info failed
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:add_interfaces: new_sock2list failed
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:qm_malloc: not enough free pkg memory (64 bytes left), please 
increase the "-M" command line parameter!
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:new_sock_info: pkg memory allocation error
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:new_sock2list: new_sock_info failed
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:add_interfaces: new_sock2list failed
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:fix_socket_list: could not resolve eth0
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:fix_all_socket_lists: fix_socket_list for 1 failed
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:main: failed to initialize list addresses
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
NOTICE:core:main: Exiting

This is for OpenSIPS 2.2 & 2.3, running on
Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 
GNU/Linux



Thanks for your help
  Marco

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

[OpenSIPS-Users] Handling various CANCEL scenarios

2017-02-07 Thread Andreas Bøckmann

Hello everybody

How can I separate different Reason headers to achieve a setup where
NO_ANSWER (480) ends the dialog (and sends CANCELs) while other reasons
like e.g. TM timeout leads to routing the requests to GW?

Could this be handled in the failure route as something like below or am I
way off here?

  if (t_check_status("480")) {
 t_relay();
 exit;
  }

  if (t_check_status("487")) {
 t_relay();
 exit;
  }

  if (t_check_status("404")) {
 route_to_gw("gwname");
 t_on_failure("gwfailure");
  }

Thanks!

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

Re: [OpenSIPS-Users] SIP message relay order

2017-02-07 Thread Stas Kobzar

Hi,

I also was thinking about usleep as in Nick's solution.

My OpenSIPS version is 1.11 and async, AFAIK, is available starting with
version 2.1, isn't it?

Thanks,

On Tue, Feb 7, 2017 at 7:35 AM, Bogdan-Andrei Iancu 
wrote:

> Hi Nick,
>
> It is risky to do a sync sleep as you keep the process blocked, so the
> ability of OpenSIPS to handle new messages will decrease .
>
> Either do async sleep, either simple drop it to force a retransmissions in
> 500ms - much simpler :)
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 02/07/2017 12:22 PM, Nick Altmann wrote:
>
> The easies way we use in such cases is:
> if (is_method("INVITE")) usleep("500");
> for in-dialog INVITEs (inside loose_route() / match_dialog() section).
>
> It will delay slightly all reINVITES, but also will guarantee correct
> order of packets.
>
> 2017-02-06 22:46 GMT+03:00 Stas Kobzar :
>
>> Hello Bogdan,
>>
>> In my case, ACK for previous INVITE has already been received by
>> OpenSIPS, but not sent yet.
>> In this case, will the variable $DLG_status still equals 3 ?
>>
>> Thanks
>>
>> On Sun, Feb 5, 2017 at 11:15 AM, Bogdan-Andrei Iancu > > wrote:
>>
>>> Hi Stas,
>>>
>>> Such races may happen at application level or even at network level
>>> (when using UDP) - so if you have 2 packets very close as time, they may
>>> swap. That is SIP :)
>>>
>>> The full guilt is in the UAC device, IMHO - it should let some time gap
>>> between the ACK and re-INVITE, to eliminate any possible races.
>>>
>>> Now, what you can do is to use the dialog module and to check the dialog
>>> state when receiving the re-invite. If $DLG_status is *3* (Confirmed by
>>> a final reply but no ACK received yet), drop with no reply the re-INVITEs
>>> (to force a later retransmission) :
>>> http://www.opensips.org/html/docs/modules/2.2.x/dialog.html#id297400
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>
>>> On 02/02/2017 10:31 PM, Stas Kobzar wrote:
>>>
>>> Hello List,
>>> My call flow has initial INVITE and re-INVITE to update RTP IP/port.
>>> Usually everything works well, but sometimes OpenSIPS come up with
>>> following example:
>>> UA OpenSIPS  PSTN GW
>>> ---
>>> INV(CSeq: 100) -> | ---> INV(CSeq: 100)
>>> < 200 OK  | <--- 200 OK
>>> (UA sends ACK then new INVITE)
>>> ACK(CSeq: 100) -> |
>>> reINV(Cseq: 101) ---> |
>>> (OpenSIPS relays first INVITE then ACK)
>>>   | ---> reINV(CSeq: 101)
>>>   | --->   ACK(CSeq: 100)
>>> When PSTN gateway receives re-INVITE before ACK for previous INVITE
>>> it responds 500 with Retry-After header.
>>> This is correct behaviour which conforms to the RFC 3261 section 14.2
>>> My question is:
>>> Is it possible to assure order of received and relayed messages within
>>> the same SIP session? Is there any configuration parameter?
>>>
>>> Thank you,
>>> --
>>>
>>> Stas Kobzar
>>>
>>> Developeur VoIP / VoIP Developer
>>>
>>> Modulis.ca Inc.
>>>
>>> # Bureau / Office: 514-284-2020 x 246 <%28514%29%20284-2020>
>>>
>>> Email: s tas.kob...@modulis.ca
>>>
>>> https://www.modulis.com
>>>
>>> ___
>>> Users mailing 
>>> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>> --
>>
>> Stas Kobzar
>>
>> Developeur VoIP / VoIP Developer
>>
>> Modulis.ca Inc.
>>
>> # Bureau / Office: 514-284-2020 x 246 <(514)%20284-2020>
>>
>> Email: s tas.kob...@modulis.ca
>>
>> https://www.modulis.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
>
>


-- 

Stas Kobzar

Developeur VoIP / VoIP Developer


Modulis.ca Inc.

# Bureau / Office: 514-284-2020 x 246

Email: s tas.kob...@modulis.ca

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

Re: [OpenSIPS-Users] Change 200 OK of BYE message

2017-02-07 Thread Daniel Zanutti

Hi

No, i didn't set it. After set the onreply, it worked fine. I didn't know
that the BYE is a new request internally.

Thanks Bogdan

On Tue, Feb 7, 2017 at 10:37 AM, Bogdan-Andrei Iancu 
wrote:

> Hi,
>
> As the 200OK belongs to the BYE request, are you sure you arm the onreply
> route when handling the _BYE_ request ?
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 02/07/2017 01:48 PM, Daniel Zanutti wrote:
>
> The sip client is working fine, I can confirm that both BYE and 200 OK are
> flowing through the proxy, the problem is I cannot modify the 200 OK
> message.
>
> I need to modify a header on the 200 OK of the BYE but I cannot since the
> message doesn't pass to internal on_reply_route or main Route inside
> Opensips. It's being routed internally by Opensips directly to the
> destination.
>
> Do you have any idea?
>
> On Tue, Feb 7, 2017 at 5:40 AM, Johan De Clercq  wrote:
>
>> Any chance to have a small capture ?
>> I tend to agree with Robert, if you use rr consistently there should be
>> no problem. It can of course also be that the client does something strange
>> ...
>>
>> 2017-02-06 21:43 GMT+01:00 Daniel Zanutti < 
>> daniel.zanu...@gmail.com>:
>>
>>> Hi Robert
>>>
>>> Yes, all messages are passing through the proxy, but when I receive the
>>> 200 OK of the BYE message, it doesn't go to Main Route or Reply Route. It
>>> just go to the destination and I cannot change anything on it.
>>>
>>> Any idea?
>>>
>>>
>>>
>>> On Mon, Feb 6, 2017 at 6:14 PM, Mundkowsky, Robert <
>>> rmundkow...@ets.org> wrote:
>>>
 Did you use “record_route”?



 For reference:

 http://www.iptel.org/sip/intro/scenarios/rr





 Robert Mundkowsky



 *From:* Users [mailto: 
 users-boun...@lists.opensips.org] *On Behalf Of *Daniel Zanutti
 *Sent:* Monday, February 6, 2017 3:01 PM
 *To:* OpenSIPS users mailling list 
 *Subject:* [OpenSIPS-Users] Change 200 OK of BYE message



 Hi



 I need to change something on the 200 OK of BYE message. Tried
 everything on Opensips but looks like this message doesn't follow standard
 message path. Neither Main Route or Reply route pass this message.



 Is there any way to do it?



 Thanks

 --

 This e-mail and any files transmitted with it may contain privileged or
 confidential information. It is solely for use by the individual for whom
 it is intended, even if addressed incorrectly. If you received this e-mail
 in error, please notify the sender; do not disclose, copy, distribute, or
 take any action in reliance on the contents of this information; and delete
 it from your system. Any other use of this e-mail is prohibited.

 Thank you for your compliance.
 --

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

Re: [OpenSIPS-Users] Change 200 OK of BYE message

2017-02-07 Thread Bogdan-Andrei Iancu

Hi,

As the 200OK belongs to the BYE request, are you sure you arm the 
onreply route when handling the _BYE_ request ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 02/07/2017 01:48 PM, Daniel Zanutti wrote:
The sip client is working fine, I can confirm that both BYE and 200 OK 
are flowing through the proxy, the problem is I cannot modify the 200 
OK message.

I need to modify a header on the 200 OK of the BYE but I cannot since 
the message doesn't pass to internal on_reply_route or main Route 
inside Opensips. It's being routed internally by Opensips directly to 
the destination.

Do you have any idea?

On Tue, Feb 7, 2017 at 5:40 AM, Johan De Clercq > wrote:

Any chance to have a small capture ?
I tend to agree with Robert, if you use rr consistently there
should be no problem. It can of course also be that the client
does something strange ...

2017-02-06 21:43 GMT+01:00 Daniel Zanutti
>:

Hi Robert

Yes, all messages are passing through the proxy, but when I
receive the 200 OK of the BYE message, it doesn't go to Main
Route or Reply Route. It just go to the destination and I
cannot change anything on it.

Any idea?

On Mon, Feb 6, 2017 at 6:14 PM, Mundkowsky, Robert
> wrote:

Did you use “record_route”?

For reference:

http://www.iptel.org/sip/intro/scenarios/rr

Robert Mundkowsky

*From:*Users [mailto:users-boun...@lists.opensips.org
] *On Behalf Of
*Daniel Zanutti
*Sent:* Monday, February 6, 2017 3:01 PM
*To:* OpenSIPS users mailling list
>
*Subject:* [OpenSIPS-Users] Change 200 OK of BYE message

Hi

I need to change something on the 200 OK of BYE message.
Tried everything on Opensips but looks like this message
doesn't follow standard message path. Neither Main Route
or Reply route pass this message.

Is there any way to do it?

Thanks

This e-mail and any files transmitted with it may contain
privileged or confidential information. It is solely for
use by the individual for whom it is intended, even if
addressed incorrectly. If you received this e-mail in
error, please notify the sender; do not disclose, copy,
distribute, or take any action in reliance on the contents
of this information; and delete it from your system. Any
other use of this e-mail is prohibited.

Thank you for your compliance.

___
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

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

Re: [OpenSIPS-Users] SIP message relay order

2017-02-07 Thread Bogdan-Andrei Iancu


Hi Nick,

It is risky to do a sync sleep as you keep the process blocked, so the 
ability of OpenSIPS to handle new messages will decrease .


Either do async sleep, either simple drop it to force a retransmissions 
in 500ms - much simpler :)


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 02/07/2017 12:22 PM, Nick Altmann wrote:

The easies way we use in such cases is:
if (is_method("INVITE")) usleep("500");
for in-dialog INVITEs (inside loose_route() / match_dialog() section).

It will delay slightly all reINVITES, but also will guarantee correct 
order of packets.


2017-02-06 22:46 GMT+03:00 Stas Kobzar >:


Hello Bogdan,

In my case, ACK for previous INVITE has already been received by
OpenSIPS, but not sent yet.
In this case, will the variable $DLG_status still equals 3 ?

Thanks

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

Hi Stas,

Such races may happen at application level or even at network
level (when using UDP) - so if you have 2 packets very close
as time, they may swap. That is SIP :)

The full guilt is in the UAC device, IMHO - it should let some
time gap between the ACK and re-INVITE, to eliminate any
possible races.

Now, what you can do is to use the dialog module and to check
the dialog state when receiving the re-invite. If $DLG_status
is /3/ (Confirmed by a final reply but no ACK received yet),
drop with no reply the re-INVITEs (to force a later
retransmission) :
http://www.opensips.org/html/docs/modules/2.2.x/dialog.html#id297400


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 02/02/2017 10:31 PM, Stas Kobzar wrote:

Hello List,
My call flow has initial INVITE and re-INVITE to update RTP
IP/port.
Usually everything works well, but sometimes OpenSIPS come up
with following example:
UA OpenSIPS  PSTN GW
---
INV(CSeq: 100) -> | ---> INV(CSeq: 100)
< 200 OK  | <--- 200 OK
(UA sends ACK then new INVITE)
ACK(CSeq: 100) -> |
reINV(Cseq: 101) ---> |
(OpenSIPS relays first INVITE then ACK)
  | ---> reINV(CSeq: 101)
  | --->   ACK(CSeq: 100)
When PSTN gateway receives re-INVITE before ACK for previous
INVITE
it responds 500 with Retry-After header.
This is correct behaviour which conforms to the RFC 3261
section 14.2
My question is:
Is it possible to assure order of received and relayed
messages within the same SIP session? Is there any
configuration parameter?
Thank you,
-- 


Stas Kobzar

Developeur VoIP / VoIP Developer

Modulis.ca Inc.

# Bureau / Office: 514-284-2020 x 246 

Email: s tas.kob...@modulis.ca

https://www.modulis.com 

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



-- 


Stas Kobzar

Developeur VoIP / VoIP Developer

Modulis.ca Inc.

# Bureau / Office: 514-284-2020 x 246

Email: s tas.kob...@modulis.ca

https://www.modulis.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] rtpengine xmlrpc integration with opensips. Teardown xmlrpc method

2017-02-07 Thread Carlos Oliva

Hi Adrian:

You're right. Sorry for the word "abandoned" is not the right word. As you
say it works, and works very well.

I was trying to say "no new features" I think mediaproxy is a very good
project, stable and fast, but needs to be a bit more active if don't want
to stay behind. New technologies like WS are coming very fast.

Thanks to you and AG-Projects team for this good software

Thanks and regards,

Carlos Oliva
















* _ Carlos
OlivaDepartamento de Sistemas C/ Pujades, 77-79, 8a Planta 9B | 08005
Barcelona www.numintec.com  |
carlos.ol...@numintec.com  | T: 902 02 02 97
_ Talking Numintec:
Dialogando con empresarios de éxito 
 Las soluciones en la nube de
Numintec - Casos de éxito 
 Solicita una demo

_ Medio Ambiente: Antes de
imprimir este mensaje, asegúrese de que es necesario. Nota Legal: La
información contenida en la presente transmisión es confidencial y su uso
únicamente está permitido a su(s) destinatario(s). Le informamos que los
datos personales que facilite/ha facilitado pasarán/han pasado a formar
parte de un fichero responsabilidad de NUMINTEC COMUNICACIONES S.L.. y que
tiene por finalidad gestionar las relaciones. Tiene la posibilidad de
ejercitar los derechos de acceso, rectificación, cancelación y oposición
respecto a sus datos ante la empresa, en el e-mail
comunicac...@numintec.com   o bien en el
 domicilio sito en C/ Pujades, 77-79 8ª Planta 9-B 08005 de Barcelona.*

2017-02-06 12:39 GMT+01:00 Adrian Georgescu :

>
> On 29 Jan 2017, at 23:05, Carlos Oliva  wrote:
>
> Hi List!
>
> I'm using Opensips 1.11 and doing some tests to change my mediaproxy
> rtprelays to ngcp-rtpengine. My reasons to try this change are efficiency
> and that the mediaproxy project seems to be a little abandoned by
> AGProjects (not really abandoned but has no new features in years)
>
>
> Well, it is not abandoned. It just works. So there is nothing to fix,
> hence little activity about it.
>
> Adrian
>
>
> After the change I started to see some dialogs in state 3 that ends at
> timeout (6 hours in my config)
>
> I tried to use the RTPTimeout function in rtpengine (in mediaproxy  it
> works very well) to try to end the dialogs which don't have RTP.
>
> To try this I used the rtpengine flags --b2b-url=http://%%:8000/RPC2
> --xmlrpc-format=1 to send Opensips the order to end the related dialog.
>
> It doesn't work. Doing some ngrep at xmlrpc interface seems that rtpengine
> send some commands to opensips RPC interface that Opensips does not
> understand. The command is: "teardown" and the callid, here is an example:
>
> POST /RPC2 HTTP/1.1..Host: XXX.XXX.XXX.XXX:8000..Accept:
> */*..Content-Type: text/xml..User-Agent: Xmlrpc-c/1.33.14 
> Curl/7.38.0..Content-Length:
> 204   ding="UTF-8"?>teardown methodName>822048991-
> 4075...@bjc.bgi.b.ge
>
> and the opensips response:
>
> HTTP/1.1 200 OK..Connection: Keep-Alive..Content-Length: 48..Content-Type:
> text/xml; charset=utf-8..Date: Sun, 29 Jan 2017 20:31:36
> GMTInternal server error!
>
> Obviously OpenSips does not implement this "teardown" method.
>
> My questions are:
>
> Anybody has a good idea of how to deal with this?
>
> Devels: Do you think is a good idea to open a feature request in github
> about this? I'll try to backport to 1.11 later.if you accept the request.
>
>
> Thanks and Regards,
>
> Carlos Oliva
>
> ___
> 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] Change 200 OK of BYE message

2017-02-07 Thread Daniel Zanutti

The sip client is working fine, I can confirm that both BYE and 200 OK are
flowing through the proxy, the problem is I cannot modify the 200 OK
message.

I need to modify a header on the 200 OK of the BYE but I cannot since the
message doesn't pass to internal on_reply_route or main Route inside
Opensips. It's being routed internally by Opensips directly to the
destination.

Do you have any idea?

On Tue, Feb 7, 2017 at 5:40 AM, Johan De Clercq  wrote:

> Any chance to have a small capture ?
> I tend to agree with Robert, if you use rr consistently there should be no
> problem. It can of course also be that the client does something strange
> ...
>
> 2017-02-06 21:43 GMT+01:00 Daniel Zanutti :
>
>> Hi Robert
>>
>> Yes, all messages are passing through the proxy, but when I receive the
>> 200 OK of the BYE message, it doesn't go to Main Route or Reply Route. It
>> just go to the destination and I cannot change anything on it.
>>
>> Any idea?
>>
>>
>>
>> On Mon, Feb 6, 2017 at 6:14 PM, Mundkowsky, Robert 
>> wrote:
>>
>>> Did you use “record_route”?
>>>
>>>
>>>
>>> For reference:
>>>
>>> http://www.iptel.org/sip/intro/scenarios/rr
>>>
>>>
>>>
>>>
>>>
>>> Robert Mundkowsky
>>>
>>>
>>>
>>> *From:* Users [mailto:users-boun...@lists.opensips.org] *On Behalf Of 
>>> *Daniel
>>> Zanutti
>>> *Sent:* Monday, February 6, 2017 3:01 PM
>>> *To:* OpenSIPS users mailling list 
>>> *Subject:* [OpenSIPS-Users] Change 200 OK of BYE message
>>>
>>>
>>>
>>> Hi
>>>
>>>
>>>
>>> I need to change something on the 200 OK of BYE message. Tried
>>> everything on Opensips but looks like this message doesn't follow standard
>>> message path. Neither Main Route or Reply route pass this message.
>>>
>>>
>>>
>>> Is there any way to do it?
>>>
>>>
>>>
>>> Thanks
>>>
>>> --
>>>
>>> This e-mail and any files transmitted with it may contain privileged or
>>> confidential information. It is solely for use by the individual for whom
>>> it is intended, even if addressed incorrectly. If you received this e-mail
>>> in error, please notify the sender; do not disclose, copy, distribute, or
>>> take any action in reliance on the contents of this information; and delete
>>> it from your system. Any other use of this e-mail is prohibited.
>>>
>>> Thank you for your compliance.
>>> --
>>>
>>> ___
>>> 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

[OpenSIPS-Users] limit of using $acc_extra() variables

2017-02-07 Thread Marco Hierl

Dear all,

there seems to be a limit of using $acc_extra() variables.

I'm using the ACC module to log accounting data into a file and it's working 
fine even with logging of extra_fields.
But when I come to the point that I used $acc_extra variables more often 
(around 45 times) in the config file, I get "not enough free pkg memory" during 
the OpenSIPS start.

Ok, so I set start option -M from 8 to 128... but the fault did not change.


Maybe this part of my config file can explain it better. It is running fine as 
long as I don't remove one of the "#"-signs below:

modparam("acc", "extra_fields", "log: switch; internal_ci; related_inc_cdrs; 
time; us; si; inroute; outroute; bno_in; bno_out; snr; ziel; tu; anum; fu; 
diverting_no; cpc; privacy; ua; received; p-germany-tariff; switch_dur; init; 
eos")

route{
...
   do_accounting("log", "missed|failed", "");

   $acc_extra(switch)="sitename";   ..(and couple of 
assignments/po's more) ...
   $acc_extra(si)="si";
   $acc_extra(ua)="ua";
xlog("L_DBG","+++ $acc_extra(ua)");

   #$acc_extra(ua)="ua";
   #$acc_extra(received)="yes";
   #xlog("L_DBG","+++ $acc_extra(ua)");

...
}

If I remove any of the "#" above I get:

Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Not starting opensips: invalid 
configuration file!
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: -e
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
INFO:core:tr_parse_re: preparing to parse param
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
INFO:cfgutils:shvar_init_locks: locks array size 16
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
INFO:core:tr_parse_re: preparing to parse param
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
INFO:core:tr_parse_re: preparing to parse param
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
INFO:core:tr_parse_re: preparing to parse param
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
INFO:core:tr_parse_re: preparing to parse param
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
INFO:core:fix_poll_method: using epoll_lt as the IO watch method (auto detected)
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:qm_malloc: not enough free pkg memory (64 bytes left), please 
increase the "-M" command line parameter!
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:new_sock_info: pkg memory allocation error
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:new_sock2list: new_sock_info failed
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:add_interfaces: new_sock2list failed
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:qm_malloc: not enough free pkg memory (64 bytes left), please 
increase the "-M" command line parameter!
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:new_sock_info: pkg memory allocation error
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:new_sock2list: new_sock_info failed
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:add_interfaces: new_sock2list failed
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:fix_socket_list: could not resolve eth0
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:fix_all_socket_lists: fix_socket_list for 1 failed
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
ERROR:core:main: failed to initialize list addresses
Feb  7 10:57:25 sbc-dtag-bln opensips[3282]: Feb  7 10:57:25 [3290] 
NOTICE:core:main: Exiting

This is for OpenSIPS 2.2 & 2.3, running on
Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 
GNU/Linux



Thanks for your help
  Marco

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

Re: [OpenSIPS-Users] SIP message relay order

2017-02-07 Thread Bogdan-Andrei Iancu


Hi Stas,

If the ACK git the loose_route() / match_dialog(), then the state will 
move to 4.


You may also use the $DLG_lifetime when handling the re-INVITE - if it 
is less than 5 seconds, drop the re-INVITE :)


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 02/06/2017 09:46 PM, Stas Kobzar wrote:

Hello Bogdan,

In my case, ACK for previous INVITE has already been received by 
OpenSIPS, but not sent yet.

In this case, will the variable $DLG_status still equals 3 ?

Thanks

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


Hi Stas,

Such races may happen at application level or even at network
level (when using UDP) - so if you have 2 packets very close as
time, they may swap. That is SIP :)

The full guilt is in the UAC device, IMHO - it should let some
time gap between the ACK and re-INVITE, to eliminate any possible
races.

Now, what you can do is to use the dialog module and to check the
dialog state when receiving the re-invite. If $DLG_status is /3/
(Confirmed by a final reply but no ACK received yet), drop with no
reply the re-INVITEs (to force a later retransmission) :
http://www.opensips.org/html/docs/modules/2.2.x/dialog.html#id297400


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com 

On 02/02/2017 10:31 PM, Stas Kobzar wrote:

Hello List,
My call flow has initial INVITE and re-INVITE to update RTP IP/port.
Usually everything works well, but sometimes OpenSIPS come up
with following example:
UA OpenSIPS  PSTN GW
---
INV(CSeq: 100) -> | ---> INV(CSeq: 100)
< 200 OK  | <--- 200 OK
(UA sends ACK then new INVITE)
ACK(CSeq: 100) -> |
reINV(Cseq: 101) ---> |
(OpenSIPS relays first INVITE then ACK)
  | ---> reINV(CSeq: 101)
  | --->   ACK(CSeq: 100)
When PSTN gateway receives re-INVITE before ACK for previous INVITE
it responds 500 with Retry-After header.
This is correct behaviour which conforms to the RFC 3261 section 14.2
My question is:
Is it possible to assure order of received and relayed messages
within the same SIP session? Is there any configuration parameter?
Thank you,
-- 


Stas Kobzar

Developeur VoIP / VoIP Developer

Modulis.ca Inc.

# Bureau / Office: 514-284-2020 x 246 

Email: s tas.kob...@modulis.ca

https://www.modulis.com 

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



--

Stas Kobzar

Developeur VoIP / VoIP Developer

Modulis.ca Inc.

# Bureau / Office: 514-284-2020 x 246

Email: s tas.kob...@modulis.ca

https://www.modulis.com 

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

Re: [OpenSIPS-Users] Opensips with rtpengine

2017-02-07 Thread Sasmita Panda

Thank you so much .

*Thanks & Regards*
*Sasmita Panda*
*Network Testing and Software Engineer*
*3CLogic , ph:07827611765*

On Tue, Feb 7, 2017 at 2:30 PM, Răzvan Crainea  wrote:

> Hi, Sasmita!
>
> Yes, both proto_ws, proto_wss and rtpengine modules are mature enough and
> are ready to use.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 02/07/2017 10:47 AM, Sasmita Panda wrote:
>
> Hi All ,
>
>I am quite intrested to use opensips-2.2 with rtpengine . Is this
> working good or there is any open issue till now with this module .
>
>   And what about proto_ws and proto_wss . Are these modules working
> fine ? Please let me know if any precausion I need to take before using
> this .
>
>  Till now I was using opensips-1.11 .  So this will be very new for me
> . Please let me know if there is any open issue or any link on which I will
> get the details .
>
>
> *Thanks & Regards*
> *Sasmita Panda*
> *Network Testing and Software Engineer*
> *3CLogic , ph:07827611765*
>
>
> ___
> 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] Opensips with rtpengine

2017-02-07 Thread Răzvan Crainea


Hi, Sasmita!

Yes, both proto_ws, proto_wss and rtpengine modules are mature enough 
and are ready to use.


Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 02/07/2017 10:47 AM, Sasmita Panda wrote:

Hi All ,

   I am quite intrested to use opensips-2.2 with rtpengine . Is 
this working good or there is any open issue till now with this module .


  And what about proto_ws and proto_wss . Are these modules 
working fine ? Please let me know if any precausion I need to take 
before using this .


 Till now I was using opensips-1.11 .  So this will be very new 
for me . Please let me know if there is any open issue or any link on 
which I will get the details .



*/Thanks & Regards/*
/Sasmita Panda/
/Network Testing and Software Engineer/
/3CLogic , ph:07827611765/


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

2017-02-07 Thread Sasmita Panda

Hi All ,

   I am quite intrested to use opensips-2.2 with rtpengine . Is this
working good or there is any open issue till now with this module .

  And what about proto_ws and proto_wss . Are these modules working
fine ? Please let me know if any precausion I need to take before using
this .

 Till now I was using opensips-1.11 .  So this will be very new for me
. Please let me know if there is any open issue or any link on which I will
get the details .


*Thanks & Regards*
*Sasmita Panda*
*Network Testing and Software Engineer*
*3CLogic , ph:07827611765*
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

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

2017-02-07 Thread Ionut Ionita

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

   223loadmodule "siptrace.so"
   224modparam("siptrace", "trace_on", 1)
   225modparam("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 Developer
http://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

Re: [OpenSIPS-Users] Opensips backup

[OpenSIPS-Users] Opensips backup

Re: [OpenSIPS-Users] ds_select_dst with algorithm 6 is not using the last destination

Re: [OpenSIPS-Users] limit of using $acc_extra() variables

[OpenSIPS-Users] Handling various CANCEL scenarios

Re: [OpenSIPS-Users] SIP message relay order

Re: [OpenSIPS-Users] Change 200 OK of BYE message

Re: [OpenSIPS-Users] Change 200 OK of BYE message

Re: [OpenSIPS-Users] SIP message relay order

Re: [OpenSIPS-Users] rtpengine xmlrpc integration with opensips. Teardown xmlrpc method

Re: [OpenSIPS-Users] Change 200 OK of BYE message

[OpenSIPS-Users] limit of using $acc_extra() variables

Re: [OpenSIPS-Users] SIP message relay order

Re: [OpenSIPS-Users] Opensips with rtpengine

Re: [OpenSIPS-Users] Opensips with rtpengine

[OpenSIPS-Users] Opensips with rtpengine

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

17 matches

Site Navigation

Mail list logo

Footer information