0

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:

  1. Client sends INVITE to SIP-Proxy, SIP-Proxy resends INVITE to Asterisk
  2. Asterisk answers with 200 OK, SIP-Proxy resends 200 OK to client.
  3. Client answers with ACK, SIP-Proxy resends ACK to Asterisk
  4. 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.

user12384512
  • 3,362
  • 10
  • 61
  • 97

2 Answers2

0

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!

Liviu Chircu
  • 1,000
  • 3
  • 11
  • 24
0

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.

Rajesh
  • 660
  • 4
  • 12
  • Finally after debugig I managed to figure out that it happens when BYE packets was lost due retransmission. For example if we have 10 seconds network spike, bye packet will be lost. If I do re-invite very 1-2 minute will it help to check whether call is still alive ? – user12384512 Aug 07 '14 at 16:46
  • yep, periodic pinging with Re-INvite should help you determine the presence of the call on the remote-server. Either it may not respond at all or reply with a 481 / 408. In either case you could possibly tear down the call. – Rajesh Aug 08 '14 at 17:38