I am trying to elaborate SIP messages coming to an Asterisk server and edit them on the fly using Java.
AMI is supposed to work fine with that. Although I can't send any SIP messages though the socket, cause every-time I tried to edit chan_sip.c the server breaks down. So I haven't find a way to access this information from other classes of the manager. I don't want to save those information to a file or database cause this will delay the whole process.
Using Kamailio is not an option cause I want to make a comparison of both solutions so I need Asterisk.
Is there any path I should follow to get this done? I can't figure why editing chan_sip.c bothers Asterisk making him nonfunctional..
Seams like no way with your qualification. Task seams really complex for me(i have more then 10 years experience, including asteirsk internal and c/c++ programming).Try do that using dialplan only
Related
I'm looking for some advice on best/common practices with writing a log for a game server I wrote in Java (first time with server/client concept and I've never done anything with logging). I've tried some Googling, but the keywords involved are kind of vague and not coming up with any answers to my questions.
I have a server with users, game lobbies, and games. I think that I should create a log to keep a history of everything that happens on the server. And in this log I think I should record status changes of both the server itself (startup, shutdown, commands being processed), and socket connections (new/lost clients, incoming/outgoing messages).
I'm not sure if that's the best thing to do, or instead/also have a log with more human readable messages like "Bob781 joined lobby #4." or "microman12 beat sun44 in a game."
Should I write logs to the console or to a file? (2 separate files?)
What formats are best or most commonly used? Should they be the same formats?
I've come across the "Common Log Format", is this the best format choice for socket connections? Can it be used for the server statuses?
Should I use something in java.util.logging or just output the strings myself?
You always want to look for existing solutions before starting from scratch. When you use/create the logging, I would suggest the following tips based on my experience
Make sure you can reliable retrieve the logs whenever you might need them.
Make it easy to find a log file based on what you're looking for. For example if there is a problem with a specific game lobby, you should be able to easily navigate to the file or directory of files that pertain to that game lobby in question. Nothing worse than having to parse a huge gigantic log file...
Make each logging message meaningful. Don't just log stuff for the sake of logging. You will want to be able to read a log message and know relatively where in the server code that message is coming from. This will help later down the road when you run into bugs in your server code.
Have each log message time stamped at the point it's created and not when it's written to the log file.
Hí,
I'm doing my second App, and The second one is a little bit complex, it's backup tool.
In some devices works perfect in others not.
I would like if is there a way to do my own Exceptions catcher to my server or log cats or smth, and receive them, and known if my app needs some fix or not etc.
Greetens and thanks
David
As pointed out, you can use ACRA. The site states:
Acra catches exceptions, retrieves lots of context data and send them
to the backend of your choice.
and that is what you seem to need. The Quick Setup Guide is there on the homepage itself.
You can also look into BugSense which you can use as a back end for your ACRA.
If you are using ACRA, you can use BugSense as your backend.
The only change you need to do is specify in formUri BugSense's url
and your API key:
#ReportsCrashes(formUri =
"http://www.bugsense.com/api/acra?api_key=YOUR_API_KEY", formKey="")
Basically i am trying to create a websocket based live chat for a few websites i work on.
the server i have up and working no bother running on the javax.websocket package on a glassfish server.
the standard HTML5 websocket interface i also have working no bother.
the problem is that about 10-20% or our users dont use an HTML5 compatible browser so i need a fallback. Do far the best option i can find seems to be running a swf as a middle man between the websocket server and HTML. The problem there being that action script doesnt support websockets as standard so im having to write my own wrapper.
So far i can connect to the server and perform a successful handshake, i can also receive messages from the server with no issues, the problem is sending messages.
I have had a look through https://www.rfc-editor.org/rfc/rfc6455#section-5.2 at the theory of the data frame for a websocket package and written an attempt at this, i have also looked through various other open source library's without any luck. What happens is whenever i send a message to the server i get a response of
RSV bit(s) incorrectly set.
and then the connection closes (as it should with the websocket protocol).
A large part of the problem i suspect is that this is the first time i have ever even looked at action script never mind attempted using it.
i was just wondering if anyone else had been having this problem/response and preferably has found a solution
in an idea world im looking for a tutorial that i could use to actually understand the creation of the frame better but i cant seem to find one :P
thanks
Matt
As it turns out it was just one of those bizarre bugs that happened for basically no reaseon, i ended up re-writing the section of code that manages the creation of websocket frames and frame fragmentation and it just worked.
ive had a few programmers look the the two examples of code including an action script developer and none of them can work out why the one snippet works and the other doesnt.
On the upside going back over the process has given me a better understanding of the protocol. If there is anyone else that has been having a similar problem feel free to get in touch and i will see if i can help you out.
I am to develop a mobile application for the Java ME platform that sends SMS messages, containing binary data. However, the application is to use a custom port for sending these messages (so that it can register itself and automatically receive these messages, instead of the standard messaging system of the phone).
My question is:
1) Are BinaryMessages to custom port widely supported in mobile networks worldwide? Or is this something "extravagant" that would work only with a few telecom operators?
2) Normal TextMessages tend to be broken down to multiple parts when their text exceeds the limit of a single message. Are BinaryMessages treated the same way, and if so, how can I deal with this issue (fragmentation) in my application? Obviously part of the message will not do the work and ideally I would like to get the full message when all of its parts are received. Is this dependent on the carrier network?
I realize I could test this out, but I can't run the test on many telecoms, just those in my (small) country, and this is crucial to whether this application should be developed, or not.
I tried looking for the answers by myself, but I failed. Sorry if these are trivial questions and thank you for your time.
I see nothing wrong with this question. I can only offer a semi-answer though.
It is true that it is up to the individual network provider to choose whether they want to keep all ports open, or not. Therefor you cannot assume that it's always possible to send/receive a text message or a binary message.
However, I was told by another JavaME developer long time ago, that it's very unusual for them to close the ports. (Aren't the same ports used for a lot of other protocols such as sockets and http? If yes, then surely they are always open. Closing them wouldn't make any sense).
If I were you I'd add some code to check if messages are sent, and then output some error message to the user about it if it fails. (If possible, also call some URL as a way of error-reporting back to you).
About the broken down messages, that's a good question. I have no idea. I would make some real-device tests to find out.
I'm trying to implement a Cometd/Bayeux server on Android using iJetty. The Jetty implementation itself works just fine serving static pages along with servlets. I am trying to up the ante a bit and create a Bayeux application on the phone but I'm having some trouble. I can hit the page that has the dojo cometd scripts on it, but I am unable to subscribe to the channel. When I view firebug/chome developer tools, I see a series of posts/gets that last a couple of milliseconds (~14). However, when I run a cometd application on a normal machine, the posts/gets last several seconds (~14 seconds) before timing out and reopening the connection. This second scenario makes sense to me with my understanding of how continuation in HTTP works. So I'm thinking that something is not allowing those connections to hang open and prematurely returning a value and consequently closing the connection. I would post my source but I'm not sure what to post short of posting everything...(it is open source though so if you want to have a look it's at http://webtext-android.googlecode.com).
So my question is, does anybody think that there could be some underlying limitation imposed by the Android system that is preventing these servlets from working? Are there assumptions that are made by the Jetty Bayeux implementation with regards to the underlying system? Or is it more likely that somehow I have a bad implementation of the ContinuationCometdServelt? I should note that all of the posts/gets from the client return 200 OK messages so I'm not inclined to think that the Android system is simply terminating the connection.
I know this is a bit off the wall and I'm definitely trying to do something a bit out of the ordinary but any suggestions or tips would be greatly appreciated.
In case anybody discovers this and has similar problems (this applies to all cometd implementations regardless of host), I discovered that the issue was with using the Google js library. For some reason, the dojo scripts I was loading from Google (1.4) didn't have a valid implementation of cometd. I switched my dojo script to the one that was used by the jetty-1.6.23 example and it works perfectly.