Explore topic-wise InterviewSolutions in .

The UPDATE method is used to modify the state of a SESSION WITHOUT changing the state of the dialog. A session is established in SIP using an INVITE REQUEST in an offer/answer manner. Typically, a session offer is made in the INVITE and an answer made in a RESPONSE to the INVITE. In an established session, a re-INVITE is used to update session parameters. However in pending session (INVITE sent but no final response received) UPDATE is used to update session parameters. Basically UPDATE is used to perform QoS and negotiate end-to-end attributes prior to session establishment.

The UPDATE method is used to modify the state of a session without changing the state of the dialog. A session is established in SIP using an INVITE request in an offer/answer manner. Typically, a session offer is made in the INVITE and an answer made in a response to the INVITE. In an established session, a re-INVITE is used to update session parameters. However in pending session (INVITE sent but no final response received) UPDATE is used to update session parameters. Basically UPDATE is used to perform QoS and negotiate end-to-end attributes prior to session establishment.

The PRACK method is used to acknowledge receipt of RELIABLY transported provisional responses (1XX). The reliability of 2xx, 3xx, 4xx, 5xx, and 6xx responses to INVITEs is achieved using the ACK method. However, in cases where a provisional RESPONSE, such as 180 Ringing, is critical in determining the call state, it may be necessary for the receipt of a provisional response to be confirmed. The PRACK method applies to all provisional responses except the 100 Trying response, which is never reliably transported. A PRACK is generated by a UAC when a provisional response has been received containing a RSeq reliable sequence number and a Supported: 100rel HEADER. The PRACK COPY the number in the RSeq and the CSeq of the response in a RAck header.

The PRACK method is used to acknowledge receipt of reliably transported provisional responses (1xx). The reliability of 2xx, 3xx, 4xx, 5xx, and 6xx responses to INVITEs is achieved using the ACK method. However, in cases where a provisional response, such as 180 Ringing, is critical in determining the call state, it may be necessary for the receipt of a provisional response to be confirmed. The PRACK method applies to all provisional responses except the 100 Trying response, which is never reliably transported. A PRACK is generated by a UAC when a provisional response has been received containing a RSeq reliable sequence number and a Supported: 100rel header. The PRACK copy the number in the RSeq and the CSeq of the response in a RAck header.

The INFO method is used by a user agent to SEND CALL signaling information to another user agent with which it has an established media session. This is different from a re-INVITE since it does not change the media CHARACTERISTICS of the call. The request is end-to-end, and is never initiated by proxies. A PROXY will always forward an INFO request—it is up to the UAS to check to see if the dialog is valid. INFO requests for unknown dialogs receive a 481 Transaction/Dialog Does Not Exist response.

The INFO method is used by a user agent to send call signaling information to another user agent with which it has an established media session. This is different from a re-INVITE since it does not change the media characteristics of the call. The request is end-to-end, and is never initiated by proxies. A proxy will always forward an INFO request—it is up to the UAS to check to see if the dialog is valid. INFO requests for unknown dialogs receive a 481 Transaction/Dialog Does Not Exist response.

The MESSAGE method is used to transport instant messages (IM) using SIP. IM USUALLY consists of SHORT message exchanged in near-real time by participants engaged in a "conversation." MESSAGEs may be SENT within a DIALOG or outside a dialog, but they do not establish a dialog by themselves.

The MESSAGE method is used to transport instant messages (IM) using SIP. IM usually consists of short message exchanged in near-real time by participants engaged in a "conversation." MESSAGEs may be sent within a dialog or outside a dialog, but they do not establish a dialog by themselves.

The NOTIFY method is used by a user AGENT to convey information about the occurrence of a PARTICULAR event. A NOTIFY is always sent within a dialog when a subscription exists between the subscriber and the notifier. A NOTIFY request normally receives a 200 OK response to indicate that it has been received. If a 481 Dialog/Transaction Does Not Exist response is received, the subscription is automatically terminated and no more NOTIFYs are sent. NOTIFY requests contain an Event header field INDICATING the package and a Subscription-State header field indicating the current state of the subscription.

The NOTIFY method is used by a user agent to convey information about the occurrence of a particular event. A NOTIFY is always sent within a dialog when a subscription exists between the subscriber and the notifier. A NOTIFY request normally receives a 200 OK response to indicate that it has been received. If a 481 Dialog/Transaction Does Not Exist response is received, the subscription is automatically terminated and no more NOTIFYs are sent. NOTIFY requests contain an Event header field indicating the package and a Subscription-State header field indicating the current state of the subscription.

The SUBSCRIBE METHOD is used by a user agent to establish a subscription for the purpose of receiving notifications (via the NOTIFY method) about a particular event. A successful subscription ESTABLISHES a dialog between the UAC and the UAS. The subscription request contains an Expires header field, which indicates the desired duration of the EXISTENCE of the subscription. After this time period passes, the subscription is automatically terminated. The subscription can be refreshed by sending another SUBSCRIBE within the dialog before the expiration time. A server accepting a subscription returns a 200 OK response also containing an Expires header field. The expiration timer can be the same as the request, or the server may shorten the interval, but it may not lengthen the interval. There is no "UNSUBSCRIBE" method used in SIP—instead a SUBSCRIBE with Expires:0 requests the termination of a subscription and HENCE the dialog. A terminated subscription (either due to timeout out or a termination request) will result in a final NOTIFY indicating that the subscription has been terminated.

The SUBSCRIBE method is used by a user agent to establish a subscription for the purpose of receiving notifications (via the NOTIFY method) about a particular event. A successful subscription establishes a dialog between the UAC and the UAS. The subscription request contains an Expires header field, which indicates the desired duration of the existence of the subscription. After this time period passes, the subscription is automatically terminated. The subscription can be refreshed by sending another SUBSCRIBE within the dialog before the expiration time. A server accepting a subscription returns a 200 OK response also containing an Expires header field. The expiration timer can be the same as the request, or the server may shorten the interval, but it may not lengthen the interval. There is no "UNSUBSCRIBE" method used in SIP—instead a SUBSCRIBE with Expires:0 requests the termination of a subscription and hence the dialog. A terminated subscription (either due to timeout out or a termination request) will result in a final NOTIFY indicating that the subscription has been terminated.

The REFER method is used by a user agent to request another user agent to access a URI or URL resource. The resource is identified by a URI or URL in the required Refer-To HEADER field. A REFER request can be sent EITHER inside or OUTSIDE an existing dialog.

The REFER method is used by a user agent to request another user agent to access a URI or URL resource. The resource is identified by a URI or URL in the required Refer-To header field. A REFER request can be sent either inside or outside an existing dialog.

The OPTIONS method is used to query a USER AGENT or SERVER about its capabilities and discover its current AVAILABILITY.

The OPTIONS method is used to query a user agent or server about its capabilities and discover its current availability.

The CANCEL method is used to terminate PENDING searches or call attempts. It can be generated by either user agents or proxy servers provided that a 1XX response containing a tag has been received, but no final response has been received. The branch ID for a CANCEL MATCHES the INVITE that it is canceling. A CANCEL only has meaning for an INVITE since only an INVITE may take several seconds (or minutes) to complete. All other SIP requests complete immediately. A user agent CONFIRMS the cancellation with a 200 OK response to the CANCEL and replies to the INVITE with a 487 Request Terminated response.

The CANCEL method is used to terminate pending searches or call attempts. It can be generated by either user agents or proxy servers provided that a 1xx response containing a tag has been received, but no final response has been received. The branch ID for a CANCEL matches the INVITE that it is canceling. A CANCEL only has meaning for an INVITE since only an INVITE may take several seconds (or minutes) to complete. All other SIP requests complete immediately. A user agent confirms the cancellation with a 200 OK response to the CANCEL and replies to the INVITE with a 487 Request Terminated response.

The ACK method is used to acknowledge final responses to INVITE requests. Final responses to all other requests are never acknowledged.An ACK may contain an application/sdp message body. This is permitted if the initial INVITE did not contain a SDP message body. If the INVITE CONTAINED a message body, the ACK may not contain a message body. For 2xx responses, the ACK is end-to-end, but for all other final responses it is done on a hop-by-hop basis when stateful proxies are involved. A hop-by-hop ACK reuses the same BRANCH ID as the INVITE SINCE it is considered part of the same transaction. An end-to-end ACK USES a different branch ID as it is considered a new transaction.

The ACK method is used to acknowledge final responses to INVITE requests. Final responses to all other requests are never acknowledged.An ACK may contain an application/sdp message body. This is permitted if the initial INVITE did not contain a SDP message body. If the INVITE contained a message body, the ACK may not contain a message body. For 2xx responses, the ACK is end-to-end, but for all other final responses it is done on a hop-by-hop basis when stateful proxies are involved. A hop-by-hop ACK reuses the same branch ID as the INVITE since it is considered part of the same transaction. An end-to-end ACK uses a different branch ID as it is considered a new transaction.

The BYE method is used to terminate an established MEDIA session. A BYE is SENT only by user agents participating in the session, NEVER by proxies or other THIRD parties. It is an end-to-end method, so responses are only generated by the other user agent.

The BYE method is used to terminate an established media session. A BYE is sent only by user agents participating in the session, never by proxies or other third parties. It is an end-to-end method, so responses are only generated by the other user agent.

If no CONTACT header present in REGISTER message registrar/location server will RETURN all current registrations(CONTACTS) in response.

If no Contact header present in REGISTER message registrar/location server will return all current registrations(contacts) in response.

The CONTACT header FIELD is equal to * and EXPIRES: 0

The contact header field is equal to * and Expires: 0

If the UA sending the registration request on BEHALF of other UA it is CALLED THIRD party registration. In this case, the From header will CONTAIN the URI of the party submitting the registration on behalf of the party identified in the To header.

If the UA sending the registration request on behalf of other UA it is called third party registration. In this case, the From header will contain the URI of the party submitting the registration on behalf of the party identified in the To header.

The Request-URI contains only the DOMAIN of the registrar server with no USER PORTION.

The Request-URI contains only the domain of the registrar server with no user portion.

The presence of an Expires header sets the EXPIRATION of CONTACTS with no expires PARAMETER. If an expires parameter is present, it sets the expiration TIME for that Contact only.

The presence of an Expires header sets the expiration of Contacts with no expires parameter. If an expires parameter is present, it sets the expiration time for that Contact only.

The registration creates a temporary BINDING between the Address of Record (AOR) URI in the To header and the device URI in the Contact header.The binding of Registration is not required to enable a user agent to use a proxy server for outgoing calls. It is necessary, however, for a user agent to REGISTER to receive INCOMING calls from proxies that serve that domain unless some non-SIP mechanism is used by the location service to POPULATE the SIP URIS and Contacts of end-points.

The registration creates a temporary binding between the Address of Record (AOR) URI in the To header and the device URI in the Contact header.The binding of Registration is not required to enable a user agent to use a proxy server for outgoing calls. It is necessary, however, for a user agent to register to receive incoming calls from proxies that serve that domain unless some non-SIP mechanism is used by the location service to populate the SIP URIs and Contacts of end-points.

The REGISTER METHOD is used by a user AGENT to notify a SIP network of its current CONTACT URI (IP address).

The REGISTER method is used by a user agent to notify a SIP network of its current Contact URI (IP address).

The INVITE METHOD is used to establish media SESSIONS between user agents. An INVITE usually has a message body CONTAINING the media information of the caller. If an INVITE does not contain media information, the ACK CONTAINS the media information of the UAC. If the media information contained in the ACK is not acceptable, then the called party must send a BYE to cancel the session—a CANCEL cannot be sent because the session is already established.

The INVITE method is used to establish media sessions between user agents. An INVITE usually has a message body containing the media information of the caller. If an INVITE does not contain media information, the ACK contains the media information of the UAC. If the media information contained in the ACK is not acceptable, then the called party must send a BYE to cancel the session—a CANCEL cannot be sent because the session is already established.

An Expires header in an INVITE indicates to the UAS how long the CALL request is valid. For example, the UAS could leave an UNANSWERED INVITE request displayed on a screen for the duration of SPECIFIED in the Expires header. Once a session is ESTABLISHED, the Expires header has no meaning—the expiration of the time does not terminate the media session. Instead, a Session-Expires header can be used to place a time limit on an established session.

An Expires header in an INVITE indicates to the UAS how long the call request is valid. For example, the UAS could leave an unanswered INVITE request displayed on a screen for the duration of specified in the Expires header. Once a session is established, the Expires header has no meaning—the expiration of the time does not terminate the media session. Instead, a Session-Expires header can be used to place a time limit on an established session.

No, If a re-INVITE is REFUSED or FAILS in any way, the session CONTINUES as if the INVITE had never been sent.

No, If a re-INVITE is refused or fails in any way, the session continues as if the INVITE had never been sent.

The INVITE, REGISTER, BYE, ACK, CANCEL, and OPTIONS METHODS are the original six methods in SIP. The REFER, SUBSCRIBE, NOTIFY,MESSAGE, UPDATE, INFO, and PRACK methods are DESCRIBED in separate RFCS.

The INVITE, REGISTER, BYE, ACK, CANCEL, and OPTIONS methods are the original six methods in SIP. The REFER, SUBSCRIBE, NOTIFY,MESSAGE, UPDATE, INFO, and PRACK methods are described in separate RFCs.

Traversal Using Relay NAT (TURN) protocol allows a client to obtain a transport IP address and port that it can receive packets sent from a single IP address in the PUBLIC Internet. For some NAT TOPOLOGIES such as a client behind a SYMMETRIC NAT, using a relay located in the public Internet is the only APPROACH that allows communication to take PLACE.

Traversal Using Relay NAT (TURN) protocol allows a client to obtain a transport IP address and port that it can receive packets sent from a single IP address in the public Internet. For some NAT topologies such as a client behind a symmetric NAT, using a relay located in the public Internet is the only approach that allows communication to take place.

The Simple Traversal of UDP through NATs (STUN) protocol ALLOWS a client to discover the presence and type of NATs between the client and the public Internet. In addition, a client can discover the MAPPING between the private IP address and PORT number and the public IP address and port number. Typically, a service PROVIDER will OPERATE a STUN server in the public Internet, with STUN clients being embedded in end-devices, which are possibly behind a NAT.

The Simple Traversal of UDP through NATs (STUN) protocol allows a client to discover the presence and type of NATs between the client and the public Internet. In addition, a client can discover the mapping between the private IP address and port number and the public IP address and port number. Typically, a service provider will operate a STUN server in the public Internet, with STUN clients being embedded in end-devices, which are possibly behind a NAT.

A FIREWALL or a proxy that controls the firewall needs to understand SIP, be able to parse an INVITE REQUEST and 200 OK response, extract the IP addresses and port numbers from the SDP, and open up “pin holes” in the firewall to ALLOW RTP traffic to pass. The hole can then be closed when a BYE is sent or a session timer expires. An alternative is an ALG—a B2BUA that is trusted by the firewall. The firewall then allows SIP and RTP traffic, which terminates on the ALG and BLOCKS all other traffic. The authentication and security policies of allowing or denying SIP sessions are then controlled by the SIP ALG instead of in the firewall itself.

A firewall or a proxy that controls the firewall needs to understand SIP, be able to parse an INVITE request and 200 OK response, extract the IP addresses and port numbers from the SDP, and open up “pin holes” in the firewall to allow RTP traffic to pass. The hole can then be closed when a BYE is sent or a session timer expires. An alternative is an ALG—a B2BUA that is trusted by the firewall. The firewall then allows SIP and RTP traffic, which terminates on the ALG and blocks all other traffic. The authentication and security policies of allowing or denying SIP sessions are then controlled by the SIP ALG instead of in the firewall itself.

A proxy is said to be loose ROUTING if it follows the procedures defined in rfc 3261 specification for processing of the ROUTE HEADER FIELD. These procedures separate the destination of the request (present in the Request-URI) from the set of proxies that need to be visited ALONG the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router.

A proxy is said to be loose routing if it follows the procedures defined in rfc 3261 specification for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from the set of proxies that need to be visited along the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router.

A spiral is a SIP request that is routed to a proxy, FORWARDED onwards, and arrives once again at that proxy, but this time differs in a way that will result in a different processing decision than the original request. Typically, this means that the request's Request-URI differs from its previous arrival. A spiral is not an error CONDITION, unlike a loop. A typical CAUSE for this is call forwarding. A user calls joe@example.com. The example.com proxy forwards it to Joe's PC, which in turn, forwards it to bob@example.com. This request is proxied back to the example.com proxy. However, this is not a loop. Since the request is TARGETED at a different user, it is considered a spiral, and is a valid condition.

A spiral is a SIP request that is routed to a proxy, forwarded onwards, and arrives once again at that proxy, but this time differs in a way that will result in a different processing decision than the original request. Typically, this means that the request's Request-URI differs from its previous arrival. A spiral is not an error condition, unlike a loop. A typical cause for this is call forwarding. A user calls joe@example.com. The example.com proxy forwards it to Joe's PC, which in turn, forwards it to bob@example.com. This request is proxied back to the example.com proxy. However, this is not a loop. Since the request is targeted at a different user, it is considered a spiral, and is a valid condition.

A request that arrives at a proxy, is forwarded, and later arrives back at the same proxy. When it arrives the SECOND time, its Request-URI is IDENTICAL to the first time, and other header fields that affect proxy OPERATION are unchanged, so that the proxy would make the same processing decision on the request it made the first time. LOOPED requests are errors and can be handled using the value of Max-Forwards header field.

A request that arrives at a proxy, is forwarded, and later arrives back at the same proxy. When it arrives the second time, its Request-URI is identical to the first time, and other header fields that affect proxy operation are unchanged, so that the proxy would make the same processing decision on the request it made the first time. Looped requests are errors and can be handled using the value of Max-Forwards header field.

A LOCATION SERVICE is used by a SIP redirect or PROXY server to obtain information about a callee's possible location(s). It contains a list of BINDINGS of address-of-record keys to zero or more contact ADDRESSES.

A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s). It contains a list of bindings of address-of-record keys to zero or more contact addresses.

A proxy is CALL stateful if it retains state for a dialog from the initiating INVITE to the terminating BYE REQUEST. A call stateful proxy is always TRANSACTION stateful, but the CONVERSE is not necessarily true.

A proxy is call stateful if it retains state for a dialog from the initiating INVITE to the terminating BYE request. A call stateful proxy is always transaction stateful, but the converse is not necessarily true.

• The SIP protocol is divided into layers. 
• The lowest layer of SIP is its syntax and encoding, where the message is constructed. 
• The The second layer is the transport layer, it defines how a message is send and receive over a network.
• The THIRD layer is the transaction layer. A transaction is a request sent from the UAC to UAS and the RESPONSES for this request COMING from UAS to UAC.The transaction layer handles application-layer retransmissions, matching of responses to requests, and application-layer TIMEOUTS.
• The layer above the transaction layer is called the transaction user(TU). Each of the SIP entities, except the stateless proxy, is a transaction user.

After RECEIVING a 1XX response, any RETRANSMISSIONS CEASE altogether, and the client waits for further responses.

After receiving a 1xx response, any retransmissions cease altogether, and the client waits for further responses.

a gateway is just a special TYPE of user agent, where the user agent ACTS on BEHALF of another PROTOCOL rather than a HUMAN. A gateway terminates the signaling path and can also terminate the media path. Another difference between a user agent and a gateway is the number of users supported. While a user agent typically supports a single user, a gateway can support hundreds or thousands of users.

a gateway is just a special type of user agent, where the user agent acts on behalf of another protocol rather than a human. A gateway terminates the signaling path and can also terminate the media path. Another difference between a user agent and a gateway is the number of users supported. While a user agent typically supports a single user, a gateway can support hundreds or thousands of users.

Gateways are sometimes decomposed into a media GATEWAY (MG) and a media gateway CONTROLLER (MGC). An MGC is sometimes called a call AGENT because it MANAGES call control PROTOCOLS (signaling), while the MG manages the media connection.

Gateways are sometimes decomposed into a media gateway (MG) and a media gateway controller (MGC). An MGC is sometimes called a call agent because it manages call control protocols (signaling), while the MG manages the media connection.

A SIP gateway is an application that INTERFACES a SIP NETWORK to a network UTILIZING ANOTHER signaling PROTOCOL.

A SIP gateway is an application that interfaces a SIP network to a network utilizing another signaling protocol.

A back-to-back user agent (B2BUA) is a type of SIP device that receives a SIP request, then reformulates the request and sends it out as a new request. Responses to the request are also reformulated and sent back in the opposite DIRECTION. For example, a B2BUA device can be USED to IMPLEMENT an anonymizer service in which two SIP UAs can communicate WITHOUT either party learning the other party’s URI, IP address, or any other information. The most common form of B2BUA present in SIP networks is application layer gateways (ALG).

A back-to-back user agent (B2BUA) is a type of SIP device that receives a SIP request, then reformulates the request and sends it out as a new request. Responses to the request are also reformulated and sent back in the opposite direction. For example, a B2BUA device can be used to implement an anonymizer service in which two SIP UAs can communicate without either party learning the other party’s URI, IP address, or any other information. The most common form of B2BUA present in SIP networks is application layer gateways (ALG).

A presence agent (PA) is a SIP device that is capable of receiving SUBSCRIPTION requests and GENERATING state NOTIFICATIONS. A presence agent can collect presence information from a number of devices. Presence information can come from a SIP device registering, a SIP device PUBLISHING presence information or from many other non-SIP SOURCES.

A presence agent (PA) is a SIP device that is capable of receiving subscription requests and generating state notifications. A presence agent can collect presence information from a number of devices. Presence information can come from a SIP device registering, a SIP device publishing presence information or from many other non-SIP sources.

A SIP UA uses TCP if it has to SEND messages GREATER than 1,000 OCTETS in SIZE.

A SIP UA uses TCP if it has to send messages greater than 1,000 octets in size.

A user agent RECEIVING a request for an UNKNOWN DIALOG responds with a 481 Dialog/Transaction Does Not Exist. Responses from an unknown dialog are SILENTLY discarded.

A user agent receiving a request for an unknown dialog responds with a 481 Dialog/Transaction Does Not Exist. Responses from an unknown dialog are silently discarded.

A re-INVITE is USED to change the session parameters of an existing or PENDING call. It uses the same Call-ID, but the CSeq is incremented because it is a NEW request. A retransmitted INVITE will contain the same Call-ID and CSeq as a PREVIOUS INVITE.

A re-INVITE is used to change the session parameters of an existing or pending call. It uses the same Call-ID, but the CSeq is incremented because it is a new request. A retransmitted INVITE will contain the same Call-ID and CSeq as a previous INVITE.

A SIP-enabled end-device is called a SIP user agent. As the name implies, a user agent TAKES direction or input from a user and acts as an agent on their behalf to set up and tear down media sessions with other user agents. In most cases, the user will be a human, but the user could be another PROTOCOL, as in the case of a gateway. A user agent must be capable of ESTABLISHING a media session with another user agent. A UA must maintain state on calls that it INITIATES or participates in. A minimum call state set includes the local and remote tags, Call-ID, local and remote CSeq header fields, along with the route set and any state information NECESSARY for the media.

A SIP-enabled end-device is called a SIP user agent. As the name implies, a user agent takes direction or input from a user and acts as an agent on their behalf to set up and tear down media sessions with other user agents. In most cases, the user will be a human, but the user could be another protocol, as in the case of a gateway. A user agent must be capable of establishing a media session with another user agent. A UA must maintain state on calls that it initiates or participates in. A minimum call state set includes the local and remote tags, Call-ID, local and remote CSeq header fields, along with the route set and any state information necessary for the media.

No, the CANCEL method is hop-by-hop request used to terminate pending calls or searches. A proxy receiving a CANCEL immediately SENDS a 200 OK response BACK to the sender and GENERATES a new CANCEL, which is then FORWARDED to the next hop. Similar behaviour can be found in 3xx, 4xx, 5xx, and 6xx responses to an INVITE request. While an ACK to a 2xx response is generated by the end point, a 3xx, 4xx, 5xx, or 6xx response is acknowledged on a hop-by-hop basis. A proxy SERVER receiving one of these responses immediately generates an ACK back to the sender and forwards the response to the next hop.

No, the CANCEL method is hop-by-hop request used to terminate pending calls or searches. A proxy receiving a CANCEL immediately sends a 200 OK response back to the sender and generates a new CANCEL, which is then forwarded to the next hop. Similar behaviour can be found in 3xx, 4xx, 5xx, and 6xx responses to an INVITE request. While an ACK to a 2xx response is generated by the end point, a 3xx, 4xx, 5xx, or 6xx response is acknowledged on a hop-by-hop basis. A proxy server receiving one of these responses immediately generates an ACK back to the sender and forwards the response to the next hop.

A registration SERVER, also known as a registrar, accepts SIP REGISTER requests and all other requests receive a 501 Not Implemented response. The CONTACT information from the request is then made available to other SIP servers within the same administrative domain, such as proxies and redirect servers. In a registration request, the To HEADER field contains the name of the resource being registered, and the Contact header fields contain the alternative ADDRESSES or aliases. The registration server creates a temporary binding between the Address of Record (AOR) URI in the To and the DEVICE URI in the Contact header.

A registration server, also known as a registrar, accepts SIP REGISTER requests and all other requests receive a 501 Not Implemented response. The contact information from the request is then made available to other SIP servers within the same administrative domain, such as proxies and redirect servers. In a registration request, the To header field contains the name of the resource being registered, and the Contact header fields contain the alternative addresses or aliases. The registration server creates a temporary binding between the Address of Record (AOR) URI in the To and the device URI in the Contact header.

Yes, the ACK sent to non-2xx FINAL RESPONSE is considered to be part of the same transaction as INVITE. ACK request reuses the same branch ID as INVITE. Only an ACK sent in response to a 200 OK is considered a separate transaction with a unique branch ID. Also an ACK to a non-2xx final response is a hop-by-hop response, not an end-to-end response.

Yes, the ACK sent to non-2xx final response is considered to be part of the same transaction as INVITE. ACK request reuses the same branch ID as INVITE. Only an ACK sent in response to a 200 OK is considered a separate transaction with a unique branch ID. Also an ACK to a non-2xx final response is a hop-by-hop response, not an end-to-end response.

A REDIRECT server is a type of SIP server that responds the REQUESTS but does not forwards the requests. Like proxy server, a redirect server uses a database or location service to LOOK up a user. The location INFORMATION, however, is sent back to the caller in a redirection class response (3xx), which, after the ACK, concludes the transaction.

A redirect server is a type of SIP server that responds the requests but does not forwards the requests. Like proxy server, a redirect server uses a database or location service to look up a user. The location information, however, is sent back to the caller in a redirection class response (3xx), which, after the ACK, concludes the transaction.

A SIP session timer has been proposed to limit the time period over which a stateful PROXY must MAINTAIN state information. In the initial INVITE request, a Session-Expires HEADER field indicates a timer interval after which stateful proxies may discard state information about the session. User agents must TEAR down the call after the expiration of the timer. The caller can send re-INVITEs to refresh the timer, ENABLING a “keep alive” mechanism for SIP. This solves the problem of how long to store state information in cases where a BYE request is lost or misdirected.

A SIP session timer has been proposed to limit the time period over which a stateful proxy must maintain state information. In the initial INVITE request, a Session-Expires header field indicates a timer interval after which stateful proxies may discard state information about the session. User agents must tear down the call after the expiration of the timer. The caller can send re-INVITEs to refresh the timer, enabling a “keep alive” mechanism for SIP. This solves the problem of how long to store state information in cases where a BYE request is lost or misdirected.

a proxy server that receives an INVITE request, then forwards it to a number of locations at the same time. This “forking” proxy server keeps track of each of the outstanding requests and the response to each. This is USEFUL if the location service or database lookup returns multiple possible locations for the called party that need to be tried. For example forking proxy F1 is RECEIVED from UA1 which forks to two user agents UA2 & UA3. Each user agent begins alerting and sending BACK two provisional resposes(180 Ringing) to F1. The two responses are identical except for having different To tags and Contact URIs. Finally, ONE of the two UAs answers and SENDS a 200 OK response. The forking proxy server sends a CANCEL to the second UA to stop that phone alerting. If both UAs had answered, the forking proxy would have forwarded both 200 OK responses back to the caller who then would have had to choose which one, probably accepting one and sending a BYE to the other one.

a proxy server that receives an INVITE request, then forwards it to a number of locations at the same time. This “forking” proxy server keeps track of each of the outstanding requests and the response to each. This is useful if the location service or database lookup returns multiple possible locations for the called party that need to be tried. For example forking proxy F1 is received from UA1 which forks to two user agents UA2 & UA3. Each user agent begins alerting and sending back two provisional resposes(180 Ringing) to F1. The two responses are identical except for having different To tags and Contact URIs. Finally, one of the two UAs answers and sends a 200 OK response. The forking proxy server sends a CANCEL to the second UA to stop that phone alerting. If both UAs had answered, the forking proxy would have forwarded both 200 OK responses back to the caller who then would have had to choose which one, probably accepting one and sending a BYE to the other one.

The PROXY SERVER from which the USER agent recieves the SIP request is CALLED the inbound proxy server.

The proxy server from which the user agent recieves the SIP request is called the inbound proxy server.

The PROXY SERVER to which the user agent SENDS the SIP request is called the outbound proxy server. This proxy server will authenticate the user agent and may pull up a PROFILE of the user and APPLY outbound routing services.

The proxy server to which the user agent sends the SIP request is called the outbound proxy server. This proxy server will authenticate the user agent and may pull up a profile of the user and apply outbound routing services.

A proxy server is DIFFERENT from a gateway or user agent in three key ways:

1. A proxy does not issue request, it only responds to requests from user agents. (A CANCEL request is an exception to this rule)
2. A proxy server has no media capabilities.
3. A proxy server does not PARSE message BODIES, it relies exclusively on message HEADER fields.

A proxy server is different from a gateway or user agent in three key ways: