I am beginner to freeswitch.While learning this I have seen the terms 'leg A' and 'leg B'.
I didn't understand about this.So please explain me about this.
Thanks in advance.
Leg is a connection (between equipments). In a network diagram, a connection look like a leg.
This has some nice information as well:
https://freeswitch.org/confluence/display/FREESWITCH/Call%20Legs
-MC
Some of the FreeSwitch DialPlan tools like transfer or blind transfer user notions of
leg A - as a person who dialed (caller)
log B - as a person who was dialed (callee)
As a good example is bind_meta_app
So for example you can execute some command or do an action if a key was pressed by (caller (leg) a or callee (leg) b or any leg in this case caller or callee ab)
Related
I have researched on the FreeSwitch official website.
I want to develop a task based on FreeSwitch, while I cannot find one API.
What I have already done is I let my program to dial a 4 digit number and set up a conference, then other clients could dial this 4 digit number to enter the conference. But I need another function, which is when a client is speaking, I want to get who is speaking.
I have researched a lot of the FreeSwitch official website and cannot find the answer. If I google "How to get who is speaking in FreeSwitch", and I cannot find something useful. Can any one please provide me some solution?
if you use mod_esl to listen for events. one of the attributes is 'floor', and there are floor-change and video-floor-change events you can listen to.
Start with an ESLConnection Object
bear in mind i'm terrible with freeswitch and feel your pain, so take what i say with a pinch of salt
I was going through the Mellanox driver (mlx4) and then I had difficulty understanding which portion of code corresponds to the one executed by the PF(Physical Function Driver) and which portion of code by (Virtual Function Driver) in the SRIOV mode.
My confusion is because, I was of the understanding that the QPs, CQs (and their creation, state mgmt commands) etc are to be performed by the virtual function driver(VF driver).
And the role of the physical function driver(PF driver) is to just take care of the resource_tracker.c and ICM allocation.
But of late, I think I may have understood wrong. This is because there is code that is specifically executed when mlx4_is_master is true/false( indicating PF or VF).
And then, there is code which is not surrounded by this test, which indicates it is executed in both cases(PF driver as well as VF driver).
Is my understanding correct? If yes, then are the QPs, CQs and ethernet tx, rx related functionality is executed both by master and slave?
Is there any way we can clearly separate the files that are used by PF vs the files that are used by VF in the (drivers/net/ethernet/mlx4 sub-directory)?
I would be really thankful and really appreciate all the help/clarification I can get in understanding this.
Thank you so much.
Best Regards,
Bob
If anyone is interested, this question was also posted and answered here:
http://linux-pci.vger.kernel.narkive.com/mxQuEb2w/mlx4-query-regarding-pf-vf-functionality-division
Would you guys know a diagram or dable that would give a short & concise but nevertheless complete and relatively up-to-date view of the existing protocols, and their specifics ? (namely : ZeroMQ, Rendez-Vous, EMS, ... All of them! :) ).
This one is about open source solutions only : http://blog.x-aeon.com/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/
No love for the commercial ones !
Message oriented middleware is a big topic, there are probably more than 50-100 different implementations around. And unfortunately everyone putting together a list has an agenda (like presenting his product or his favourite in the best light). To simplify your search, however, it might help to ask yourself these questions:
JMS or not ? (EMS yes, Rendezvous no)
Brokerless ? (ZeroMQ yes, no on the others)
Free or commercial ?
And once you know more browse through some blogs, for example: https://bravenewgeek.com/dissecting-message-queues/, http://supercoderz.in/amqp-zeromq-jms-tibco-rv-and-so-on-which-messaging-system-to-use/ or checkout Which JMS implementation do you use? - my agenda ;-)
Is "Application Definition Statement" the correct term for the plan/idea stage that gets written down of user interface design? I mean before you even reach the stage of sketching > wireframing > prototyping.
And i also mean before any contact with the target market, i guess you could say the hypotheses stage.
And i mean with regards to myself doing this for a web application of my own and not when its for a client.
For a few days i have thought that it was called Requirements Definition but having looked at http://www.apple.com/business/accelerator/plan/define-your-app.html i think that Application Definition Statement is what i should be calling it, im looking for confirmation/correction on this.
To clarify too, its for a web application not iphone or ipad its just that while im searching to find the right name i keep landing on apple.com at various pages, lol
I believe this is called the "I've got an idea" stage. Which is to say: you're so early that it doesn't have a name, and it doesn't really need a name yet. It's not like someone's going to knock off points if you don't use the Correct Name for where you are as you're thinking through what might become an application.
Requirements definition is later in the process, after you've had some time to let your idea gel into something that could become an application. Requirements definition is when you start to solidify your idea into something that will eventually get completed, and when you break down your idea into small manageable chunks (and eventually prioritize those chunks) that can be worked on.
Apple's term of "Application Definition Statement" is okay for stage, although I think that it's a rather grandiose term for something that you haven't started sketching out or researching or anything. "I've got an idea" sounds like it's more descriptive of where you are.
I was wondering what the general consensus on error messages was. How detailed should they be?
I've worked on projects where there was a different error message for entering a number that was too big, too small, had a decimal, was a string, etc. That was quite nice for the user as they knew exactly where things went wrong, but the error handling code started to rival the actual business logic in size, and started to develop some of its own bugs.
On the other side I've worked on a project where you'd get very generic errors such as
COMPILE FAILED REASON 3
Which needless to say was almost entirely useless as reason 3 turned out to mean a link error.
So where is the middle ground? How do I know if I've added descriptive enough error messages? How do I know if the user will be able to understand where they've gone wrong?
There are two possible target audiences for an error message, the user, and the developer.
One should generally have the message target the user.
o what is the cause of the problem.
o why the program can't work around the problem
o what the user can do to work around the problem.
o how to report the problem.
If the problem is to be reported, the report should include as much program context information as possible.
o module name
o function name
o line number
o variables of interest in the general area of the problem
o maybe even a core dump.
Target the correct audience.
You should communicate what happened, and what the user's options are, in as few words as possible. The longer the error message is, the less likely the user is to read it. By the same token, short error messages are cryptic and useless. There's a sweet spot in terms of length, and it's different for every situation.
Too short:
Invalid input.
Too long:
Please enter a correctly formatted IP address, such as 192.168.0.1. An IP address is a number used to identify your computer on a network.
Just right:
Please enter a valid IP address.
As far as code bloat is concerned, if a little extra code will prevent a user from calling support or getting frustraited, then it's a good investment.
There are two types of error messages: Those that will be seen by the user and those that'll be seen by the programmer.
"How do I know if the user will be able to understand where they've gone wrong?"
I'm assuming that those messages are only going to be seen by the user, and not a very technical one, and COMPILE FAILED REASON 3 is not a typical end-user error message. It's something that the programmer will see(the user doesn't usually compile things).
So, if it's the user that'll see it:
Provide a short "This is an error message"("Ops! Something went wrong!", etc.)
Provide a small generic description of the error ("The site you're trying to connect to seems to be unavailable"/"You don't seem to have enough permissions to perform the XYZ task"/etc.)
Add a "Details>>" button, in case your user happens to understand computers well, including detailed information(exception stack trace, error code, etc.)
Finally, provide some simple and understandable commands for the user ("Try again", "Cancel", etc.)
The real question about error messages is if they should even be displayed. A lot of error messages are presented to a user but there is NO WAY for them to correct them.
As long as there is a way to correct the error then give enough information to the user that will allow them to correct it on their own. If they are not able to correct it on their own is there any reason to tell them the technical reason for the crash? No just log it to a file for troubleshooting later.
As detailed as they need to be ;)
I know it sounds like a smart ass answer but so much of this depends on your target audience and the type of error. For errors caused by invalid user entry, you could show them what constitutes a valid entry. For errors that the user can't control, a generic "we're working on it" type message might do.
I agree with Jon B's comments regarding length as well.
Error messages should be detailed, but clear. This can be achieved by combining error messages from multiple levels:
Failed to save the image
Permission denied: /foo.jpg
Here we have two levels. There can be more. First we tell the big picture and then we tell the details. The order is such that first we have the part understood by most and then the part less people understand, but both can still be visible.
Additionally there could be a fix suggestion.
I would err on the side of more detail, but I think you answered your own question. To avoid the bloat in code then provide useful information in the code/error message but you can give more details in the documentation perhaps or with help files or FAQ.
having too little information is worse in my opinion.
If you are using a language with rich introspection or other capabilities, a log witht he line that failed a check would be useful. The user can then forward to tech support or otherwise get detailed information and this is not additional code bloat, but using your own code to provide information.