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..!
Related
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".
I'm using a PJSIP's pjsua dialer (based on pjsua_app.c, PJSIP 2.0.1) with TCP transport and a SIP trunk to make calls to a mobile phone. The dialer registers with a SIP Server over TCP and also sends out INVITES over TCP. UDP transport is not being used.
The environment is something like this -
PJSIP (behind NAT)<--- SIP over TCP ---> SIP Server <--- SIP trunk --> SIP trunk Provider <-- PSTN/Mobile Gateway-->Mobile phone
All calls are made from PJSIP over TCP to the mobile. To disable UDP transport creation I inserted a line "cfg->no_udp = true;" at the end of the function
"static void default_config(struct app_config *cfg)" in pjsua_app.c
I followed the instructions given here to make calls over TCP.
The problem is that we don't receive audio sent from the mobile end into the PJSIP dialer.
But RTP packets from the PJSIP dialer reach the mobile side just fine. We can hear audio in the mobile when the call is established.
We found from packet traces that the reason we dont receive media in the PJSIP dialer is that the SIP server is sending RTP packets received over the SIP trunk to a private IP address.
But when we switch to UDP for registration and send INVITES over TCP the call works fine (audio at both ends).
The wireshark packet capture shows the following -
1. PJSIP registers with server over TCP.
2. Server sends 401 with PJ's public IP and port in VIA
3. PJ registers again but inserts its public ip and port in the
contact header in the next REGISTER message sequence.
So far so good. Same sequence of messages seen when UDP is used to REGISTER.
4. INVITE sent over TCP. Dialog establishment works fine.
But in the record-route header nat=yes is missing.
5. Server sends media to private IP. No media received at PJSIP.
Is this a bug in PJSIP? If so how can this be fixed. Wireshark packet traces are available on request.
Your help and inputs are much appreciated.
Your question doesn't actually make sense as the transport of the signalling between the sip endpoint and the sip server (either UDP or TCP) has no bearing on the media transport between the two sip endpoints (most likely UDP). So there must be something else going on.
Since your talking about private IP addresses, I'm assuming you are coming from a behind a NAT over the internet to a "public" sip server.
In these types of environments I would recommend you setup STUN, TURN and ICE on the sip endpoint.
I would guess the UDP setup you where talking about has the STUN server setup and the TCP setup you where talking about doesn't.
Without further information I can't help much more.
Try to use port other than 5060 in both client and server, and/or reducing the SIP message size.
It seams this is a know issue for sending INVITE request over TCP in PJSIP.
Also you can find here some advices for reducing the SIP message size.
Please make sure that allow_contact_rewrite is set to true so that the media will be received to your end.
I think my answer is too late but this may help some other folks
I have to integrate the text, voice and video chat via SIP server into my application. So that I have chosen the "Peers" from http://peers.sourceforge.net/.
I have downloaded the code, registered a sip addressz(peers sip client) and call to another sip account(peers sip client). I can't receive a call in that peers client. If I call to another sip client(X-Lite), I can able to receive a call.
Can anybody tell me what may be the problem and how to fix?
when you want to call a remote party from peers you should use sip:user#domain.com where domain.com is the domain you used in your account. If you used an ip address in domain in your sip account, you should use the same domain.
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 :))
I am trying to make a gateway between SIP and XMPP domain. I have an environment with FreeSWITCH (with dingaling module) and OpenFire (FreeSWITCH is registered as a component in OF). Calls from XMPP to SIP are working fine. The problem appears for calls from SIP to XMPP. The caller (SIP) has a ringing tone, the callee (XMPP) has a 'connecting...' message after answering the call. The connection (voice channel) is never established.
Do you have any experience in making calls between SIP and XMPP users and have an idea, why it is not working?
Thanks in advance,
Maciek
Enable debug in mod_dingaling and mod_sofia and look for XMPP/Jingle errors.
However I suspect NAT/Firewall/Connections issues for this half-working behaviour.