Is there a SIP/VOIP-agnostic way to know when a phone goes offline? - sip

Working on a SIP application that requires monitoring call activity/state on a phone. My app (UA) is registered with a proxy server, as is the phone being monitored. I am making use of SUBSCRIBE/NOTIFY messages to tell the phone that I want to know about its "dialog" events, and once subscribed, this works fine. I am running into two problems:
I am requesting a subscription length of 900 seconds and consistently getting some absurd amount of 4000+ seconds returned from the phone.
There is the possibility that the phone may be unplugged while the subscription is active (don't ask, but, yes, this is a possibility). When this happens, I am not getting any type of notification as to the phone no longer being available. Consequently, I have to wait for my subscription to time out, try and renew it, handle the failure, and create a new subscription.
I realize that I can renew my subscription sooner than its expiration time, but is there a better way to go about it? For example, would I be able to get "presence" events and use them to know when the phone is there or not? Are those events always guaranteed to happen on phone start-up, and even so, since there is a proxy in the middle, would I even get the notifications, or would I still not know that the phone restarted and no longer recognizes my subscription(s)? Are these "presence" updates something that I can request from the proxy?
Any insight would be great; for the moment, I'm going to simply try and refresh my subscription on a much smaller interval, but I would love to know if there is a better way to go about it. Thanks in advance.

I don't know about a SIP agnostic way other than perhaps somehow pinging the phone but there is definitely a SIP way to do presence and that's using the same subscribe/notify model you are using for dialogs but in this case for presence. The relevant standard is RFC 3856 A Presence Event Package for the Session Initiation Protocol (SIP).
Typically the presence notifications would be generated by a SIP registrar, and since you say your phone is registering with your proxy it must also have a registrar built in. The registrar would notify your UA when the other phone's registration status changes such as when it first came online or when it failed to re-register. As far as the delay between a phone "disappearing" and the registrar server detecting it there's no prescribed way to do it. You can either wait for the registration period to expire and mark the phone as offline when it fails to register or alternatively the server could actively send a packet or even a SIP request such as an OPTIONS request to the phone and mark it as offline if it got a failure response, Asterisk uses te latter approach.

When a SIP UAC client registers with a SIP UAS Registrar, the SIP client provides a Expiry Header, which indicates that maximum amount of time after which a SIP client needs to re-register itself. If the SIP client does not re-register itself in this time period, then Sip UAS proxy/registrar server will mark the client as disconnected.
Proprietary SIP packages like FreePBX and Asterisk, proactively, send SIP OPTIONS to the client, continuously, at some interval, wherein the client responds with OK. This is a more proactive way of validating if SIP clients are online; however, this technique is proprietary and not part of the actual SIP specification.

Related

Initator and acceptor logout order in Quickfix

When I have a FIX session between acceptor and initiator which side in general should be sending logout message first?
Also, is it fine to set session times on acceptor and initiator side to the same hours? Or maybe initiator should be configured for the shorter period to keep the communication safe and clear from errors?
Based on real project experience,
The connection was post trade feed, where our post trade gateways
used to connect with ECN (Electronic communication networks) like
Bloomberg, Tradeweb etc.
The ECN used to act as Acceptor and our gateways used to act as
initiator.
As initiator, its our gateways responsibility to initiate the
connection with ECN by sending LOGON message.
The gateways used to send LOGON and LOGOUT half an hour before/After
the markets open & closes respectively.
But in case there is some problem/error, even ECN used to send a LOGOUT message.
So, there is no hard and fast rule, who should send LOGOUT message.

How to intercept / observe SIP traffic through fiddler or wireshark?

I am using a free caller android app and they restrict me with limited credits. I would like to explore more about how this app works. So I started decompiling the APK file and intercepting networking requests using Fiddler.
I intercepted requests, but none of those are creating the actual call. So after decompiling the APK I understood they are using SIP server for calls. I couldn't intercept any SIP call with fiddler or wireshark.
They are using this SIP server : https://www.kamailio.org/
Kamailio is one of the powerful SIP Servers and they have good documentation and big mail-user list. You can check their wiki:
http://www.kamailio.org/wiki/
For understanding this case first you should learn "how voip works" subject. You already can not inrecept any SIP call with fiddler or wireshark. Generally, SIP server managers hide their topology for security reasons. Thats why you can not observe SIP traffic to the end of the tunnel.
Even Kamailio has its own module that provides hide your network topology with one click :)
https://www.kamailio.org/wiki/tutorials/tls/testing-and-debugging#decoding_of_tls_connections_with_wireshark
If they can limit your credits, then, of course, they will authenticate your every call and reject it if you don't have enough funds (or out of quota).
So, if you learn a little bit about SIP technology - perhaps, you'll be able to send a call request even without a dialer, but I doubt that the call will be authenticated.
An analogy: if you know a full path to some restricted page - you can paste it into the browser's address field and go there, but if you are not logged in, then you will still get an error like "you're not allowed to read this page".

Keeping SIP registration alive for interval less than 600 seconds in iPhone VOIP app

I am implementing a VOIP application in which I work with SIP protocol. As per SIP I need to refresh my registration with SIP server at certain interval. But when my app goes in background, my keepalive handler is invoked only after 600 seconds as per documents os Apple. But this is not desired with SIP protocol. To be able to keep my connection alive with server and receive incoming call, I need to send registration message before 600 seconds even when app is in background. According to Apple documentation this is not possible but stilll I have seen apps on AppStore which runs in background and keeps their registration on with SIP server even when registration interval is 60 seconds. They keep app running in background throughout. So how is this possible? I know that playing silent audio in background will survive but then AppReview process will reject it. But if its so, how Apple allowed other such apps on AppStore? Is there some standard way to achieve what I have described above? Any help is appreciated.
You don't have to send the registration more often. You can do something like this: configure your server to send keep alive packages to your sip client in order to keep the TCP connection open. Your server should support TCP connection and your client should communicate over TCP since apple is very restrictive in background mode and only the TCP connection is allowed to remain open in the background (if your TCP socket is wrapped with CFReadStreamRef).
The problem is no the registration message, this can be configured by the client by specifying the time between the connection attempts, and the sip sever will be fine with an interval of one hour between 2 registration messages. The real problem is how will the server contact the sip client in case of an incoming call or IM. Most of the sip clients will not have a public IP adress but most probably they will be behind a NAT. So there is no way the sip server can open a direct connection to the sip client, for this reason you have to keep a socket open between your client and the server.
None of the app in the appstore is sending registration message more often than 600s.
Do you use your own library for sip or you use pjsip? If you use pjsip i can give you more hints. What SIP server do you plan to use?
Some hints:
make sure you set in your app-info.plist the required background modes to "App provides Voice over IP services" and "App plays audio"
in case your app will not be tied to your own sip server then provide a way for the user to disable the allow_contact_rewrite pjsip param (usually u want this to be enable for bypassing the nat problem) since some session border controllers are not happy about this feature
make sure, in case you capture the messages send form the sip thread in your main thread, you are using a method to post them in the main thread
here are described some other interesting issues
have a lot of coffee prepared :))

Is that possible to use SIP in LAN network?

I don't know enough about SIP. As far as I know SIP can not be used in LAN. But it's features are very good. I want to use it for a LAN messenger (with video conference facilities).
Is there any way of using SIP in LAN network ?
The SIP protocol can be used over any reliable transport (TCP, XMPP, instant messaging channel, etc...) to a service (e.g. a server such as a SIP proxy) that knows how to route the SIP INVITE message from the caller to the callee. e.g. If you send an INVITE to bob#foobar.com, there's needs to be a service that knows how to find "bob" and deliver the message. Likewise, when Bob sends back his response messages back, the messages need to route back to the caller who sent the original INVITE.
And you can do SIP without a server - provided the computer already have a connection (direct or indirect) to the other computer intended for the call.
But SIP isn't anything special. If you were to invent your own video conferencing protocol, it would probably look a lot like SIP. SIP's primary job is for both sides of a call to exchange IP/port candidates for connecting directly in addition to codec and bandwidth negotiation data.
After the SIP messages are exchanged, ICE/STUN/TURN take over and RTP packets typically flow. SIP isn't used in the call except to end the call.
What are you really trying to do anyway?
Thread is Old but still I would like to contribute to this. There are various SIP server like http://www.officesip.com/index.html which works in LAN and can be connected to hardware phone too and soft client also.
Jitsi is open source cross platform SIP/xmpp client:https://jitsi.org/
And if you want to XMPP server Openfire is the best:http://www.igniterealtime.org/projects/openfire/
I hope this will definitely help someone..!

Send XMPP message without starting a chat

I am basically writing a XMPP client to automatically reply to "specific" chat messages.
My setup is like this:
I have pidgin running on my machine configured to run with an account x#xyz.com.
I have my own jabber client configured to run with the same account x#xyz.com.
There could be other XMPP clients .
Here is my requirement:
I am trying to automate certain kind of messages that I receive on gtalk. So whenever I receive a specific message eg: "How are you" , my own XMPP client should reply automatically with say "fine". How are you". All messages sent (before and after my client replies) to x#xyz.com but should be received by all clients (my own client does not have a UI and can only respond to specific messages.).
Now I have already coded my client to reply automatically. This works fine. But the problem I am facing is that as soon as I reply (I use the smack library), all subsequent messages that are sent to x#xyz.com are received only by my XMPP client. This is obviously a problem as my own client is quite dump and does not have a UI, so I don't get to see the rest of the messages sent to me, thereby making me "lose" messages.
I have observed the same behavior with other XMPP clients as well. Now the question is, is this is a requirement of XMPP (I am sorry but I haven't read XMPP protocol too well). Is it possible to code an XMPP client to send a reply to a user and still be able to receive all subsequent messages in all clients currently listening for messages? Making my client a full fledged XMPP client is a solution, but I don't want to go that route.
I hope my question is clear.
You may have to set a negative presence priority for your bot..
First thing to know is that in XMPP protocol every client is supposed to have a full JID. This is a bare JID - in your case x#xyz.com with a resource in the end e.g. x#xyz.com/pidgin or x#xyz.com/home (where /pidgin and /home are the resource). This is a part of how routing messages to different clients is supposed to be achieved.
Then there are the presence stanzas. When going online a client usually sends a presence stanza to the server. This informs about e.g. if the client is available for chat or away for lunch. Along with this information can be sent a priority. When there are more than one clients connected the one with the highest priority will receive the messages sent to the bare JID (e.g. ClientA(prio=50) and ClientB(prio=60) -> ClientB receives the messages sent to x#xyz.com). But there are also negative priorities. A priority less than 0 states that this client should never be sent any messages. Such a stanza might look like this
<presence from="x#xyz.com/bot">
<priority>-1</priority>
</presence>
This may fit your case. Please keep in mind it also depends on the XMPP server where your account is located, which may or may have not fully implemented this part of the protocol.
So to summarize: I recommend you to look through the Smack API how to set a presence and set the priority to <0 for your bot client right after it connected.