Latest Sofia-Sip responds automatically with 200 to incoming INFO - sip

i am using the sofia-sip library (an open source, cross-platform SIP stack) and what i see is that it responds automatically to incoming SIP INFO even tho' the INFO messages belong to a SIP dialog that has already been destroyed... has anyone experienced the same issue?
Previous version of the library did not seem to show this behaviour.

I'm not sure about any change in behaviour in Sofia-SIP between releases.
If you want to control SIP method handling in your application, rather than letting Sofia-SIP automatically respond to it, then at initialisation you should call nua_set_params() and pass it NUTAG_APPL_METHOD("<METHOD-NAME>"), e.g. NUTAG_APPL_METHOD("INFO").
If you have further questions, you may want to ask on the Sofia-SIP mailing list.

Related

Handle timeout of GNotifications in Gnome?

My program needs to react to the user not taking any action on a GNotification.
More specificially, a piece of data is written to the database only if the user does not press the "undo" button on the notification sent after the data's creation. My target deployment scenario does have notifications enabled and a real timeout value.
To be precise: Moving the notification "away" / deleting it should also count as such a timeout.
1) Is there a built-in way to 'listen' to notification timeouts?
2) If not, how could I still implement similar behavior?
I would use the D-Bus org.freedesktop.Notifications interface. Although it is still a draft specification, it does appear stable. My experience accessing the D-Bus interface using Vala has been that it is easier to use and gives the full feature set of the specification. GNotification doesn't seem to be as feature complete.
From the draft specification you will see there is an expire_timeout argument of the org.freedesktop.Notifications.Notify method. That should fit your time out requirement, although I've not used it personally. There is also a org.freedesktop.Notifications.NotificationClosed signal that will allow your program to be notified when the notification is closed, including because of a time out or if it was dismissed by the user.
This post about the screen lock re-design for GNOME Shell 3.10 might give some indication of what notifications are capable of. The post includes some screenshots of notifications appearing in the lock screen.

Eclipse Scout Neon Message box triggered on server side

I am wondering if there is a way to trigger message box on server side.
My case is that I have some logic on server side of the scout application. In the middle of the process some decision need to be made. It this case I would like to trigger message box with YES, NO, CANCEL options.
The way my logic works it really hard to split it into two functions and call one first, ask question and call another with on answer. So this is out of the way for me.
If it is not possible to triggered message box on scout service, is there a way to "mimic" it. So call service method, in the middle pause it, go to client side, present messsage box, return to same service method and continue it.
Why do I need this:
I have dependencies graph (between fields) implemented on scout server side.
After one field has been changed, the whole dependencies graph will be resolved.
One node of the graph has some logic that need user interaction. Problem is that I don't know if this method will be called (dependent on a graph), and if after this method other nods will be called.
You have asked a very similar question few months ago:
Scout Eclipse present optional message on server side
MessageBox is a client concept (package is: org.eclipse.scout.rt.client.ui.messagebox).
You need to transfert the data you need from the server to the client and intercept this information client-side to display the message box you want.
As Jmini already said, MessageBox is a client concept. What you can do is sending back a status (from server to client), checking it on client side and show an appropriate message (box). But then you interrupt your service method and cannot go on where it stopped (alternatively you can throw a VetoException, but this interrupts your service method aswell, so same problem). In my opinion, it is also not a good design to 'request' a user interaction from server side, because in this case, the server side has to wait for the user to respond.
I suggest, if possible, to split your logic into different parts. At first, you execute the first part until you reach the point where you need the user interaction. Then you could save the current state of execution, return to client and show the message. After the user has responded, you should start the 'second' execution, depending on the user's input. This second execution should be started by calling another (new) service, which at first should load or restore the state of the execution saved before requesting the user input.

how to get queue information from asterisk

I am running asterisk on a elastix 2.2 distro. I have a Queue with EXT 9000 where 3 softphone (c#) extensions belong to this round robin queue.
I know that I could trigger a AGI or AMI event from the dialplan and let in some way a webservice know about the length of the queue and then forward this information to the softphones.
Is there any way that the softphones could get this information directly from asterisk. Either something AsteriskBuiltIn or ElastixBuiltIn.
a last resort (baaaaaad) idea was to open a line, call an encoded number like (555*1) and receive back a dtmf. it is a Bad Way but it would work.
Open for any suggestions
Queue drop events into ami.
Also queue log all actions into /var/log/asterisk/queue_log, which is posible put to mysql(see this)
There are no way say how your softphone can catch that event. But for sure you can get that info from mysql and rewrite your softphones to show that info.
Also elastix call center edition have web panel for call center. As option you can check fop2 project for panel.

jain-sip /jsip getListeningPoint method was removed from RequestEvent and ResponseEvent

I have a JAIN-SIP project with one SipStack, multiple SipProviders each with one ListeningPoint. In earlier versions of the sip stack, when a request/response come in, I could just call: requestEvent.getListeningPoint().getIPAddress(), but the getListeningPoint() function was removed. How am I supposed to find out, to which ip address and port the request come in?
Look at the event source i.e. Event.getSource() of the event delivered to your listener method.

Quickfix or Quickfix/n, through which message type are custom U1, U2,....,Un messages identified?

I cannot find anywhere how to manage custom U-type messages. I use MessageCracker and need to understand the corresponding OnMessage method signature. For example my broker sends custom U1,U5, U2 messages, how can I capture those incoming messages inside a OnMessage method? I understand that Tag35 identifies those but if I cannot capture them through OnMessage then MessageCracker becomes kind of useless and I need to identify each message by Tag35 within FromApp or FromAdmin. Any suggestion how to handle those kind of custom U-types?
Thanks
Ah, custom messages. Fun stuff.
You need to add your counterparty's customizations to the DataDictionary xml file. Choose the appropriate FIXnn.xml file for your FIX version.
See here: http://quickfixn.org/tutorial/custom-fields-groups-and-messages
Then, because you are adding custom messages, you'll want to regenerate the QF/n source and rebuild the library so you can get classes for your new messages.
Instructions for rebuilding are here: https://github.com/connamara/quickfixn
You'll need to install Ruby. This annoys some people, but we haven't found any more-windows-oriented code-generator that we don't hate. Sorry in advance.
(If you were just adding fields to existing messages, you could probably get away with not rebuilding. But you're adding messages, so you pretty much have to regenerate/rebuild.)
To Windows developers, it may seem annoying that rebuilding the library is required, but it really is the norm for all the QF engines. FIX is just too fudgey a protocol for a single build to satisfy everyone, because it seems that every counterparty likes to screw with the message definitions.