I use Asterisk 11 and try to change ringing timeout in MySQL realtime extention. It takes only 7~10 seconds to hangup automatically. I checked extension and it was like this.
here is a screeshot of extension table in asteriskrealtime mysql database.
SIP/5162860921,60
I changed this one to
SIP/5162860921,300
However, there was no change. How can I extend ringing timeout to 60 seconds?
extensions.conf (I use realtime database)
[general]
[globals]
;
[from-sip]
switch =>Realtime
CLI log
== Using SIP RTP CoS mark 5
-- Executing [2000#from-sip:1] Dial("SIP/1000-00000000", "SIP/2000,30")
== Using SIP RTP CoS mark 5
-- Called SIP/2000
-- SIP/2000-00000001 is ringing
-- Got SIP response 486 "Busy here" back from 14.63.12.134:5060
-- SIP/2000-00000001 is busy
== Everyone is busy/congested at this time (1:1/0/0)
-- Executing [2000#from-sip:2] Answer("SIP/1000-00000000", "2000#from-sip")
> 0x7fe6fc01bc00 -- Probation passed - setting RTP source address to 223.62.180.115:47204
-- Executing [2000#from-sip:3] hangup("SIP/1000-00000000", "")
== Spawn extension (from-sip, 2000, 3) exited non-zero on 'SIP/1000-00000000'
It was softphone application problem. I changed it to 60 seconds and it is working fine now.. SIP/1000,60 was right.
Related
I'm working on a test scenario that it's testing a socket server over TCP with JMeter.
My test tree and TCP Sampler looks like this:
I used BinaryTCPClientImpl for 'TCPClient classname'. It worked correctly and sent the hex packet (24240011093583349040005000F6C80D0A) to the server and I received the packet in server side too. After receiving the packet in the server side, it answered and JMeter received the response packet correctly too.
As you can see in the following test result, the TCP Sampler (Login Packet) send 4 times in the right way and responses are true (404000120935833490400040000105490d0a).
The problem is that JMeter waits till the end of Timeout (in my case 2000ms) for each request and when it occurred then go to the next request. I don't want to wait for a timeout, I need a forward scenario, without the wait.
I found the solution according to the following question and it helped me:
Answer link
I just set the End of line(EOL) byte value to 10 that it means return new line in ASCI table.
I'm implementing a callback service for Asterisk queues.
The idea is to place all incoming calls on a queue. A message is played back, letting callers know that they can either wait in line until an agent becomes available or they can press '2', hangup, and have the agent call them back as soon as possible.
I defined a context for the inbound queue in queues.conf as such:
[qIngresoCC]
...
context=qIngresoCC-callback
...
and defined the corresponding entries in extensions.conf:
[qIngresoCC-callback]
exten = > 2,1,NoOp("El cliente ${CALLERID(all)} solicita CallBack")
same => n,AGI(add_channel_to_callback.php)
same => n,Playback(goodbye_for_the_best)
same => n,Hangup()
An incoming call is correctly sent to the queue, the announcements are played back, but when pressing '2', the call is not sent to the qIngresoCC-callback context.
DTMF logging is enabled, and I can see Asterisk receiving it, but it simply won't jump to the specified context.
[Jul 4 10:45:47] DTMF[84833][C-0000014d]: channel.c:4017 __ast_read: DTMF end '2' received on SIP/axtel-rappi-0000027b, duration 0 ms
[Jul 4 10:45:47] DTMF[84833][C-0000014d]: channel.c:4076 __ast_read: DTMF end accepted without begin '2' on SIP/axtel-rappi-0000027b
[Jul 4 10:45:47] DTMF[84833][C-0000014d]: channel.c:4087 __ast_read: DTMF end passthrough '2' on SIP/axtel-rappi-0000027b
What am I missing?
UPDATE
I forgot to specify:
I'm using Asterisk 13.14.0 compiled from source (by Portage) on Gentoo, with support (USE flags) for caps, curl, http, iconv, odbc, pjproject, postgres, samples, srtp.
I'm not using freepbx nor any other GUI. Everything is configured manually through the .conf files.
The only tuning of the source I did was changing channel.h from #define AST_MAX_ACCOUNT_CODE 20 to #define AST_MAX_ACCOUNT_CODE 256 to be able to use longer account codes.
The digit pressed must match the extension level in the context: for example if you have context=queue_out in your queues.conf and let's say your recording says "Press 5 to leave a voicemail (periodic announcement): extensions.conf would have the following
[queue_out]
exten => 5,1,Voicemail(123#default)
exten => 5,n,Hangup()
I had the same problem btw.
I've just recently started using JMeter.
I'm trying to run a TCP sampler on one of my servers.
The TCP sampler is set to all default values, with my IP, port number and text to send.
The server receives the text and responds as expected.
However, once JMeter receives the response it doesn't close the connection; it just waits until I stop the test manually, at which point the server logs show the client has disconnected.
I also have a response assertion which looks for this string:
{"SERVER":[{"End":200}]}\r\n
The Assertion is set to apply to main sample and sub-samples, the response field to test is set to Text Response.
With the pattern matching rules set to Equals I get:
Device Server Sampler
Device Server Response Assertion : Test failed: text expected to equal /
****** received : {"SERVER":[{"End":200}]}[[[
]]]
****** comparison: {"SERVER":[{"End":200}]}[[[\r\n]]]
/
If I set pattern matching to Contains I get:
Device Server Sampler
Which I can only assume at this point is a pass??
But no matter how I try it JMeter never closes the socket, so when I stop the tests myself and View the results in a table the status is marked as Warning, even though the correct amount of bytes have been received, and the data is correct.
JMeter doesn't seem to like \r\n so I've run the same tests removing those from the strings on both sides, but the sockets still remain open until I stop the tests.
Got any ideas what the issue may be?
In the TCP Sampler I needed to set End of line(EOL) byte value to 10, which is the decimal byte value for \n
I am make a application base on lwip,the applcation just send data to the server;
When my app works for some times (about 5 hours),I found that the send thread hung in send() function,and after about 30min send() return 0,and my thread run agin;
In the server side ,have make a keepalive,its time is 5min,when my app hungs,5min later the server close the sockect,but my app have not get this,still hungs in send() until 30min get 0 return; why this happen?
1: the up speed is not enough to send data,it will hungs in send?
2: maybe the server have not read data on time,and it make send buff full and hungs?
how can i avoid these peoblems in my code ? I have try to set TCP_NODELAY,SO_SNDTIMEO and select before send,but also have this problem.
send() blocks when the receiver is too far behind the sender. recv() returns zero when the peer has closed the connection, which means you must close the socket and stop reading.
I have read that the combination of three things causes something like a 200ms delay with TCP: Nagle's algorithm, delayed acknowledgement, and the "write-write-read" combination. However, I cannot reproduce this delay with Java sockets and I am therefore not sure if I have understood correctly.
I am running a test on Windows 7 with Java 7 with two threads using sockets over the loopback address. I have not touched the tcpNoDelay option on any socket (false by default) nor played around with any TCP settings on the OS. The main piece of the code in the client is as below. The server is responding with a byte after each two bytes it receives from the client.
for (int i = 0; i < 100; i++) {
client.getOutputStream().write(1);
client.getOutputStream().write(2);
System.out.println(client.getInputStream().read());
}
I do not see any delay. Why not?
I believe you see delay acknowledgment.
You write 4 and 4 bytes to the socket. The server's TCP stack receives a segment (that probably contains at least 4 bytes from an int number) and wakes up the server application thread. This thread writes a byte back to the stream and this byte is sent to the client within ACK segment. I.e. TCP stack gives a chance to an application to send a reply immediately. So you see no delay.
You can write a dump of traffic and also make an experiment between two computers to see what really happens.