A requirement for the SIP PBX I created for my company was to record all calls passing through it. I solved it by forcing all SIP message to pass through the PBX and to modify the SDP body so the stream passes through it and gets recorded. It works well.
I recently found out that this is not allowed.
Is there any other way to implement call recording and how "wrong" is this in regard to the protocol?
It sounds like you're describing a SIP proxy, more or less a Session Border Controller (SBC). A proxy can modify SDP, though it should be careful in doing so. Typically SBCs will set the media destination to themselves, and proxy the data to the destination. So this is perfectly legal spec-wise (assuming the devices are already coming to your server).
However, "Not allowed" could also mean "recording calls is legally not allowed", which varies a lot state-to-state.
A more conventional way to implement call recording would be to capture the RTP packets on the wire and put them together to create an audio file. There are quite a few tools around to do exactly that and it's even inbuilt into Wireshark.
As far as tweaking with the SDP goes it's definitely not something that is "not allowed" at least not on a technical level. A lot of SIP Proxy's are forced to mangle the IP addresses in SDP when user agents put private IP addresses in them. You'll find most SIP servers out there have some sort of capability in this regard and it's often call NAT mangling or similar.
Related
I am referring to the c value of an SDP header.
Is it possible that the media stream address changes during a call? And it what scenarios?
It may be changed with re-INVITE or UPDATE. Some example scenarios:
PABX system consisting of multiple machines decides to route media through another media endpoint because of e.g. high server load or some other problem with this machine
after receiving FAX CNG, CED and/or modem preamble PABX passes the call to fax server
call is passed to specialized music-on-hold or IVR server
Also, addresses advertised in SIP headers or in SDP quite often are not matching real addresses used for communication because of NAT or misconfiguration - for best results B2BUAs often may ignore them.
IS there a way I can in user-space get notification about a packet being dropped at Layer-2 in 802.11.
According to my understanding what happens is, when a packet is sent out on the medium, there are Layer-2 ACKs which are received if it is delivered correctly (if not,it does the retransmission and ultimately drops the packet if not delivered after several retries..)
I want to be able to access this notification (in user-space)and change the behavior of packet transmission.
I want to be able to send the packet to another host from the FIB rather than dropping the packet.
I have read about libpcap libraries and netfilter hooks which allows me to capture packet and inject them back on the networking stack..
But I'm not able to find hooks (if any, for the wireless stack) to help me capture the packet notification in Layer-2.
Please correct me if I'm not understanding something correctly. Also, any heads-up or links to read would be great.
No, you cannot, at least not using the standardised sockets interfaces. 802.11 is a link layer, and the sockets API is strictly link-layer agnostic: unless it's going to work on all link layers, it's not in sockets. There are good reasons for that: the kind of cross-layer interaction that you envision has been tried many times, and it's always turned out more trouble than it's worth.
You didn't give us any details about the application — but the best solution is most probably to change your application-layer protocol to send explicit acknowledgments, and send your data over the fallback route when you fail to receive an ACK.
What is the purpose for using sip with VOIP ? is it just to know the remote ip address ?
If i know (by server) the remote IP address ,then established a direct TCP socket connection for call negotiation, and send the media over RTP protocol ,so am i still need sip protocol ? or how can sip help me here?
The Session Initiation Protocol does rather a lot more than find out a remote IP address/port/transport triple.
It lets two parties
negotiate the media streams (including codecs and transports) and
establish commonly understood extensions to the protocol.
It also describes how to build scalable infrastructure (proxies, using SRV and NAPTR records, back to back user agents), location services and a host of other details that go into making a voice (or any other kind of) call to arbitrary third parties.
then you have implemented a sip alternative. sip (session instanciation protocol) does just control the "phone call". if you want to do that on your own, why not? the only problem would be that there are many sip clients and just one (or few) clients using your protocol.
SIP allocates a IP:port to a voip call. The RTP flows (one for each direction) will then use this IP:port as a destination address. If you have only one static RTP flow to send to your server, it may be useful and ok to do what you said.
Otherwise, if there are many clients, or if your system has to change a lot, it's better to use a polished protocol which will dynamically allocate ports and establish your sessions.
nobody forces you to implement a standard.
e.g. why do you implement the media stream in RTP? most likely because you already have code that "talks" RTP (e.g. a library, or a raedymade application).
the nice thing about standards is, that it will work "out-of-the-box" with all other applications implementing the same standard.
if it is an open standard, there's another nice thing: other people have already spent a lot of brain power into getting the implementation right. you don't need to fall into the same problems.
I am still learning about SIP and all its protocols, specifically trying to integrate PJSIP into an iPhone application to make p2p calls.
I have a question about a peer 2 peer connection using PJSUA. I am able to
make calls perfectly to other clients on my local network by calling directly using the URI:
sip:192...*:5060
I am curious if this will work for
making direct calls to other SIP URIs that are not on the local
network without using server configuration - if not this way, is there another way of making p2p calls without server configuration?
thanks in advance,
You can make calls without server configuration, as a general principle, but something needs configuring. As mattjgalloway points out in the comments below your question, the most robust solution is a can of worms involving ICE which provides a kind of "umbrella" protocol for things like STUN.
Last time I touched this issue, I had the requirement that I couldn't use internet-based SIP servers to help. I came up with the idea of a registry of sorts: your client can define a bunch of "address spaces" with particular routing requirements. For SIP URIs in your LAN, you define no routing; for URIs in your company's VPN-accessed network, you define a route passing through your VPN connection; for everything else you define a route through your internet router.
By "define a route", I mean that when you place a call to a URI in some particular address space, you store what IP will go into a Contact header, what Route headers you might need, and so on.
Thus, the process of making a call becomes:
Look up in the set of address spaces for a match.
Ask that address space for the suitable bits needed to make a workable INVITE (appropriate Contact header details, Route headers, etc.)
Construct a normal INVITE, mutating as necessary for the previous step.
Send the INVITE as normal.
This essentially reproduces half of what ICE would give you, in a manually administrated form. "Half", because this ensures that one SIP agent can make calls such that the SIP routing all works. The missing half is you still need some kind of registrar somewhere, and each agent in your contact list needs to have the necessary setup to receive incoming calls. (If an agent's behind a NATting internet router, the router would need to either run a SIP proxy, or forward ports 5060, 5061 to a particular machine (which might be an agent, or a proxy serving the LAN's agents).
It is, indeed, a large can of worms.
The basic issue is to solve the problem of getting transport ports anywhere on the internet for multimedia traffic.
Many companies/experts have tried to solve this situation. A possible way out of is to buy a domain and setup a basic registrar using YATE or Asterisk on an address accessible from the internet and configure it to also use ICE as needed. Your iphone application at both ends could register automatically to it upon start. Then make P2P calls.
Actually We are doing thesis work where we need to make 10 voip phones which are SIP based connected with each other.So they can call and talk among each other.Also we want to add video calls access.Another question is it possible video calls on SIP.
SIP already has built in reliability measures, most of which are specifically to cope with unreliable transports such as UDP. You should read the section in the SIP RFC on Transactions to gain an understanding of how it works. One aspect missing from the SIP RFC is reliability for provisional responses and the supplementary RFC3262 deals with that.
SIP is agnostic to the type of sessions, such as voice or video, it sets up so yes it can be used to set up video calls. There are heaps of readily available SIP softphones around that already provide video, one example being x-lite.
To make it reliable you need to emulate the following two features:
For Calls
You need to sequence the packets.
One end needs to tell the other end that a sequenced packet is missing if this happens, and you probably want take jitter into account -- i.e., wait a small amount of time before you request a missing packet.
For protocol commands
You need to ackknowledge command packets -- if a command is not acknowledged it has to be sent again.