Contents

• SIP Introduction
• SIP Requests
• SIP Responses
• SIP and RTP Testing
• What is a SIP Polling Re-invite

SIP Introduction

SIP clients traditionally use TCP and UDP port 5060 to connect to SIP servers and other SIP endpoints. SIP is primarily used in setting up and tearing down voice or video calls. However, it can be used in any application where session initiation is a requirement. These include Event Subscription and Notification, Terminal mobility and so on. There are a large number of SIP-related RFCs that define behaviour for such applications. All voice/video communications are done over separate transport protocols, typically RTP.

SIP provides call signalling while RTP provides the audio stream in each direction.

SIP Requests

• INVITE -Indicates a client is being invited to participate in a call session
• ACK -Confirms that the client has received a final response to an INVITE request
• BYE -Terminates a call and can be sent by either the caller or the callee.
• CANCEL -Cancels any pending searches but does not terminate a call that has already been accepted.
• OPTIONS -Queries the capabilities of servers.
• REGISTER -Registers the address listed in the To header field with a SIP server.

SIP Responses

1xx - Informational Responses

• 100 Trying
• 180 Ringing
• 181 Call Is Being Forwarded
• 182 Queued
• 183 Session Progress

2xx - Successful Responses

• 200 OK
• 202 accepted: Used for referrals

3xx - Redirection Responses

• 300 Multiple Choices
• 301 Moved Permanently
• 302 Moved Temporarily
• 305 Use Proxy
• 380 Alternative Service

4xx - Client Failure Responses

• 400 Bad Request
• 401 Unauthorized: Used only by registrars. Proxies should use proxy authorization 407
• 402 Payment Required (Reserved for future use)
• 403 Forbidden
• 404 Not Found: User not found
• 405 Method Not Allowed
• 406 Not Acceptable
• 407 Proxy Authentication Required
• 408 Request Timeout: Couldn't find the user in time
• 410 Gone: The user existed once, but is not available here any more
• 413 Request Entity Too Large
• 414 Request-URI Too Long
• 415 Unsupported Media Type
• 416 Unsupported URI Scheme
• 420 Bad Extension: Bad SIP Protocol Extension used, not understood by the server
• 421 Extension Required
• 423 Interval Too Brief
• 480 Temporarily Unavailable
• 481 Call/Transaction Does Not Exist
• 482 Loop Detected
• 483 Too Many Hops
• 484 Address Incomplete
• 485 Ambiguous
• 486 Busy Here
• 487 Request Terminated
• 488 Not Acceptable Here
• 491 Request Pending
• 493 Undecipherable: Could not decrypt S/MIME body part

5xx - Server Failure Responses

• 500 Server Internal Error
• 501 Not Implemented: The SIP request method is not implemented here
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Server Time-out
• 505 Version Not Supported: The server does not support this version of the SIP protocol
• 513 Message Too Large

6xx - Global Failure Responses

• 600 Busy Everywhere
• 603 Decline
• 604 Does Not Exist Anywhere
• 606 Not Acceptable

SIP and RTP testing

Conventional TCP/IP tools do not give much detail into how SIP/RTP traffic will perform on any given network. Outside of firewall and NAT concerns, both SIP and RTP are UDP-based with packet payloads of 70-110 bytes on average. This added concern of PPS load creates a very large number of variables in trying to pre-test for VoIP quality, especially when terminating over off-net ISPs.

Because of this, ultimately the best way to test a VoIP call is to actually record or analyze a network trace of a live phone call. There are, however, a few basic tests we can run prior to placing test calls. Many simple tests, such as ICMP pings, may show the link to be 'clean' and not expose bad VoIP call quality. Doing network trace testing can be useful for determining firewall or routing issues and also identify call quality issues at the clients ISP. In this example, we are using tethereal for our tracing.

What is a SIP Polling ReInvite

A polling reINVITE is a periodic INVITE request sent by the Metaswitch call agent to a SIP endpoint whilst that endpoint is involved in an active call (session).
Polling reINVITEs are sent as follows:

1. For a registered SIP binding, the reINVITE is sent every 30 seconds, with the first one being sent between 0 and 30 seconds into the call.
2. For a configured SIP binding the behaviour is controlled by the 'Poll peer device' field on the configured SIP binding object (Call Agent -> Controlled Networks -> Configured Sip Bindings -> Configured SIP binding)
   • a) If the field is set to 'false', the behaviour is the same as for a registered SIP binding. That is, the reINVITE is sent every 30 seconds, with the first one being sent between 0 and 30 seconds into the call.
   • b) If the field is set to 'true', the reINVITE will be sent every 15 minutes, with the first one being sent approximately 15 minutes into the call. In this case, the Metaswitch call agent will also be sending OPTIONS requests to the SIP device (the interval between these messages being controlled by the 'Polling interval' field on the configured SIP binding object). OPTIONS requests are also sent when the device is not in a call, so that the Metaswitch call agent can tell if the device is available