Search code examples
sipasterisk

SIP: Wait for ACK packet on Callee site to start RTP session

The Situation:

I have a question concerning the ACK message (yellow) which is send from the Asterisk to the Callee (Tel B) after the Callee has send its 200 OK + SDP message (purple). The Asterisk call flow which I am talking about looks like:

My network for testing porposes:

Laptop+Softphone ---- Asterisk ---- Laptop+Softphone

The Question:

All of my tested Linux softphones (Twinkle, SFLPhone, Ekiga-Softon, Linphone and QuteCom) are not waiting for the ACK to start the RTP session. I filtered the ACK message with iptables on the Asterisk Server and the RTP session started anyways. However due to my project intention I would like to wait for the ACK message and then start the RTP session. Is there a way, switch, command or preference to let the softphone wait with the RTP stream until the ACK message is received?

Additional:

I googled a lot and found some device e.g. the iiNet Branded Belkin VoIP Router which has the option: Start RTP session before receiving ACK [default: off] Thus I guess there must be a way to let the RTP session start after the ACK is received.

As well I found that it is best practice that the session starts directly after the 200 OK + SDP is send. However as aforementioned this is not sufficient for my project.

Source of Figure:

http://www.panoramisk.com/101/asterisk-and-voice-transport/en/

Solution

  • The short answer is no; there isn't going to be a widely supported setting that allows you to force RTP to be started after the ACK. At best you'll find some devices/softphones, such as the one you mention, that have a setting that allows it. I have seen this query come up before on the SIP implementers mailing list and if I recall correctly the RFC isn't actually definitive on whether the RTP should start after the 2xx response or the ACK but the generally excepted premise is that it's the 2xx response.

    Another angle you could explore is looking for a setting, or maybe even getting tricky with your firewall rules, to send the initial INVITE without SDP. INVITEs without SDP are supported by RFC 3261 and when they are received it indicates the 2xx response should contain the initial SDP offer and the subsequent ACK will then have the SDP response. With that mechanism the RTP will have nowhere to go until after the ACK is sent.