diff options
Diffstat (limited to '1.4.23-rc4/doc/sip-retransmit.txt')
| -rw-r--r-- | 1.4.23-rc4/doc/sip-retransmit.txt | 126 |
1 files changed, 0 insertions, 126 deletions
diff --git a/1.4.23-rc4/doc/sip-retransmit.txt b/1.4.23-rc4/doc/sip-retransmit.txt deleted file mode 100644 index a3431a806..000000000 --- a/1.4.23-rc4/doc/sip-retransmit.txt +++ /dev/null @@ -1,126 +0,0 @@ -What is the problem with SIP retransmits? ------------------------------------------ - -Sometimes you get messages in the console like these: - -- "retrans_pkt: Hanging up call XX77yy - no reply to our critical packet." -- "retrans_pkt: Cancelling retransmit of OPTIONs" - -The SIP protocol is based on requests and replies. Both sides send -requests and wait for replies. Some of these requests are important. -In a TCP/IP network many things can happen with IP packets. Firewalls, -NAT devices, Session Border Controllers and SIP Proxys are in the -signalling path and they will affect the call. - -SIP Call setup - INVITE-200 OK - ACK ------------------------------------- -To set up a SIP call, there's an INVITE transaction. The SIP software that -initiates the call sends an INVITE, then wait to get a reply. When a -reply arrives, the caller sends an ACK. This is a three-way handshake -that is in place since a phone can ring for a very long time and -the protocol needs to make sure that all devices are still on line -when call setup is done and media starts to flow. - -- The first reply we're waiting for is often a "100 trying". - This message means that some type of SIP server has received our - request and makes sure that we will get a reply. It could be - the other endpoint, but it could also be a SIP proxy or SBC - that handles the request on our behalf. - -- After that, you often see a response in the 18x class, like - "180 ringing" or "183 Session Progress". This typically means that our - request has reached at least one endpoint and something - is alerting the other end that there's a call coming in. - -- Finally, the other side answers and we get a positive reply, - "200 OK". This is a positive answer. In that message, we get an - address that goes directly to the device that answers. Remember, - there could be multiple phones ringing. The address is specified - by the Contact: header. - -- To confirm that we can reach the phone that answered our call, - we now send an ACK to the Contact: address. If this ACK doesn't - reach the phone, the call fails. If we can't send an ACK, we - can't send anything else, not even a proper hangup. Call - signalling will simply fail for the rest of the call and there's - no point in keeping it alive. - -- If we get an error response to our INVITE, like "Busy" or - "Rejected", we send the ACK to the same address as we sent the - INVITE, to confirm that we got the response. - -In order to make sure that the whole call setup sequence works and that -we have a call, a SIP client retransmits messages if there's too much -delay between request and expected response. We retransmit a number of -times while waiting for the first response. We retransmit the answer to an -incoming INVITE while waiting for an ACK. If we get multiple answers, -we send an ACK to each of them. - -If we don't get the ACK or don't get an answer to our INVITE, -even after retransmissions, we will hangup the call with the first -error message you see above. - -Other SIP requests ------------------- -Other SIP requests are only based on request - reply. There's -no ACK, no three-way handshake. In Asterisk we mark some of -these as CRITICAL - they need to go through for the call to -work as expected. Some are non-critical, we don't really care -what happens with them, the call will go on happily regardless. - -The qualification process - OPTIONS ------------------------------------ -If you turn on qualify= in sip.conf for a device, Asterisk will -send an OPTIONS request every minute to the device and check -if it replies. Each OPTIONS request is retransmitted a number -of times (to handle packet loss) and if we get no reply, the -device is considered unreachable. From that moment, we will -send a new OPTIONS request (with retransmits) every tenth -second. - -Why does this happen? ---------------------- - -For some reason signalling doesn't work as expected between -your Asterisk server and the other device. There could be many reasons -why this happens. - -- A NAT device in the signalling path - A misconfigured NAT device is in the signalling path - and stops SIP messages. -- A firewall that blocks messages or reroutes them wrongly - in an attempt to assist in a too clever way. -- A SIP middlebox (SBC) that rewrites contact: headers - so that we can't reach the other side with our reply - or the ACK. -- A badly configured SIP proxy that forgets to add - record-route headers to make sure that signalling works. -- Packet loss. IP and UDP are unreliable transports. If - you loose too many packets the retransmits doesn't help - and communication is impossible. If this happens with - signalling, media would be unusable anyway. - -What can I do? --------------- - -Turn on SIP debug, try to understand the signalling that happens -and see if you're missing the reply to the INVITE or if the -ACK gets lost. When you know what happens, you've taken the -first step to track down the problem. See the list above and -investigate your network. - -For NAT and Firewall problems, there are many documents -to help you. Start with reading sip.conf.sample that is -part of your Asterisk distribution. - -The SIP signalling standard, including retransmissions -and timers for these, is well documented in the IETF -RFC 3261. - -Good luck sorting out your SIP issues! - -/Olle E. Johansson - - --- oej (at) edvina.net, Sweden, 2008-07-22 --- http://www.voip-forum.com |