The VoIP world is dominated by SIP lately. SIP is a standard that is defined by a number of RFCs but searching through here for answers to questions is ridiculously difficult. I would like to use this post to answer any SIP questions that I come across in my daily travels. If you have a question that has not been answered feel free to drop it in the comments. I'll do my very best to find an answer for you!
Q: What is the maximum size of a SIP packet?
A: The maximum allowed size is equal to the maximum size of a UDP packet, or 65,507 bytes (65,535B - 20 B IP Header -8 B UDP Header). Some software may not accept packets of this size. Often software will limit the packet size to 4096B.
Q: What is a SIP User Agent (UA)?
A: A User Agent refers to a component in the SIP communication between two devices. There are two types of User Agents: Client and Server. A UA Client (UAC) sends a SIP request and a UA Server (UAS) sends a response. Most of the time a SIP server or endpoint will act as both a UAC and a UAS, depending on the circumstance. A call may terminate to a phone in which case the SIP server is the UAC and the phone is the UAS. The phone may then place the call on hold or conference another user, at which point the phone sends the request and becomes the UAC.
Q: What is a B2BUA?
A: A B2BUA (Back to Back User Agent) is a device that receives a request from a UAC and forwards that request out to another device, acting initially as the UAS and as the second leg as a UAC. A B2BUA will remain in the middle of the conversation so that the endpoints do not communicate directly for signaling purposes. It is still possible to have a B2BUA with direct media path for RTP packets.
Q: What is the maximum speed for faxing with SIP?
A: Contrary to what most people believe, there is no difference in the maximum speed of a fax machine on analog or PRI versus SIP. The SIP standard doesn't care - this is a function of the codec negotiation. But that doesn't answer the real question here. When I'm setting up a PBX I always suggest the customer limit their fax speed to 14,400bps. The PBX will see the 14,400 speed (or lower) and will use the T.38 codec for faxing. Most phone systems will only allow T.38 if the PBX will be holding up the RTP (i.e. no direct media path) as the system will switch to T.38 when it detects the fax tones being sent from the originating fax machine. Modern fax machines (also known as Super G3 fax machines) support speeds of up to 38,400bps, although the realized throughput is often lower. When using a Super G3 fax machine the codec will negotiate to G.711. Network reliability is incredibly important when using Super G3 speeds. These machines are incredibly intolerant to jitter and packet loss.
Showing posts with label UAS. Show all posts
Showing posts with label UAS. Show all posts
Session Initiation Protocol
Session Initiation Protocol (SIP) is an alternative to H.323. It was created for the distribution of multimedia content. SIP supports a variety of architectures and protocols and is modeled after HTTP using plain text, which allows for easy packet inspection by administrators. It uses a Request-Response model (or INVITE model). It supports several types of proxy servers and operates on the Application layer of the OSI model. It leverages separate protocols that can be used without making any core protocol changes. It is totally independent of the voice path.
Every device on a SIP network is called a User Agent. A User Agent can serve two roles: If it is sending a request it is a User Agent Client (UAC) and if it is receiving a request it is a User Agent Server (UAS).
SIP supports two basic types of messages: Requests and Responses. SIP Requests and Responses are defined in the IETF RFC 3261. Every SIP message uses a start line that indicates if the message is a request or a response, as well as some other information including the version of SIP that is being used. I will start by going over requests and then discuss responses.
A request uses one of six methods. These methods are REGISTER, INVITE, ACK, CANCEL, BYE, and OPTIONS. REGISTER is quite obvious – it sends a message to a SIP Registration Server notifying it of its current IP address, as well as the URLs at which it wants to receive calls. INVITE is also fairly obvious; it indicates that a device wants to invite another user or service to participate in the session. ACK is an acknowledgement that the UAC has received a request, confirming that a message has been exchanged. CANCEL is used to terminate a pending request, but it does not terminate any already accepted calls. BYE end the call (this is what happens when you hang up). OPTIONS will query the capabilities of the UAS (the receiving end of a call) without setting up a call. There are additional SIP Extensions, defined by other RFCs, that include UPDATE (allowing the client to update the parameters of a session), INFO (carrying session-related control information during a session), PRACK (provides a Provisional Acknowledgement), and SUBSCRIB/NOTIFY (asking for notification from a remote node indicating that certain events have occurred). A request starts off with the method of the request, followed by the request URL and the SIP version.
A Response has a large number of possibilities. These possibilities are all covered in RFC 3261 as well. All responses have a three-digit code to identify what the response is. They are grouped into six categories, with each category being easily identified by the first digit in the code. A code beginning with a 1 is called a Provisional response, and indicates that a request has been received and is currently being processed, also called an informational response. A code that starts with 2 is a successful response, indicating that the UAS has received the request and understands it. A code beginning with 3 is a redirection response, indicating that further actions are required, usually by the sending User Agent, to complete the request. A 4 code indicates a failure. Often this is caused by bad syntax or an inability of the UAS to complete the request. A code starting with 5 is a server failure, indicating that the server was unable to process a request even though it looked like the request was valid. A code beginning with 6 indicates a global failure. Each of these six categories has a number of possible responses, as is indicated by the two remaining digits.
SIP uses two protocols to establish a conference call session: Session Announcement Protocol (SAP) and Session Description Protocol (SDP). SAP creates, modifies, and terminates sessions. It announces a conference session by periodically multicasting an announcement to a well-known multicast address port. SDP is a component of SAP, but can be used with RTSP, SIP, and as a standalone protocol. It is used to convey information to SIP entities and let them join and participate in a SIP session. SDP contains the purpose of the session, the name of the session, the media type pertaining to the session, formatted information for the session, and pertinent IP addresses and port numbers for the session.
Every device on a SIP network is called a User Agent. A User Agent can serve two roles: If it is sending a request it is a User Agent Client (UAC) and if it is receiving a request it is a User Agent Server (UAS).
SIP supports two basic types of messages: Requests and Responses. SIP Requests and Responses are defined in the IETF RFC 3261. Every SIP message uses a start line that indicates if the message is a request or a response, as well as some other information including the version of SIP that is being used. I will start by going over requests and then discuss responses.
A request uses one of six methods. These methods are REGISTER, INVITE, ACK, CANCEL, BYE, and OPTIONS. REGISTER is quite obvious – it sends a message to a SIP Registration Server notifying it of its current IP address, as well as the URLs at which it wants to receive calls. INVITE is also fairly obvious; it indicates that a device wants to invite another user or service to participate in the session. ACK is an acknowledgement that the UAC has received a request, confirming that a message has been exchanged. CANCEL is used to terminate a pending request, but it does not terminate any already accepted calls. BYE end the call (this is what happens when you hang up). OPTIONS will query the capabilities of the UAS (the receiving end of a call) without setting up a call. There are additional SIP Extensions, defined by other RFCs, that include UPDATE (allowing the client to update the parameters of a session), INFO (carrying session-related control information during a session), PRACK (provides a Provisional Acknowledgement), and SUBSCRIB/NOTIFY (asking for notification from a remote node indicating that certain events have occurred). A request starts off with the method of the request, followed by the request URL and the SIP version.
A Response has a large number of possibilities. These possibilities are all covered in RFC 3261 as well. All responses have a three-digit code to identify what the response is. They are grouped into six categories, with each category being easily identified by the first digit in the code. A code beginning with a 1 is called a Provisional response, and indicates that a request has been received and is currently being processed, also called an informational response. A code that starts with 2 is a successful response, indicating that the UAS has received the request and understands it. A code beginning with 3 is a redirection response, indicating that further actions are required, usually by the sending User Agent, to complete the request. A 4 code indicates a failure. Often this is caused by bad syntax or an inability of the UAS to complete the request. A code starting with 5 is a server failure, indicating that the server was unable to process a request even though it looked like the request was valid. A code beginning with 6 indicates a global failure. Each of these six categories has a number of possible responses, as is indicated by the two remaining digits.
SIP uses two protocols to establish a conference call session: Session Announcement Protocol (SAP) and Session Description Protocol (SDP). SAP creates, modifies, and terminates sessions. It announces a conference session by periodically multicasting an announcement to a well-known multicast address port. SDP is a component of SAP, but can be used with RTSP, SIP, and as a standalone protocol. It is used to convey information to SIP entities and let them join and participate in a SIP session. SDP contains the purpose of the session, the name of the session, the media type pertaining to the session, formatted information for the session, and pertinent IP addresses and port numbers for the session.
Subscribe to:
Posts (Atom)