date:20140415

Re: [OpenSIPS-Users] UDP vs TCP/TLS

2014-04-15 Thread leo

Thanks Razvan.
I'm still trying to troubleshoot this problem, i've seen that in the opensips 
logs, when i place a call, there are the following error messeges:

Apr 15 21:21:31 sip-lab /usr/local/opensips110/sbin/opensips[14226]: 
INFO:core:probe_max_sock_buff: using snd buffer of 255 kb
Apr 15 21:21:31 sip-lab /usr/local/opensips110/sbin/opensips[14226]: 
INFO:core:init_sock_keepalive: -- TCP keepalive enabled on socket
Apr 15 21:21:32 sip-lab /usr/local/opensips110/sbin/opensips[14225]: 
ERROR:nathelper:msg_send: tcp_send failed
Apr 15 21:21:32 sip-lab /usr/local/opensips110/sbin/opensips[14225]: 
ERROR:nathelper:nh_timer: sip msg_send failed!
Apr 15 21:21:41 sip-lab /usr/local/opensips110/sbin/opensips[14226]: 
ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s
Apr 15 21:21:41 sip-lab /usr/local/opensips110/sbin/opensips[14226]: 
ERROR:core:tcpconn_connect: tcp_blocking_connect failed
Apr 15 21:21:41 sip-lab /usr/local/opensips110/sbin/opensips[14226]: 
ERROR:core:tcp_send: connect failed
Apr 15 21:21:41 sip-lab /usr/local/opensips110/sbin/opensips[14226]: 
ERROR:tm:msg_send: tcp_send failed
Apr 15 21:21:41 sip-lab /usr/local/opensips110/sbin/opensips[14226]: 
ERROR:tm:t_forward_nonack: sending request failed
Apr 15 21:21:41 sip-lab /usr/local/opensips110/sbin/opensips[14226]: 
ERROR:rtpproxy:force_rtp_proxy: Unable to parse body
Apr 15 21:21:41 sip-lab /usr/local/opensips110/sbin/opensips[14226]: incoming 
reply
Apr 15 21:21:41 sip-lab /usr/local/opensips110/sbin/opensips[14226]: 
ERROR:rtpproxy:force_rtp_proxy: Unable to parse body
Apr 15 21:21:41 sip-lab /usr/local/opensips110/sbin/opensips[14226]: incoming 
reply
Apr 15 21:21:42 sip-lab /usr/local/opensips110/sbin/opensips[14225]: 
ERROR:nathelper:msg_send: tcp_send failed
Apr 15 21:21:42 sip-lab /usr/local/opensips110/sbin/opensips[14225]: 
ERROR:nathelper:nh_timer: sip msg_send failed!

I didn't reply before because i was serching in the forum but i didn'n find any 
helpfull topic.
Do you still think that is a network issue? Do those error logs have a meaning?
If you see, form the call placing to the incoming replay there are 10 secs.

Thanks a lot,

Leo.

Il Lunedì 14 Aprile 2014 10:26, Razvan Crainea-3 [via OpenSIPS (Open SIP 
Server)]  ha scritto:

Hi, Leo! 

This doesn't seem to be related to OpenSIPS. My suggestion is to trace 
this at the network layer and check if and why the TCP/TLS connection is 
taking 15-20 seconds. 

Best regards, 

Razvan Crainea 
OpenSIPS Core Developer 
http://www.opensips-solutions.com

On 04/14/2014 01:17 AM, leo wrote: 

> Hello: 
> 
> I'm using opensips 1.10 in a simple single domain scenario. 
> The UA are normally NATted. 
> The problem i'm having is that the call establishment using UDP is 1 or 2 
> sec while when i use TCP or TLS the call is taking 15-20 sec. 
> Is this normal? How could i have the same performance for TCP/TLS like with 
> UDP? 
> Thanks a lot. 
> 
> Leo. 
> 
> 
> 
> -- 
> View this message in context: 
> http://opensips-open-sip-server.1449251.n2.nabble.com/UDP-vs-TCP-TLS-tp7590719.html
> Sent from the OpenSIPS - Users mailing list archive at Nabble.com. 
> 
> ___ 
> Users mailing list 
> [hidden email] 
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
___ 
Users mailing list 
[hidden email] 

http://lists.opensips.org/cgi-bin/mailman/listinfo/users

If you reply to this email, your message will be added to the discussion 
below:http://opensips-open-sip-server.1449251.n2.nabble.com/UDP-vs-TCP-TLS-tp7590719p7590723.html

To unsubscribe from UDP vs TCP/TLS, click here.
NAML

--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/UDP-vs-TCP-TLS-tp7590719p7590757.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Issue in VIA Header

2014-04-15 Thread B. Buitenhuis

I'll try it on a bare metal.
Good point!



Van: Ali Pey mailto:ali...@gmail.com>>
Beantwoorden - Aan: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Datum: dinsdag 15 april 2014 19:36
Aan: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Onderwerp: Re: [OpenSIPS-Users] Issue in VIA Header

Are you running on a VM environment? If so, try your script on a bare metal 
hardware. VMs mess with OS quite a bit.


Regards,
Ali Pey



On Tue, Apr 15, 2014 at 1:33 PM, B. Buitenhuis 
mailto:bern...@buitenhuis.nu>> wrote:
Hi ,

I'm not using any aliases in my config and I've tested the config with 
different machines in different networks.

About the messages
They are set properly before they reach open sips. Weird thing is that after 
running the open sips deamon (about a hour) the problem looks solved.


Van: Ali Pey mailto:ali...@gmail.com>>

Beantwoorden - Aan: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Datum: dinsdag 15 april 2014 19:29

Aan: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Onderwerp: Re: [OpenSIPS-Users] Issue in VIA Header

Have a look at your system network configuration and aliases in opensips?

Where do these messages come from and where do they go? Have you checked if 
they are set properly before they reach opensips.


Regards,
Ali Pey


On Tue, Apr 15, 2014 at 7:14 AM, B. Buitenhuis 
mailto:bern...@buitenhuis.nu>> wrote:
Anyone has any clue where to look?



Van: MT mailto:bern...@buitenhuis.nu>>
Beantwoorden - Aan: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Datum: maandag 14 april 2014 12:35

Aan: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Onderwerp: Re: [OpenSIPS-Users] Issue in VIA Header

Also with the latest master branch I've got this problem.
After running opensips deamon for an hour the problems seems te be solved.

Is this a known bug?

Van: MT mailto:bern...@buitenhuis.nu>>
Beantwoorden - Aan: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Datum: zaterdag 12 april 2014 00:09
Aan: "users@lists.opensips.org" 
mailto:users@lists.opensips.org>>
Onderwerp: [OpenSIPS-Users] Issue in VIA Header

Hello,

I'm facing the same problem as:
https://github.com/OpenSIPS/opensips/issues/190

When I look at a wireshark, I see the following in the VIA header:
Via: SIP/2.0/UDP 
\000\000\000\000\000\000\000\000\000\000\000\000\000:5060;branch=z9hG4bK9414.22d66c76.0

As far as I can see it's only with the CANCEL method, in the config it looks 
like:

if (method=="CANCEL")
{
set_advertised_address(185.XX.XX.XX);

route("PROCESS_RTP_PROXY");
unforce_rtp_proxy();
if (t_check_trans())
t_relay();
exit;
}


I've tested it with 1.8.3 and 1.10.1

Does anyone has this same problem?


Regards,

Bernard Buitenhuis


___
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] Issue in VIA Header

2014-04-15 Thread Ali Pey

Are you running on a VM environment? If so, try your script on a bare metal
hardware. VMs mess with OS quite a bit.


Regards,
Ali Pey



On Tue, Apr 15, 2014 at 1:33 PM, B. Buitenhuis wrote:

>  Hi ,
>
>  I'm not using any aliases in my config and I've tested the config with
> different machines in different networks.
>
>  About the messages
> They are set properly before they reach open sips. Weird thing is that
> after running the open sips deamon (about a hour) the problem looks solved.
>
>
>   Van: Ali Pey 
>
> Beantwoorden - Aan: OpenSIPS users mailling list  >
> Datum: dinsdag 15 april 2014 19:29
>
> Aan: OpenSIPS users mailling list 
> Onderwerp: Re: [OpenSIPS-Users] Issue in VIA Header
>
>   Have a look at your system network configuration and aliases in
> opensips?
>
>  Where do these messages come from and where do they go? Have you checked
> if they are set properly before they reach opensips.
>
>
>  Regards,
> Ali Pey
>
>
> On Tue, Apr 15, 2014 at 7:14 AM, B. Buitenhuis wrote:
>
>>  Anyone has any clue where to look?
>>
>>
>>
>>   Van: MT 
>> Beantwoorden - Aan: OpenSIPS users mailling list <
>> users@lists.opensips.org>
>>  Datum: maandag 14 april 2014 12:35
>>
>> Aan: OpenSIPS users mailling list 
>>  Onderwerp: Re: [OpenSIPS-Users] Issue in VIA Header
>>
>>   Also with the latest master branch I've got this problem.
>> After running opensips deamon for an hour the problems seems te be solved.
>>
>>  Is this a known bug?
>>
>>   Van: MT 
>> Beantwoorden - Aan: OpenSIPS users mailling list <
>> users@lists.opensips.org>
>> Datum: zaterdag 12 april 2014 00:09
>> Aan: "users@lists.opensips.org" 
>> Onderwerp: [OpenSIPS-Users] Issue in VIA Header
>>
>>   Hello,
>>
>>  I'm facing the same problem as:
>> https://github.com/OpenSIPS/opensips/issues/190
>>
>>  When I look at a wireshark, I see the following in the VIA header:
>> Via: SIP/2.0/UDP
>> \000\000\000\000\000\000\000\000\000\000\000\000\000:5060;branch=z9hG4bK9414.22d66c76.0
>>
>>  As far as I can see it's only with the CANCEL method, in the config it
>> looks like:
>>
>>  if (method=="CANCEL")
>> {
>>  set_advertised_address(185.XX.XX.XX);
>>
>>  route("PROCESS_RTP_PROXY");
>> unforce_rtp_proxy();
>> if (t_check_trans())
>> t_relay();
>> exit;
>> }
>>
>>
>>  I've tested it with 1.8.3 and 1.10.1
>>
>>  Does anyone has this same problem?
>>
>>
>>  Regards,
>>
>>  Bernard Buitenhuis
>>
>>
>> ___
>> 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] Issue in VIA Header

2014-04-15 Thread B. Buitenhuis

Hi ,

I'm not using any aliases in my config and I've tested the config with 
different machines in different networks.

About the messages
They are set properly before they reach open sips. Weird thing is that after 
running the open sips deamon (about a hour) the problem looks solved.


Van: Ali Pey mailto:ali...@gmail.com>>
Beantwoorden - Aan: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Datum: dinsdag 15 april 2014 19:29
Aan: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Onderwerp: Re: [OpenSIPS-Users] Issue in VIA Header

Have a look at your system network configuration and aliases in opensips?

Where do these messages come from and where do they go? Have you checked if 
they are set properly before they reach opensips.


Regards,
Ali Pey


On Tue, Apr 15, 2014 at 7:14 AM, B. Buitenhuis 
mailto:bern...@buitenhuis.nu>> wrote:
Anyone has any clue where to look?



Van: MT mailto:bern...@buitenhuis.nu>>
Beantwoorden - Aan: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Datum: maandag 14 april 2014 12:35

Aan: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Onderwerp: Re: [OpenSIPS-Users] Issue in VIA Header

Also with the latest master branch I've got this problem.
After running opensips deamon for an hour the problems seems te be solved.

Is this a known bug?

Van: MT mailto:bern...@buitenhuis.nu>>
Beantwoorden - Aan: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Datum: zaterdag 12 april 2014 00:09
Aan: "users@lists.opensips.org" 
mailto:users@lists.opensips.org>>
Onderwerp: [OpenSIPS-Users] Issue in VIA Header

Hello,

I'm facing the same problem as:
https://github.com/OpenSIPS/opensips/issues/190

When I look at a wireshark, I see the following in the VIA header:
Via: SIP/2.0/UDP 
\000\000\000\000\000\000\000\000\000\000\000\000\000:5060;branch=z9hG4bK9414.22d66c76.0

As far as I can see it's only with the CANCEL method, in the config it looks 
like:

if (method=="CANCEL")
{
set_advertised_address(185.XX.XX.XX);

route("PROCESS_RTP_PROXY");
unforce_rtp_proxy();
if (t_check_trans())
t_relay();
exit;
}


I've tested it with 1.8.3 and 1.10.1

Does anyone has this same problem?


Regards,

Bernard Buitenhuis


___
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] dlg_end_dlg ALL?

2014-04-15 Thread Ali Pey

I second this as well. +1

Thanks,
Ali Pey



On Tue, Apr 15, 2014 at 10:48 AM, Jeff Pyle  wrote:

> Very useful indeed.  +1
>
>
>
> - Jeff
>
>
> On Tue, Apr 15, 2014 at 10:28 AM, Brett Nemeroff wrote:
>
>> Hi Liviu,
>> I think this would be a very useful feature as well. Specifically I'd
>> like to be able to say something like
>> :dlg_end_profile
>> 
>>
>> and it'd hang up all calls (dlg_end_dlg method) all calls in that
>> profile. Given that you already know what calls are in a profile, this
>> should be a very efficient way to hangup an entire account, gateway,
>> customer, etc rather than iterating any kind of dialog list.
>>
>> Just my $0.02. Thanks!
>> -Brett
>>
>>
>>
>> On Fri, Mar 28, 2014 at 12:35 PM, Liviu Chircu wrote:
>>
>>> Hello Kneeoh,
>>>
>>> Point taken. I just added this feature on the list!
>>>
>>>
>>> Best regards,
>>>
>>> Liviu Chircu
>>> OpenSIPS Developer
>>> http://www.opensips-solutions.com
>>>
>>> On 03/28/2014 07:30 PM, Kneeoh wrote:
>>>
 mmm. I really don't want to use the fifo. Thats the problem I have now.
 I already have an iterative script to do what you describe. Instead I want
 to use the mi_xmlrpc_ng interface to interact with the dialog module.
 Instead of listing dialogs via the xmlrpc interface and using an external
 parser to get all the dialog ids, I just want to say "kill all dialogs" or
 more specifically, "kill all dialogs with these attributes".

 ___
 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] Issue in VIA Header

2014-04-15 Thread Ali Pey

Have a look at your system network configuration and aliases in opensips?

Where do these messages come from and where do they go? Have you checked if
they are set properly before they reach opensips.


Regards,
Ali Pey


On Tue, Apr 15, 2014 at 7:14 AM, B. Buitenhuis wrote:

>  Anyone has any clue where to look?
>
>
>
>   Van: MT 
> Beantwoorden - Aan: OpenSIPS users mailling list  >
> Datum: maandag 14 april 2014 12:35
>
> Aan: OpenSIPS users mailling list 
> Onderwerp: Re: [OpenSIPS-Users] Issue in VIA Header
>
>   Also with the latest master branch I've got this problem.
> After running opensips deamon for an hour the problems seems te be solved.
>
>  Is this a known bug?
>
>   Van: MT 
> Beantwoorden - Aan: OpenSIPS users mailling list  >
> Datum: zaterdag 12 april 2014 00:09
> Aan: "users@lists.opensips.org" 
> Onderwerp: [OpenSIPS-Users] Issue in VIA Header
>
>   Hello,
>
>  I'm facing the same problem as:
> https://github.com/OpenSIPS/opensips/issues/190
>
>  When I look at a wireshark, I see the following in the VIA header:
> Via: SIP/2.0/UDP
> \000\000\000\000\000\000\000\000\000\000\000\000\000:5060;branch=z9hG4bK9414.22d66c76.0
>
>  As far as I can see it's only with the CANCEL method, in the config it
> looks like:
>
>  if (method=="CANCEL")
> {
>  set_advertised_address(185.XX.XX.XX);
>
>  route("PROCESS_RTP_PROXY");
> unforce_rtp_proxy();
> if (t_check_trans())
> t_relay();
> exit;
> }
>
>
>  I've tested it with 1.8.3 and 1.10.1
>
>  Does anyone has this same problem?
>
>
>  Regards,
>
>  Bernard Buitenhuis
>
>
> ___
> 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] OPTIONS over TCP

2014-04-15 Thread Ali Pey

You don't really need Options for TCP. You use Options to keep UDP
ports/connection open. TCP is a stateful connection. You only need to make
sure that opensips keeps the connection open for the period of the time it
is needed.

is_from_gw should work since it works based on the src_ip.


Regards,
Ali Pey



On Tue, Apr 8, 2014 at 5:40 AM, Vincent DOCQUOIS <
v.docquois.netvi...@gmail.com> wrote:

> Hello all,
>
> I am using Opensips 1.10 for SIP trunking purposes.
> I use DR module in order to route calls to external gateways. One of
> destination gateways is only handling SIP over TCP. By adding
> "transport=tcp" header, I have no problem to use Opensips as a UDP to TCP
> gateway but I encounter 2 problems with keepalive process (using OPTIONS
> method) :
>
> 1) Is there a way to make DR module send OPTIONS over TCP instead of
> default UDP ?
> 2) In the opposite direction, when an incoming TCP OPTIONS is received by
> Opensips from the external gateway, the 'is_from_gw' function seems not to
> be able to identify my external gateway. Note that it is OK in UDP with
> another gateway.
>
> Is it just a limitation or is there any solution to handle OPTIONS over
> TCP ?
>
> Thanks in advance
>
> Vincent
> ___
> 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] Miliseconds precision for accounting module

2014-04-15 Thread Maciej Bylica

Hello,

It works, but:
1) get_timestamp doesnt work inside has_totag section
 if (has_totag()) {
if (loose_route()) {
  if (is_method("BYE")) {
  get_timestamp($avp(secbye),$avp(usecbye));
  .
  .
but works if called before that section

2) because i need to count duration, i should rather place it inside
onreply_route
 if (t_check_status("200")) {
get_timestamp($avp(sec),$avp(usec));
}
 but the question is how it will behave in case of reINVITE is triggered
from the originating side.
I think $avp(sec),$avp(usec) will be overwritten.
So maybe wise idea will be to set some flag in first 200 message and make
another statement like if ((t_check_status("200")) && !(isflagset(XX)))

What do you think about p1 and p2?

Thanks
Mac



2014-04-14 12:56 GMT+02:00 Maciej Bylica :

> Hi Vlad,
>
> Thanks for reply.
> I am using OpenSIPS (1.9.1-notls (x86_64/linux)) so get_timestamp is
> available there.
> Let me check this.
>
> Regards,
> Mac
>
>
> 2014-04-14 10:57 GMT+02:00 Vlad Paiu :
>
>  Hello,
>>
>> Which OpenSIPS version are you using ?
>> You could use get_timestamp [1] from the Core to get the current second
>> and microsecond,
>> and set the two variables at INVITE time, and set them as db_extra [2] .
>>
>> Then, at BYE time call again the get_timestamp function, store them in
>> some AVPs and set those AVPs in [3]. This way you should get both the
>> INVITE and BYE timestamps with microseconds precision in the CDR record.
>>
>> [1] http://www.opensips.org/Documentation/Script-CoreFunctions-1-10#toc18
>> [2] http://www.opensips.org/html/docs/modules/1.10.x/acc.html#id295028
>> [3] http://www.opensips.org/html/docs/modules/1.10.x/acc.html#id295056
>>
>> Best Regards,
>>
>> Vlad Paiu
>> OpenSIPS Developerhttp://www.opensips-solutions.com
>>
>> On 12.04.2014 23:44, Maciej Bylica wrote:
>>
>> Hello Ryan,
>>
>>  I am using dialog accounting, so each row is fully qualified cdr
>> record, not only single transaction of a call.
>> Couldn't i just use two extra db variables which will gather the $time
>> inside INVITE {} and BYE {}?
>>
>>  Thanks,
>> Mac
>>
>>
>> 2014-04-12 6:39 GMT+02:00 Ryan Mitchell :
>>
>>> Hello Mac,
>>>
>>>  Each row in the acc table is for a transaction.  To make a proper CDR
>>> out of the data, you have to combine rows to find the start and end of the
>>> call.  That can be harder than it sounds, especially with forking
>>> (parallel, or the more common case of serial forking when you are LCR
>>> routing or simply sending calls to alt destinations after a timeout).  I
>>> wrote scripts that implement a simple dialog state machine to make sense of
>>> all the distinct legs of a call, though there should be an easier way with
>>> the auto-cdr / multi call-legs accounting feature of the acc module (anyone
>>> comment on this please?).
>>>
>>>  The time field in the acc table will be the timestamp of the response
>>> for the given transaction.  If you assign an extra field for another
>>> timestamp, it will depend on where you assign that var in your script.  In
>>> my case I assign it in the main routing section so the timestamp indicates
>>> the start of the transaction.
>>>
>>>  best regards,
>>> Ryan
>>>
>>>
>>>
>>> On Fri, Apr 11, 2014 at 10:06 AM, Maciej Bylica  wrote:
>>>
 Ryan,

  One more question.
 Currently i have some db extra attrs setup. My acc table looks like
 following:


 ++--+--+-+-++

 | Field  | Type | Null | Key | Default | Extra
 |


 ++--+--+-+-++

 | id | int(10) unsigned | NO   | PRI | NULL| auto_increment
 |

 | method | char(16) | NO   | | |
 |

 | from_tag   | char(64) | NO   | | |
 |

 | to_tag | char(64) | NO   | | |
 |

 | callid | char(64) | NO   | MUL | |
 |

 | sip_code   | char(3)  | NO   | | |
 |

 | sip_reason | char(32) | NO   | | |
 |

 | time   | datetime | NO   | | NULL|
 |

 | duration   | int(11) unsigned | NO   | | 0   |
 |

 | setuptime  | int(11) unsigned | NO   | | 0   |
 |

 | SourceAddr | char(30) | NO   | | NULL|
 |

 | DestAddr   | char(30) | NO   | | NULL|
 |

 | Anum   | char(30) | NO   | | NULL|
 |

 | Bnum_rU| char(30) | NO   | | NULL|
 |

 | Bnum_tU| char(30) | NO   | | NULL|
 |

 | created| datetime | YES  | | NULL|
 |


 ++--+--+-+-+--

Re: [OpenSIPS-Users] dlg_end_dlg ALL?

2014-04-15 Thread Jeff Pyle

Very useful indeed.  +1



- Jeff


On Tue, Apr 15, 2014 at 10:28 AM, Brett Nemeroff  wrote:

> Hi Liviu,
> I think this would be a very useful feature as well. Specifically I'd like
> to be able to say something like
> :dlg_end_profile
> 
>
> and it'd hang up all calls (dlg_end_dlg method) all calls in that profile.
> Given that you already know what calls are in a profile, this should be a
> very efficient way to hangup an entire account, gateway, customer, etc
> rather than iterating any kind of dialog list.
>
> Just my $0.02. Thanks!
> -Brett
>
>
>
> On Fri, Mar 28, 2014 at 12:35 PM, Liviu Chircu  wrote:
>
>> Hello Kneeoh,
>>
>> Point taken. I just added this feature on the list!
>>
>>
>> Best regards,
>>
>> Liviu Chircu
>> OpenSIPS Developer
>> http://www.opensips-solutions.com
>>
>> On 03/28/2014 07:30 PM, Kneeoh wrote:
>>
>>> mmm. I really don't want to use the fifo. Thats the problem I have now.
>>> I already have an iterative script to do what you describe. Instead I want
>>> to use the mi_xmlrpc_ng interface to interact with the dialog module.
>>> Instead of listing dialogs via the xmlrpc interface and using an external
>>> parser to get all the dialog ids, I just want to say "kill all dialogs" or
>>> more specifically, "kill all dialogs with these attributes".
>>>
>>> ___
>>> 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] dlg_end_dlg ALL?

2014-04-15 Thread Brett Nemeroff

Hi Liviu,
I think this would be a very useful feature as well. Specifically I'd like
to be able to say something like
:dlg_end_profile

and it'd hang up all calls (dlg_end_dlg method) all calls in that profile.
Given that you already know what calls are in a profile, this should be a
very efficient way to hangup an entire account, gateway, customer, etc
rather than iterating any kind of dialog list.

Just my $0.02. Thanks!
-Brett

On Fri, Mar 28, 2014 at 12:35 PM, Liviu Chircu  wrote:

> Hello Kneeoh,
>
> Point taken. I just added this feature on the list!
>
>
> Best regards,
>
> Liviu Chircu
> OpenSIPS Developer
> http://www.opensips-solutions.com
>
> On 03/28/2014 07:30 PM, Kneeoh wrote:
>
>> mmm. I really don't want to use the fifo. Thats the problem I have now. I
>> already have an iterative script to do what you describe. Instead I want to
>> use the mi_xmlrpc_ng interface to interact with the dialog module. Instead
>> of listing dialogs via the xmlrpc interface and using an external parser to
>> get all the dialog ids, I just want to say "kill all dialogs" or more
>> specifically, "kill all dialogs with these attributes".
>>
>> ___
>> 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] No voice, while using 3G ( OpenSIPS & RTPProxy on AWS )

2014-04-15 Thread Maksim Solovjov

Hello,

I was able to install OpenSIPS and RTPProxy ( taken from here ) on
Amazon EC2, and onn the mobile side I am using PJSIP library.
I am able to make VOIP call from ios simulator <-> iphone5 and it
works well, if the iphone5 is connected to a WiFi, but if I turn off
the WiFi on the device and try to make the VOIP call using 3G, I can't
hear any voice, although the connection and the call are established (
confirmed ).

Maybe you can give me some advice or suggestions. Where should I look
for an error?
On the server side or on the mobile side??

Here is the info about the call ( 3G, without the voice ), which was
given by PJSIP:
==
Call time: 00h:05m:07s, 1st res in 6688 ms, conn in 6689ms
#0 audio speex @16kHz, sendrecv, peer=-
SRTP status: Not active Crypto-suite:
RX pt=98, last update:00h:00m:00.641s ago
total 0pkt 0B (0B +IP hdr) @avg=0bps/0bps
pkt loss=0 (0.0%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
(msec)min avg max lastdev
loss period:   0.000   0.000   0.000   0.000   0.000
jitter :   0.000   0.000   0.000   0.000   0.000
TX pt=98, ptime=20, last update:never
total 12.8Kpkt 397.0KB (910.1KB +IP hdr) @avg=10.3Kbps/23.6Kbps
pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec)min avg max lastdev
loss period:   0.000   0.000   0.000   0.000   0.000
jitter :   0.000   0.000   0.000   0.000   0.000
RTT msec  :   0.000   0.000   0.000   0.000   0.000
==

OpenSIPS doesn't give any errors, it shows that:
INFO:rtpproxy:rtpp_test: rtp proxy  found,
support for it enabled

And here is my opensips.cfg file:
==

### Global Parameters #
debug=3
log_stderror=no
log_facility=LOG_LOCAL1
fork=yes
children=4

advertised_address="my_public_ip"

#debug=6
#fork=no
#log_stderror=yes

#disable_dns_blacklist=no

auto_aliases=yes
listen=udp:my_private_ip:5060
disable_tcp=no
listen=tcp:my_private_ip:5060
alias=my_public_ip:5060
alias=mydomain.com:5060
disable_tls=yes

### Modules Section 

#set module path
mpath="/usr/lib64/opensips/modules/"

 SIGNALING module
loadmodule "signaling.so"

 StateLess module
loadmodule "sl.so"

 Transaction Module
loadmodule "tm.so"
modparam("tm", "fr_timer", 5)
modparam("tm", "fr_inv_timer", 30)
modparam("tm", "restart_fr_on_each_reply", 0)
modparam("tm", "onreply_avp_mode", 1)

 Record Route Module
loadmodule "rr.so"
/* do not append from tag to the RR (no need for this script) */
modparam("rr", "append_fromtag", 0)

 MAX ForWarD module
loadmodule "maxfwd.so"

 SIP MSG OPerationS module
loadmodule "sipmsgops.so"


 FIFO Management Interface
loadmodule "mi_fifo.so"
modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")
modparam("mi_fifo", "fifo_mode", 0666)

 URI module
loadmodule "uri.so"
modparam("uri", "use_uri_table", 0)

 USeR LOCation module
loadmodule "usrloc.so"
modparam("usrloc", "nat_bflag", "NAT")
modparam("usrloc", "db_mode",   0)

  NAT modules
loadmodule "nathelper.so"
modparam("nathelper", "natping_interval", 10)
modparam("nathelper", "ping_nated_only", 1)
modparam("nathelper", "received_avp", "$avp(received_nh)")

loadmodule "rtpproxy.so"
modparam("rtpproxy", "rtpproxy_sock", "udp:my_private_ip:9000") # CUSTOMIZE ME

 REGISTRAR module
loadmodule "registrar.so"
modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT")

 ACCounting module
loadmodule "acc.so"
/* what special events should be accounted ? */
modparam("acc", "early_media", 0)
modparam("acc", "report_cancels", 0)
/* by default we do not adjust the direct of the sequential requests.
   if you enable this parameter, be sure the enable "append_fromtag"
   in "rr" module */
modparam("acc", "detect_direction", 0)
modparam("acc", "failed_transaction_flag", "ACC_FAILED")
/* account triggers (flags) */
modparam("acc", "log_flag", "ACC_DO")
modparam("acc", "log_missed_flag", "ACC_MISSED")

==

Any help will be highly appreciated!
Thank you in advance.

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

[OpenSIPS-Users] Acc module

2014-04-15 Thread M.Khaled W Chehab

Hi

 

I have a problem with accc modules with  the below scenario :

OPENSIPS  receive the 200 ok from the trunk  gateway ,and forward it to UA, 

UA replies by ACK and opensips forward this ACK to Gateway ,..but for some
reason the Gateways resends a lot of 200 OK with SDP and opensips relay
these packets to UA and UA replies  with ACK ... 

Problem: Acc module set the call duration to 3600 seconds which is the max
call duration  

By wire shark i can see that UA is sending a bye after 2 minutes  and
opensips  relay  the BYE to Gateway moreover  trunk gateway is sending back
200 OK  to confirm the bye and it ends the call 

But in mysql acc  rows ,   acc module  store  the call duration to max call
duration(3600) 

 

How can I fix this ,please advice

 

Regards

 

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

Re: [OpenSIPS-Users] Issue in VIA Header

2014-04-15 Thread B. Buitenhuis

Anyone has any clue where to look?



Van: MT mailto:bern...@buitenhuis.nu>>
Beantwoorden - Aan: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Datum: maandag 14 april 2014 12:35
Aan: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Onderwerp: Re: [OpenSIPS-Users] Issue in VIA Header

Also with the latest master branch I've got this problem.
After running opensips deamon for an hour the problems seems te be solved.

Is this a known bug?

Van: MT mailto:bern...@buitenhuis.nu>>
Beantwoorden - Aan: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Datum: zaterdag 12 april 2014 00:09
Aan: "users@lists.opensips.org" 
mailto:users@lists.opensips.org>>
Onderwerp: [OpenSIPS-Users] Issue in VIA Header

Hello,

I'm facing the same problem as:
https://github.com/OpenSIPS/opensips/issues/190

When I look at a wireshark, I see the following in the VIA header:
Via: SIP/2.0/UDP 
\000\000\000\000\000\000\000\000\000\000\000\000\000:5060;branch=z9hG4bK9414.22d66c76.0

As far as I can see it's only with the CANCEL method, in the config it looks 
like:

if (method=="CANCEL")
{
set_advertised_address(185.XX.XX.XX);

route("PROCESS_RTP_PROXY");
unforce_rtp_proxy();
if (t_check_trans())
t_relay();
exit;
}


I've tested it with 1.8.3 and 1.10.1

Does anyone has this same problem?


Regards,

Bernard Buitenhuis

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

Re: [OpenSIPS-Users] UDP vs TCP/TLS

Re: [OpenSIPS-Users] Issue in VIA Header

Re: [OpenSIPS-Users] Issue in VIA Header

Re: [OpenSIPS-Users] Issue in VIA Header

Re: [OpenSIPS-Users] dlg_end_dlg ALL?

Re: [OpenSIPS-Users] Issue in VIA Header

Re: [OpenSIPS-Users] OPTIONS over TCP

Re: [OpenSIPS-Users] Miliseconds precision for accounting module

Re: [OpenSIPS-Users] dlg_end_dlg ALL?

Re: [OpenSIPS-Users] dlg_end_dlg ALL?

[OpenSIPS-Users] No voice, while using 3G ( OpenSIPS & RTPProxy on AWS )

[OpenSIPS-Users] Acc module

Re: [OpenSIPS-Users] Issue in VIA Header

13 matches

Site Navigation

Mail list logo

Footer information