Giter VIP home page Giter VIP logo

cami's Introduction

cami's People

Contributors

interlinked1 avatar

Stargazers

avatar avatar avatar

Watchers

avatar avatar

Forkers

anandeshwar

cami's Issues

Fix handling for delayed AMI responses

Not yet sure if this is a problem with CAMI or Asterisk, but either way, we need to handle this scenario better:

The problem is discussed in this commit message: 6d57c7c

Here's an example where it takes about 1500 ms to get the full response. Something about this isn't quite right. Why is it taking so long? That needs to be investigated so the root problem can be addressed, rather than having an arbitrarily long wait timeout for responses.

Particularly noteworthy is that we do in fact receive the entire response on time, essentially instantly. The remaining time is getting "eaten up" somehow because we haven't detected the EOM, and it takes over a second to somehow get that. However, there isn't any actual new data delivered during that time.

1657652606:261 : 158 : Response pending this loop (10048/1048576)!
1657652606:262 : 252 : Still in the middle of it...
1657652606:262 : 252 : Still in the middle of it...
1657652606:262 : 263 : Asterisk left us high and dry for the end of the response, polling again...
1657652606:262 : 158 : Response pending this loop (11043/1048576)!
1657652606:264 : 252 : Still in the middle of it...
1657652606:264 : 252 : Still in the middle of it...
1657652606:264 : 252 : Still in the middle of it...
1657652606:264 : 263 : Asterisk left us high and dry for the end of the response, polling again...
1657652606:264 : 158 : Response pending this loop (12624/1048576)!
1657652606:264 : 263 : Asterisk left us high and dry for the end of the response, polling again...
1657652606:264 : 158 : Response pending this loop (12624/1048576)!
1657652606:264 : 263 : Asterisk left us high and dry for the end of the response, polling again...
1657652606:315 : 158 : Response pending this loop (12624/1048576)!
1657652607:228 : 853 : Didn't receive any AMI response within 1000 ms?
1657652607:863 : 158 : Response pending this loop (12624/1048576)!
1657652607:863 : 719 : <== AMI Response: Response: Success
ActionID: 2
EventList: start
Message: Following are ContactStatusEvents for each Inbound registration...
1657652607:864 : 740 : Current response now 0x7f08d4000d00
1657652607:864 : 803 : BUG! current_response was 0x7f08d4000d00 immediately after lock acquired?

Possibly remove writing through pipe for sending AMI actions?

I would label this "improvement" but I guess that label doesn't exist by default.

This isn't a bug, and wouldn't result in behavior change, but since writing to a pipe at the same time another thread is reading from it is perfectly okay, we could probably remove the middleman of writing AMI actions to a pipe first and then having the ami_loop thread read from the pipe and simply write out to the socket.

We wouldn't necessarily gain an efficiency improvement however, since if we're reading and processing an AMI response then, the way that locking is done we're still effectively single threaded. Just something to think about...

Add multiple log levels

ami_debug should accept various debug levels, and the debug level should be accepted as a parameter if debug is enabled.
Additionally, there are several debugs of the style BUG: xxx, and there should be a separate macro for these that ties in with logging.

AMI events get missed

It is possible that events from the AMI get missed. This is the case when more than one event are written to the ami_event_pipe before it gets emptied in ami_event_dispatch thread. When the read takes place, there are more than one event separated by '\0'. But ami_parse_event counts only
before_after.txt
till the first '\0'.

events_missed_diff.txt

Insufficient buffer truncates AMI response

Not really surprising, but a static buffer that is too small to fit a single entire AMI response will result in a truncated response being processed.

While this could be fixed easily by simply increasing the buffer to something reasonably large, like from 4096 to 1048576 (which is what I've done in production at the moment), long term we should really be using a dynamic buffer, resizing if necessary, e.g. using realloc, in order to handle any arbitrarily long AMI response. Then we can do away with the fixed buffer altogether, and this should provide maximal resiliency.

Responses can be split on incomplete read from socket

If poll and recv return before Asterisk has finished putting all data onto the socket, then we may parse an incomplete response, improperly truncating it.

This happens randomly, a small fraction of the time:

root@pbxdev:~/astrex/cami# make && ./cami test
gcc -Wall -Werror -Wno-unused-parameter -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -Wmissing-declarations -Wmissing-format-attribute -Wformat=2 -Wshadow -std=gnu99 -pthread -O0 -g -Wstack-protector -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -o cami -lm *.o -ldl
1650320293:136 : 272 : ==> AMI Action:
Action:Login
ActionID:1
Username:test
Secret:test

1650320293:136 : 464 : *** Initialized Asterisk Manager Interface ***
1650320293:137 : 480 : <== AMI Response: Response: Success
ActionID: 1
...
*** Successfully logged in to AMI on 127.0.0.1 (test) ***
1650320293:137 : 272 : ==> AMI Action:
Action:CoreShowChannels
ActionID:2

1650320293:137 : 480 : <== AMI Response: Response: Success
ActionID: 2
...
Current # of active channels: 2
Channel                                  | Duration | Caller ID
Local/s@wait4-00000000;1                 | 00:05:13 | <unknown>
Local/s@wait4-00000000;2                 | 00:05:13 | <unknown>
1650320294:138 : 246 : Since we killed the AMI connection, manually cleaning up
root@pbxdev:~/astrex/cami# make && ./cami test
gcc -Wall -Werror -Wno-unused-parameter -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -Wmissing-declarations -Wmissing-format-attribute -Wformat=2 -Wshadow -std=gnu99 -pthread -O0 -g -Wstack-protector -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -o cami -lm *.o -ldl
1650320294:860 : 272 : ==> AMI Action:
Action:Login
ActionID:1
Username:test
Secret:test

1650320294:861 : 464 : *** Initialized Asterisk Manager Interface ***
1650320294:861 : 480 : <== AMI Response: Response: Success
ActionID: 1
...
*** Successfully logged in to AMI on 127.0.0.1 (test) ***
1650320294:861 : 272 : ==> AMI Action:
Action:CoreShowChannels
ActionID:2

1650320294:862 : 480 : <== AMI Response: Response: Success
ActionID: 2
...
Current # of active channels: 2
Channel                                  | Duration | Caller ID
Local/s@wait4-00000000;1                 | 00:05:15 | <unknown>
Local/s@wait4-00000000;2                 | 00:05:15 | <unknown>
1650320295:862 : 246 : Since we killed the AMI connection, manually cleaning up
root@pbxdev:~/astrex/cami# make && ./cami test
gcc -Wall -Werror -Wno-unused-parameter -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -Wmissing-declarations -Wmissing-format-attribute -Wformat=2 -Wshadow -std=gnu99 -pthread -O0 -g -Wstack-protector -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -o cami -lm *.o -ldl
1650320296:409 : 272 : ==> AMI Action:
Action:Login
ActionID:1
Username:test
Secret:test

1650320296:410 : 464 : *** Initialized Asterisk Manager Interface ***
1650320296:410 : 480 : <== AMI Response: Response: Success
ActionID: 1
...
*** Successfully logged in to AMI on 127.0.0.1 (test) ***
1650320296:410 : 272 : ==> AMI Action:
Action:CoreShowChannels
ActionID:2

1650320296:411 : 480 : <== AMI Response: Response: Success
ActionID: 2
...
Current # of active channels: 1
Channel                                  | Duration | Caller ID
Local/s@wait4-00000000;1                 | 00:05:16 | <unknown>
1650320296:411 : 575 : <== AMI Event: Event: CoreShowChannelsComplete
ActionID: 2
EventList: Complete
ListItems: 2


(Callback) Received event
Event Received: CoreShowChannelsComplete
1650320297:411 : 246 : Since we killed the AMI connection, manually cleaning up

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.