I'm writing simple SIP-proxy application which stands between Astreisk and SIP client (any softphone). The purpose of the application is to calculate the duration of the call.
Below is example of regular flow:
Client sends INVITE to SIP-Proxy, SIP-Proxy resends INVITE to Asterisk
Asterisk answers with 200 OK, SIP-Proxy resends 200 OK to client.
Client answers with ACK, SIP-Proxy resends ACK to Asterisk
Whenever one of the parties sends BYE, conversation should be finished.
On step 2 I assumes that call is started (e.g. rtp media flow is started). Then I wait for BYE message to calculate duration of the call. However I noticed that some clients never goes to step 3 and 4. No call end notification received from any parties after step 2. And duration of such call is infinitely.
What is the best way to find out start/stop time of the SIP call without sniffing RTP flow ? Should I wait for step 3 to mark the start of the call ? What if client omit ACK or what if UDP datagram with ACK is missed in the network ?
For now I used to think there is no reliable way to figure out that SIP call is started. Maybe I should use Astrisk channels API instead to track active calls.
Another option is to generate a RE-INVITE to test the existence of the Session. Dont have to negotiate a timer or anything. Just using re-invite could help. Reuse the SDP to ensure that no media changes happen. But then your application is moving out of being a Proxy in the path of the call to being a application server.
Also the duration can only be capped to nearest interval for this re-invite request and not necessarily the exact time the call was released.
Your problem seems to be at SIP level, because your proxy does not add itself into the message path using a Route header. This process is called Record Routing. If doing so, all subsequent requests in your dialog will also traverse it (ACKs and BYEs included).
You should not reinvent the wheel by writing a SIP proxy. For example, you could use a open-source, flexible, powerful and completely customizable SIP Proxy in order to build any possible scenario you could think of: OpenSIPS!
Related
I am using InfiniBand/RDMA for this. My client machine is sending a block to the server (via RDMA Send), and I want the client to get back a special 8 byte acknowledgement. I know the server could send it along separately, but that would duplicate work since my understanding for RDMA Send, the NIC is already sending some form of ACK via the completion queue. However, I was looking at InfiniBand docs, the completion queue doesn't seem to have an immediate along with it, just an id (which is itself less than 8 bytes, so there aren't any funny tricks I could play). I was wondering if I could get suggestions on how to do this?
Thank you!
I'm not sure I fully understand the question, but on the client side, a completion queue entry will be generated when the send work request is fully executed. "Fully executed" means that the RDMA-level ACK has been received from the server in your case. The work request ID in that completion entry is indeed 64 bits, and it is common to use it for a pointer to an auxiliary structure holding whatever info you want for the work request.
If you want the server to actively send back some data that it chooses after it receives the send from the client, then I don't think there's any way around having the server post a work request to do that.
I am in a process of learning and trying to use the RTP/RTCP protocol. My situation is that there is 1 to n streamers and 1 (or potentially 1 to m if needed) receiver(s), but in a way that the streamers themselves do not know about each other (they cannot directly due to technical reasons, such as different network, limited bandwidth, etc...). So it is more like multiple unicast sessions, but the receiver actually knows about them all, collects data from all of them, it is just the senders do not know about each other .
Now reading about the protocol, it seems to me that huge portion of it is related to sending some feedback, collision detections, and so on. So I have doubts, is RTP is really applicable in this case? Is is already used in this way somewhere?
Seems to me it is still beneficial to collect statistic about data transfer that RTP provides (data sent, loss, times, etc...), it just feels the most of the protocol is sort of left out...
Also I have one additional question, going through the various RTP libraries, they all assume that sender will also open ports for receiving RTP/RTCP data, does RTP forbid use of one way communication? I mean application that would only stream the data, not expecting to receive anything back. The libraries (e.g. ccRTP) seem to assume both way communication only...
RTCP is the protocol that provides statistics. The stream receiver (client) will send stats to the sender (server) via RTCP. I don't believe the client will get any statistic reports from the server.
There's nothing wrong with a single client receiving multiple unicast sessions from various servers.
RTP requires two way communication during the setup process. Once setup is complete and the play cmd is sent, it is mostly one way. The exception are the "keep alive" packets that must be sent to the server periodically (usually every 60 seconds or so) to keep the stream going. The exact timeout value is sent to the client during the setup process.
But if you implement your own RTP, there's nothing stopping you from having the server send the stream continuously without any feedback from the client. Basically it would be implementing an infinite timeout value.
You can read about all the details in the spec: RTP: A Transport Protocol for Real-Time Applications
SIP over UDP: It's necessary to have SIP response "100 Trying" for SIP over UDP to shut the Timer-A off that would have been started by caller and hence stopping the re-transmission of the SIP message. Its really important because other responses (provisional and final) might take a while for initial INVITE message as we have to consider the scenario of forking, UE-B not reachable, fallback... etc It might take some time.
SIP over TCP: Timer-A will not be started by caller and thus no re-transmission of message. TCP being reliable, not re-transmission required. Even then, why do most implementation sends 100 Trying over TCP ???
There are few reasons that 100 Trying is still needed for SIP over TCP.
Having a TCP Connection does not guarantee that the SIP Application is working or if its a SIP - Aware application at all. The 100 Trying provides you the feedback that your request is being processed by a SIP Application.
The lack of 100 Trying can also be the right trigger for not just re-transmissions but to re-attempt to maybe a different server in the configuration. You may not want to elapse 32 seconds for every Server in configuration even when the connection is TCP.
In deployment scenarios, if there are elements like a SBC or Load Balancer, the TCP Connection is established with them. The Application behind it can be a different entity and usually these edge elements pass on all messaging or generate messaging to indicate the call in action state.
Probably because it makes the SIP stack implementation easier. It makes life easier if the SIP transaction layer is the same irrespective of the SIP transport that is used. If the transaction layer has different rules for different transports that's extra code for no real benefit, i.e. the bandwidth save by not sending the 100 Trying response is negligible in the scheme of things.
I'm using Asterisk 11, a Cisco SPA303 Phone, and Twilio.
I can make outgoing phone calls without any issue and the call quality is top notch. On an incoming call however, my extension (and phone) ring, however when I answer the phone, there is no audio on either end and 30 seconds later, both calls end. Using Twilio's PCAP log, it shows that my asterisk server sends a BYE when answered. Asterisk however does not log a single thing on incoming calls. (All SIP traffic is logged on outgoing calls). Does anyone have any idea what's going on?
Update:
Turns out that I had my incoming extensions in the wrong context, once that was updated, incoming and outgoing calls worked without a hitch. I marked #arheops as the answer because the logging of unanswered calls lead to the diagnosing of the problem.
Very likly(but you not informed) your asterisk installation is after NAT.
IF so, you have configure asterisk as described in http://www.voip-info.org/wiki/index.php?page_id=410
Also may need change ports on router/disable SIP ALG on router etc.
Logging(you mean cdr,right?) is controled by /etc/asterisk/cdr.conf
Most likly you have ananswered=no in that file.
Is it possible to perform many SIP transactions in parallel, for a UA with two other UAs? Fpor example, if UA1 is in the middle of an INVITE, can UA1 respond to an incoming INVITE from UA3? What about standalone transactions?
There's nothing in the standard that prevents a SIP device from handling multiple concurrent transactions and in fact SIP servers need to do so in order to be able to handle any kind of load.
As to how a SIP user agent should handle concurrent SIP transactions that's a separate consideration. IF UA1 is already on a call and a new INVITE request comes in from UA3 the typical way to handle it is with some kind of call waiting indication. With a softphone that indication can be visual whereas with an ATA that indication is often on the audio channel by injecting some tones into the UA's audio stream.
For non-INVITE transactions it will generally be a lot simpler since most don't require any user action. For example the UA could maintain half a dozen different registrations with different SIP servers and the various register and/or subscribe transactions (in this case the transaction is simply the combination of the request and response) could be running concurrently.
There's another SIP parallel transactions "gothca-to-watch-for" too...
Within a sip dialog, if there are multiple UAC transactions started within a short space-of-time (~0.5s) and your transport in unreliable (UDP), there is a possible problem if the initial request packet is lost.
Lost packet with sequence number (CSeq) 'n' doesn't arrive, but the next packet does, containing CSeq n+1.
This is acceptable at the receiving (UAS) side, and it updates its knowledge of the "remote cseq" to 'n+1'.
The initial request is then resent, but CSeq 'n' is now lower then the remote-cseq, so MUST be discarded and the UAS responds with a (500 Server internal error).
Probably not what was expected!
So if your transport is "unreliable", you need to consider serialising requests with a dialog.