SIP Faq's

Difference between CANCEL Method and BYE Method
CANCEL Method is use to terminate a pending request, such as an outstanding INVITE. It is sent when session is not established
Eg: INVITE/180/CANCEL/200 OK

BYE Method is use to terminate the session after session is established. This Method can be sent by either user.
Eg: INVITE/200/ACK/BYE/200 OK


Difference between Call, Dialogue, Session
A call is an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation.
A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier, local tag, and a remote tag.
A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers.


SUBSCRIBE Method
When a SUBSCRIBE request is sent to a PINT Server, it indicates that a user wishes to receive information about the status of a service session. The request identifies the session of interest by including the original session description along with the request, using the SDP global-session-id that forms part of the origin-field to identify the service session uniquely. The SUBSCRIBE request (like any other SIP request about an ongoing session) is sent to the same server as was sent the original INVITE, or to a server which was specified in the Contact: field within a subsequent response (this might well be the PINT gateway for the session).

In principle, a user might send a SUBSCRIBE request after the telephone network service has completed. This allows, for example, checking up "the morning after" to see if the fax was successfully transmitted. However, a PINT gateway is only required to keep state about a call for as long as it indicated previously in an Expires: header sent within the response to the original INVITE message that triggered the service session, within the response to the SUBSCRIBE message, within the response to any UNSUBSCRIBE message, or within its own UNSUBSCRIBE message.


NOTIFY Method
During the subscription period, the Gateway may, from time to time, send a spontaneous NOTIFY request to the entity indicated in the Contact: header of the "opening" SUBSCRIBE request. Normally this will happen as a result of any change in the status of the service session for which the Requestor has subscribed. The receiving user agent server MUST acknowledge this by returning a final response (normally a "200 OK"). In this version of the PINT extensions, the Gateway is not required to support redirects (3xx codes), and so may treat them as a failure. Thus, if the response code class is above 2xx then this may be treated by the Gateway as a failure of the monitoring session, and in that situation it will immediately attempt to close the session (see next). The NOTIFY request contains the modified session description. For example, the Gateway may be able to indicate a more accurate start or stop time.

REFER Method
A REFER request enables the sender of the request to instruct the receiver to contact a third party using the contact details provided in the request. Call Transfer is a commonly used application of the REFER method.

Proxy Forking: parallel/sequential
Eg: All the phones ringing simultaneously is an example of parallel fork while when first phone rings then second is tried then next is an example of sequential Fork.

How to DeRegister/DeSubscribe
Give the timer expiry value 0 for DeRegistration. For fetching scenarios incase of subscription, give timer expiry value 0.

Mandatory Headers in SIP
Request/Status line, To, From, CallId, CSeq, Max-Forward
Difference between Transaction and Dialogue
INVITE/200 OK --> 1 Transaction
ACK --> 1 Transaction
CANCEL/200 OK --> 1 Transaction
INVITE/200 OK/ACK --> 1 Dialogue


Different states of Dialogue
Early, ..., Confirm [active, proceeding, pending, terminated]


Difference between Stateless and Stateful Proxy


Difference between Call Stateful and Transaction Stateful Proxy
As its name implies, a transaction stateful proxy maintains state associated with a single transaction. Once the transaction is complete, it does not maintain any information about the dialog and generally does not need to stay in the signaling path for subsequent messages.
A call stateful proxy maintains state for the duration of the dialog. It therefore needs to receive all subsequent requests and responses that are related to the session. This can be accomplished using the Record-Route and Route headers.


Address-Of-Record (Public URI)
Public URI, also called AOR is registered with the Registrar server.


Timer C
Timer C is sent at 60 second intervals when not reliable and is sent at 150 second intervals when reliable.


How is a re-invite treated if the UAC has not answered a call yet?
We can't send an INVITE while the first INVITE is pending. We should use UPDATE.


UPDATE Method
UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but unlike re-INVITE, it can be sent before the initial INVITE has been completed. This makes it very useful for updating session parameters within early dialogs.



SDP Description

Session
Time
Media



Type
Value
Type
Value
Type
Value
v
Protocol version
t
Time the session is active
m
Media name and transport address
o
Owner/creator and session identifier
r
Zero or more repeat times
i
Media title
s
Session name


c
Connection information
i
Session information


b
Bandwidth information
u
Uniform Resource Identifier (URI) of description


k
Encryption key
e
E-mail address


a
Zero or more media attribute lines
p
Phone number




c
Connection information




b
Bandwidth information




z
Time zone adjustments




a
Zero or more session attribute lines






PRACK Method
The PRACK request plays the same role as ACK, but for provisional responses. There is an important difference, however. PRACK is a normal SIP message, like BYE. As such, its own reliability is ensured hop-by-hop through each stateful proxy. Also like BYE, but unlike ACK, PRACK has its own response. If this were not the case, the PRACK message could not traverse proxy servers compliant to RFC 2543.

PRACK is one of the methods in SIP which establishes the concept of early media successfully. The other one is UPADTE. PRACK is the only request that acts as a response to a response i.e. 183 reliable.

OPTION Method
Queries the capabilities of the server or other devices. It can be used to check media capabilities before issuing an INVITE.


REGISTER Method
Registration entails sending a REGISTER request to a special type of UAS known as a registrar. A registrar acts as the front end to the location service for a domain, reading and writing mappings based on the contents of REGISTER requests. This location service is then typically consulted by a proxy server that is responsible for routing requests for that domain.

A registration occurs when a client needs to inform a proxy or redirect server of its location. During this process, the client sends a REGISTER request to the proxy or redirect server and includes the address (or addresses) at which it can be reached.


UNSUBSCRIBE Method
At some point, either the Client's representative User Agent Server or the Gateway may decide to terminate the monitoring session. This is achieved by sending an UNSUBSCRIBE request to the correspondent server. Such a request indicates that the sender intends to close the monitoring session immediately, and, on receipt of the final response from the receiving server, the session is deemed over.
Note that unlike the SUBSCRIBE request, which is never sent by a PINT gateway, an UNSUBSCRIBE request can be sent by a PINT gateway to the User Agent Server to indicate that the monitoring session is closed. (This is analogous to the fact that a gateway never sends an INVITE, although it can send a BYE to indicate that a telephone call has ended.)


MESSAGE Method
Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation.
MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request.

The size of MESSAGE requests outside of a media session MUST NOT exceed 1300 bytes, unless the UAC has positive knowledge that the message will not traverse a congestion-unsafe link at any hop, or that the message size is at least 200 bytes less than the lowest MTU value found en route to the UAS. Larger payloads may be sent as part of a media session, or using some type of content-indirection.

INFO Method
The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. The INFO method is used for transferring information during a session, such as user activity.


Consider a scenario when INVITE is sent, provisional responses are transmitted, and PRACK is acknowledged. After PRACK do provisional responses will be retransmitted?
PRACK ceases retransmission of provisional responses. So no more retransmissions of reliable provisional responses.


If Contact in 302 is
sip:21312@1.1.1.1;sdfs=sd;msdf=21342;shabba=dabbathen Request URI of redirected INVITE would beINVITE sip:21312@1.1.1.1 SIP/2.0

Rather if Contact in 302 isthen Request URI of redirected INVITE would beINVITEsip:21312@1.1.1.1;sdfs=sd;msdf=21342;shabba=dabba SIP/2.0

For the 1st case, "sdfs=sd;msdf=21342;shabba=dabba" is contact-param whereas for 2nd case it is uri-parameters. As per RFC 3261, entire URI of Contact Header is copied to request URI except method-param and headers URI parameters. The contact-param is notcopied.

What is a Softswitch?A softswitch sits at the interconnect point between an IP network and other networks and controls the media gateways using a master/slave protocol such as MGCP. It also translates signaling protocols from one environment to another (e.g SIP to SS7). Softswitches are also known as Media Gateway Controllers (MGCs) and Call Agents.

How does SIP relate to MGCP/Megaco?MGCP/Megaco and SIP are not peers; they can and will co-exist in converged networks. Though MGCP/Megaco can control end-points, the services thus enabled are very limited. SIP, therefore, is required to control end-points and also to communicate between softswitches. MGCP/Megaco is used to internally control the media gateway.

Difference between Loose and Strict Source Routing
Both loose and strict routing use the Route header.Strict routing (with more than zero intermediaries) attempts to carry information about the request target and the next hop to be reached in the Request-URI.Loose routing leaves the request target in the Request-URI and the next hop in the Route header. Loose routing is identified by a lr parameter in the Route URI.

What is the relationship between the From, Contact, Via and Record-Route/Route headers?
All these headers determine how requests and responses are routed in a network of SIP proxy servers. Roughly, the distinction is: - From: Used for subsequent requests from the callee to the caller if there is no Contact or Record-Route header. E.g., if Alice makes a call with From: Alice to Bob, an INVITE request from Bob to Alice would usesip:alice@example.org as the To header and Request-URI. - Contact: Determines the destination placed in the Request-URI for subsequent requests and can be used to bypass proxies _not_ enumerated in a Record-Route header. Also used in responses by redirect servers and in REGISTER requests and responses. - Record-Route/Route: The Record-Route header is inserted into requests by proxies that want to be in the path of subsequent requests for the same call-id. It is then used by the user agent to route subsequent requests. The mechanism is similar to a source-route, as the Record-Route information is copied into a set of Route headers. The Request-URI is set to the first Route header. - Via: Via headers are inserted by servers into requests to detect loops and to allow responses to find their way back to the client. They have no influence on the routing of future requests (or responses). Generally, in short, requests should be sent to Route if present, Contact if there is no Route, From if there is no Contact.
Requests
SIP uses 12 types (methods) of requests:
INVITE—Indicates a user or service 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.
PRACK—Insures reliability of provisional 1xx responses if a UAS supports reliability of provisional responses.
UPDATE—Updates offer for not-yet-established sessions. It can also be used to update session parameters before a call is active.
REFER—The mechanism to initiate a session transfer. It indicates the recipient (identified by the Request-URI) should contact a third party using the contact information provided in the request.
SUBSCRIBE—Subscribes to be notified of an event occurrence.
NOTIFY—Notifies that an event has occurred.
MESSAGE—The means of carrying data for instant messages. The gateway does not support this method.
Responses
The following types of responses are used by SIP and generated by the Cisco SIP Proxy Server:
SIP 1xx—Informational Responses
SIP 2xx—Successful Responses
SIP 3xx—Redirection Responses
SIP 4xx—Client Failure Responses
SIP 5xx—Server Failure Responses
SIP 6xx—Global Failure Responses

Session timersThe need for the addition of a session timer was initially motivated by the realization that stateful proxy servers currently have no method of determining the end of a session in certain anomalous situations. For instance, when a user agent fails to send a BYE message at the end of a session or the BYE message gets lost due to network problems. In this situation, the stateful proxy will maintain state for the session and will have no deterministic method for determining when the state no longer applies. With the addition of a session timer to the SIP protocol, the stateful proxy server will have the option of tearing down the session upon the expiration of the session timer. A session timer can also be used for other purposes. For instance, it could be used in the implementation of a prepaid service. In this case all session related signaling would be routed through a SIP server that would control the session time based on a subscriber's prepaid account. The SIP server could use the session timer to force tear down of thesession within a specific time. The session timer could also be used by the user agent as a trigger to indicate to the subscriber that the prepaid account requires more funds to extend the call. The Session-Expires header will be used by UAC to indicate the maximum duration of the session. The Session-Expires header shall be valid only in INVITE requests.

Offer-Answer ModelIn this model, one participant in the session generates an SDP message that constitutes the offer - the set of media streams and codecs the offerer wishes to use, along with the IP addresses and ports the offerer would like to use to receive the media. The offer is conveyed to the other participant, called the answerer. The answerer generates an answer, which is an SDP message that responds to the offer provided by the offerer. The answer has a matching media stream for each stream in the offer, indicating whether the stream is accepted or not, along with the codecs that will be used and the IP addresses and ports that the answerer wants to use to receive media.


Redirect Server and Location service
Redirect server
A redirect server is a device that directs a calling UA to contact an alternate location for calling the called UA.
When receiving a request from a calling UA, the redirect server searches for the location information of the called UA and returns information on a location. This location can be that of the called UA or another proxy server, to which the UA can initiate the session request again. The subsequent procedure is the same as that for calling a called UA directly or for calling a proxy server.
Location server
A location server is a device that provides UA information to proxy and redirect servers; it retains UA information received by a registrar. Normally, location server and registrar are co-located.How does the redirect server know if the user moves to different domain? Will the registration/location server multicast the presence of the user? When a user moves to a new domain (or new IP address), the redirect server knows because the endpoint re-registers. Within the VOCAL architecture, our Redirect server includes the SIP functionality of a redirect, registrar and location server. When an endpoint is moved and it re-registers, the redirect updates the registrar with the new location information.

In which case redirect server will have multiple entries of user location? Is it when user is moving across domains? What is the difference between Location server and redirect server if this is not across the domains?Redirect doesn't really support this today. When it receives a new registration, our redirect over-writes the old contact info for that user / endpoint. This simplifies the location problem, but it does limit some of the cool stuff you could do with forking calls to multiple locations. We've thought about implementing some type of "multiple contactsfor one user" scheme, but we have had neither the time nor the resources to do it. Note that you could also build something like this functionality as a type of feature server, where users could use a web page to enter multiple locations where they could be reached and the feature server could try these locations in series or parallel. Lots of possible combinations of cool stuff.... What Redirect server has to do,, is return the current status of the location of the destination to the caller. This functionality matches much with the location servers' responsibility. The only difference, is location server will be queried by the proxy,redirect, etc servers, while the redirect server is queried by the end client user agent.

Does SIP support the standard telephone features?
Yes. SIP supports, among others:
· call forwarding unconditional, busy, ...
· call transfer (call control spec)
· caller ID
· call hold
· 3-way conferences and multiparty conferencing (call control spec)
· call return ("*69")
· call park (with NOTIFY)
· follow-me
· find-me
· call waiting
· IVR systems
· multiple line presences
· call waiting
· camp on
· call queuing
· automatic call distribution
· do not disturb
Some services, like repetitive dialing, station speed dialing, last number redial and distinctive ringing, are implemented purely in the end system and require no support from the signaling protocol.
How does SIP support caller ID?
Caller-ID is provided by the From SIP header containing the caller's name and "number". The number would most likely be placed in the user field of a SIP URL or appear in a tel: URL.
Since the callee generally does not know or trust the callee's server, only cryptographic signatures can be used to ensure that the information is valid. For example, the outgoing proxy might be operated by an ISP, enterprise or phone company and sign for the identity of the caller, using the signedby parameter, with the identity of the company verified by a public key certificate similar to those used by web sites.
Should SIP be used to join a conference from a web page?
It is possible to embed a SIP URL in a web page, including a session description. Clicking on that link triggers an invitation for the conference listed to the address contained in the URL. Unfortunately, the current standard browsers (Netscape and Internet Explorer) make it difficult or impossible to add support for another URL type.
Until SIP URIs are implemented in standard browsers, data: URLs can be used to implement similar functionality, albeit less elegantly.
If it is desired that following the link directly adds the user to an existing conference, e.g., for a conference "TV guide"-style directory, the data: URL is more appropriate.
Can a SIP-initiated session have zero or one participants?
SIP-initiated sessions can have no or just one participant. Examples of a session with no participants include an invitation to a multicast group with no members (beyond the invited party). Also, SDP sessions can start at a future time relative to the invitation.

How do I charge/bill for Internet telephony using SIP?
This depends on whether you plan to charge for SIP services like directory look-ups, call processing or mobility, for gateway services to the PSTN, or for carrying media data:
SIP services
The Authorization header can be used to indicate a customer identity that associates a SIP request with a billable entity.
Examples of possibly chargeable SIP services include:
· Directory services such as SIP proxy/redirect lookups;
· Customer profile management;
SIP server operations can be charged based on server logs or, for real-time billing, via AAA.
Media services
Media services include retrieving and storing voice mail, as well as transcoding of media streams. They are not initiated by SIP, but, for example, via RTSP.

Gateway services
Similar to SIP services. Care has to be taken to stop billing when (say) RTP voice data is no longer flowing through the gateway. The gateway will generate call detail records (CDRs) either directly or through RADIUS.

Transport (network services)
It seems unlikely that voice calls carried over a best-effort service will generate per-minute charges. When reserving bandwidth or guaranteeing other quality-of-service parameters, the resource reservation protocol or differentiated services are the appropriate mechanism for including charging. These reservation protocols will likely be used in applications that are not initiated by SIP, for example, audio/video on demand or VPNs. Actual accounting records may be generated by AAA protocols (e.g., by policy enforcement points (PEP) or policy decision points (PDP)) or log files.
Under some circumstances, a SIP proxy server may be useful to initiate such reservations or differentiated services treatment on behalf of a call, since it may be easier to authenticate the SIP request than the lower-layer reservation request or the end system may not be capable of making reservations or marking packets. In those cases, the SIP proxy would initiate a resource reservation and "charge back" the caller identified by the SIP request.
How do prepaid calling cards work in a SIP network?
Note that, in general, prepaid calling cards only make sense in an IP network if there is a special-purpose VoIP internet, calls traverse a IP-to-PSTN gateway or VoIP packets receive special treatment. The SIP requests are forced to traverse a stateful proxy, which controls the Internet telephony gateway, router QOS function or firewall, depending on the architecture. When the time is used up, the proxy or gateway issues a BYE request to both parties, using the existing call ID. It also disables the gateway connection, turns of any special QOS treatment for the RTP packets or closes the firewall for that stream. This requires no additions to either caller or callee. Relying on SIP BYE itself only suffices the end systems can be trusted by the network provider not to keep sending packets.


Does SIP carry DTMF?
There are at least two options for carrying DTMF and similar signals in a VoIP network using SIP. First, DTMF can be transported as an RTP payload (RFC 2833). This has the advantage that it provides accurate timing and alignment with the speech RTP packets. Also, media gateways are the most likely to detect and generate tones, so that making it part of the media stream is appropriate. However, under some circumstances, it may be necessary for signaling entities to know about DTMF signals. Currently, there is no standardized solution within SIP, but it has been proposed to carry DTMF information in SIP INFO messages, either encoded as simple text or using the RFC 2833 format. The latter is more complex, but offers duration and timing information.

What does the [H14.17] in RFC 2453 stand for?
This is explained in Section 3 of RFC 2543. It refers to the section number in the HTTP/1.1 specification.

Do callers need to know the location of the Location Server?
The caller doesn't interact with the location server directly. A redirect or proxy server asks the location server (which may be co-resident with the SIP server or not) for "advice". The location server is just a logical abstraction to indicate where the SIP server gets its information from. The protocol between SIP server and location server is beyond the scope of SIP. Examples of location servers include
· finger;
· LDAP/X.500;
· whois, whois++;
· ph and other local directories;
· shared file systems with registration on login;
· local SQL databases reached through TCP.
Also, callers don't register with the location server.
Which parts of SIP are case-sensitive and which are case-insensitive?
Method
CS
Header field name
CI
Hide
CI
Accept-Encoding
CI
Accept
CI
Accept-Language
CI
Encoding name (PCMU, L16, etc.)
CI
rfc1123-date
CS




What is the difference between a call leg and a call id?
A call leg refers to the one-to-one signaling relationship between two user agents (UAs). The Call-ID is an identifier, carried in the SIP messages, that refers to the call. A call is a collection of call legs. A UAC starts by sending an INVITE; because of forking, it may receive multiple 200 OKs from different UAs. Each corresponds to a different call leg within the same call. Call is thus a grouping of call legs. In the call control spec, additional call legs are created through the Also header.
Call legs refer to end-to-end connections between user agents, rather than any relationship with proxies. Within a call leg, there are numerous transactions in both directions.
The request URI is not used in call leg identification.
The To and From field relate to local and remote in the following way. When Alice sends a request on a call leg to Bob, the From field contains the local address (Alice), and the To field the remote address (Bob). When a request is received by Bob, the To field is matched to Bob's local address, and the From field to the remote address (Alice).
The CSeq spaces in the two directions of a call leg are independent. Within a single direction, the sequence number is incremented for each transaction.
What is the difference between tag and branch-id?
Branch IDs allow proxies to match responses to forked requests. Without them, a proxy wouldn't be able to tell which branch a response corresponds to. Tags, in To headers, are of no help here since they are not known until responses arrive. Tags are used by the UAC to distinguish multiple final responses from different UAS.
A UAS has no reliable way of determining if the request has been forked or not. Thus, to be safe it needs to add a tag. Proxies only insert tags into the final responses they generate themselves; they never insert tags into requests or responses they forward.
Since a request can be forked several times on its way to UAS, a single "tag" (or whatever you like to call it) added to the request by one of the proxies is not sufficient for the next forking proxy along the chain to match responses on its own branches; every proxy that forked the request would need to add its own unique IDs to the branches it created. This is precisely what's being achieved by the branch parameter in the Via header. (Igor Slepchin)
How can one recognize a retransmitted, duplicate or looped request?
header
retransmitted
duplicate
matching response
From
same
same
same
To
same
same
same, but tag may have been added
Call-ID
same
same
same
request URI
same
same
same
CSeq
same
same
same
Via
-
-
must be local host; check for branch parameter to identify which branch
Looped request are recognized by one or more of the following:
· The server finds itself in the request's Via list, including any branch parameter. (The server should compute the branch parameter so that it depends on the request URI.)
· The server is about to proxy the request to one of the hosts listed in the Via list. The same
· The Max-Forward count is decremented to zero.
· The Expires time has elapsed.
What is the relationship between the From, Contact, Via and Record-Route/Route headers?
All these headers determine how requests and responses are routed in a network of SIP proxy servers. Roughly, the distinction is:
From:
Used for subsequent requests if there is no Contact or Record-Route header. E.g., if Alice makes a call with From: Alice to Bob, an INVITE request from Bob to Alice would use alice@example.org as the To header and Request-URI.
Contact:
Determines the destination placed in the Request-URI for subsequent requests and can be used to bypass proxies not enumerated in a Record-Route header. Also used in responses by redirect servers and in REGISTER requests and responses.
Record-Route/Route:
The Record-Route header is inserted into requests by proxies that want to be in the path of subsequent requests for the same call-id. It is then used by the user agent to route subsequent requests. The mechanism is similar to a source-route, copying the Record-Route information into a set of Route headers. The Request-URI is set to the first Route header.
Via:
Via headers are inserted by servers into requests to detect loops and to allow responses to find their way back to the client. They have no influence on the routing of future requests (or responses).
Generally, in short, requests should be sent to Route if present, Contact if there is no Route, From if there is no Contact.

How are URLs compared?
Two SIP URLs are compared for equality according to the following rules:
· the display name is ignored;
· tags must match;
· user, password, host, port and parameters of the URI must match. If a component is omitted, it matches based on its default value.
· string comparisons are case-insensitive;
· Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396) are equivalent to their ""%" HEX HEX" encoding.
· An IP address that is the result of a DNS lookup on a hostname does not match that hostname.
Does SIP do admission control?
Since this offers no real security (calls could always bypass a servr), admission control is not supported by SIP. If an "outbound proxy" is used for outgoing calls, that proxy may control the firewall and thus restrict outgoing calls.

Does SIP administer bandwidth?
No, that is the role of a resource reservation protocol. There is no reason to assume that any Internet telephony signaling server (such as a proxy) would know the available bandwidth in real networks. Having such a central server would not scale. Administering bandwidth separately for each application is also likely to be difficult and inefficient.
There is a proposal for an SDP extension that allows SIP INVITE requests and responses to indicate that resource reservation must succeed before the callee is alerted.

What's the difference between the request URIs tel:+12125551212 and sip:12125551212@gw.com?
Non-SIP URLs, such as tel:+12125551212 for a telephone number, may be used as request URIs in SIP INVITE requests. This only makes sense if all outbound calls are handled by a proxy server. In the case of a tel: URL, the proxy server would then translate the request URL to a SIP URL of a gateway server, if it is not handling the gateway duty itself. The proxy server might use the Gateway Location Protocol (GLP) to find the appropriate next-hop SIP server. The To header may always be a tel: URL even if the Request-URI is a SIP URL, although that breaks with the common practice that Request-URI and To start out the same.

Do I always need a proxy or redirect server?
No, two SIP servers can contact each other directly.


How does a caller find its local registrar?
The local registrar is either manually configured or, more likely, the SIP client issues a multicast registration request to the sip.mcast.net standard multicast address, which all registrars listen to.

Is the domain of the request-URI and the To header always the same?
The Request-URI names the destination of the registration request, i.e., the domain of the registrar. The user name must be empty. Generally, the domains in the Request-URI and the To header field have the same value; however, it is possible to register as a "visitor", while maintaining one's name. For example, a traveler sip:alice@acme.com (To) might register under the Request-URI sip:atlanta.hiayh.org, with the former as the To header field and the latter as the Request-URI. Note, however, that requests for a user at acme.com are not likely to arrive at the atlanta.hiayah.org server; special purpose routing logic will generally need to be established in order for requests for alice@acme.com to go to the atlanta.hiayh.org server. In the vast majority of cases, the domains in the request URI and To field will match. The REGISTER request is no longer forwarded once it has reached the server whose authoritative domain is the one listed in the Request-URI.

How do I ensure registrar reliability?
There are several techniques that can be used to minimize the impact of registrar/proxy server failures for a server in a local area network:
· Run several servers that all respond to the same multicast registration address ("warm standby"). As long as multicast requests are mostly reliable, this ensures a consistent registration picture.
· If a registration server is rebooted and does not have complete knowledge of the local UA population, it could multicast any incoming INVITE requests.
For servers separated from their client by a wide-area network, use of multicast is not appropriate, so that these servers have to rely on traditional backup techniques to achieve reliability. For example, the designated registrar could multicast registration updates within its local network to keep standby servers synchronized.
Are ACK requests retransmitted?
No. An ACK is sent when a response retransmission is received. Reliability is achieved because the response is retransmitted until an ACK arrives, and the ACK is retransmitted on response retransmissions. ACK is only used for INVITE.

How are BYE requests routed?
Since a Contact header MUST be present in INVITE and 200, the BYE will go directly to the user agent if there is no Record-Route header. If there is a Record-Route, it will traverse the list of proxies indicated there.
If the caller decides to send a BYE before receiving a 200 from the callee, the BYE is be handled by the proxies just as the corresponding INVITE was handled, i.e., it may be forked.
Can I CANCEL requests other than the first INVITE?
Yes, any request can be cancelled before it has been executed by the UAS. However, it is likely that this will only make sense in practice for the initial INVITE and subsequent "re"INVITE. In the latter case, the call remains, just any changes requests are cancelled.

How does a caller find its proxy server?
Calls typically proceed directly to the callee's domain. For example, when calling alice@example.com, the INVITE request would be sent to the SIP server for the domain example.com, found via DNS.
If a "local" (outbound) proxy is needed for outgoing calls, it currently needs to be manually configured, similar to the configuration of web proxies in browsers. Extensions to (for example) use a REGISTER response or DHCP are under discussion.
What's the difference between a stateless and a stateful proxy server?
Stateless proxies forget about the SIP request once it has been forwarded. Stateful proxies remember the request after it has been forwarded, so they can associate the response with some internal state. In other words, stateful proxies maintain transaction state. Stateful implies transaction state, not call state.
Stateless proxies scale very well, and can be very fast. They are good for network cores. Stateful proxies can do more (they can fork, for example, see the next question) and can provide services stateless ones can't (call forward busy, for example). They don't scale as much as stateless ones. An admininstrator gets to decide which to use. These are also logical entities; a physical proxy is likely to act as a stateless proxy for some calls, stateful for others, and as a redirect server for even others.
Neither stateful nor stateless proxies need to maintain call state, although they can, but will need to make sure that they are part of subsequent transactions via the Record-Route header.
Proxies must be stateful if one of the following conditions hold:
1. uses TCP,
2. uses multicast,
3. forks.
Why can a forking SIP proxy not be stateless?
A forking SIP proxy cannot be stateless because it needs to perform a filtering operation, returning (in general) one response out of the many it receives. For example, a forking proxy with three branches, that receives a 200-class, 400-class, and 500-class response on each branch respectively, should return only the 200-class response upstream. If the proxy were stateless, it would end up returning all three of the responses upstream (since it won't remember that it had received prior responses when it gets another one). The result of this is (1) response implosion at the client, and (2) inconsistent responses at the client. (In this example, depending on the order the responses would be received, the client would think that the call failed, just to get a success indication some time later.) Thus, a forking proxy must be stateful.
Also note that a proxy that uses TCP must be stateful as well, whether it forks or not. This has to do with reliability issues.
Why do you want state in a proxy? Certain services (like forking) simply require it. A sequential search proxy requires state; sequential search is the heart of services like follow-me and personal mobility. It's at the discretion of the implementor whether to use a stateful or stateless proxy. You can even be "super stateful", and use the Record-Route header to allow a proxy to be on the signaling path of all subsequent exchanges. This allows a stateful proxy to maintain call state in addition to transaction state.
How does a caller find the remote SIP client of the callee?
The process is similar to the delivery of email: The caller uses the SIP host name to look up the destination host, first trying a SRV record and then "regular" DNS, just like an email client (MTA) looks up the MX record. (SRV records are generalized MX records applicable to any network service, including, but not limited to, SIP and RTSP.) For example, when contacting bell@cs.columbia.edu, the client finds a SRV record pointing to erlang.cs.columbia.edu as the SIP server for the domain cs.columbia.edu. As for email, a single domain name can resolve to multiple servers, allowing load sharing and redundancy.
The server located in this manner can then proxy or forward the call to another server.
How does SIP get through a firewall?
There are several possible approaches to SIP-capable firewalls. One of the difficulties is that, unlike for, say, HTTP, connections are originated both by hosts inside and outside the firewall. A likely arrangement is that a SIP proxy sits "on" the firewall and relays SIP requests between the Internet and the intranet. Thix proxy would also open up the necessary ports in the firewall to let audio and video flow through, for example using Socks V5.
As an alternative, if a firewall or NAT allows outgoing TCP connections, the inside client can open up a TCP connection to an outside proxy. All outgoing and incoming calls would then be handled by that TCP connection. (The client would still have to use SOCKS or similar mechanism to convince the firewall to let RTP packets through.)
How does SIP do "call progress tones" or "ring back"?
The SIP server being called, such as an Internet telephony gateway, can return any number of provisional status messages that indicate call progress. Typically, this is just 100 (Trying) followed by 180 (Ringing), but a server could produce elaborate feedback such as 100 Message received100 Looking up number100 Found number, looking up carrier according to profile100 Finding cheapest carrier which doesn't do animal testing100 Found carrier "AT&T"100 Dialing number180 Ringing182 Queued, 3 people in front of you182 Queued, 2 people in front of you
The language of the status message should be determined based on the Accept-Language request header in the call.
A 183 (Session Progress) status response will appear in RFC2543bis. It can be used for both progress tones as well as error messages.
One would use the 183 only if you:
· Are able to determine that the audio being generated is something other than ringing (e.g. "comfort tone" or "pay tone" as defined in E.18x), or
· Are unable to definitively determine that alerting is occuring. This really should only happen with older CAS protocols. ISUP and ISDN have sufficient information to determine what is happening on the far end.
One can also use 183 if the gateway is able to determine that an error has occured, but that there is a tone or announcement accompanying it (e.g., an ACM with a cause code present). In that case, the gateway can send a 183 to set up the media for the announcement (ideally with the announcement text as the text string), wait for a timer (on the order of 30 seconds), and then send an appropriate SIP error message.
However, this should only be done if the caller is likely a human being, as sending 183 would otherwise only delay failure handling.
Does SIP do keep-alive?
SIP itself does not have a keep-alive mechanism during the call. It was felt that loss of connectivity would be detected rapidly by the absence of media packets, typically sent at a much higher rate than any signaling keep-alive messages could be sent. In addition, the signaling path is not needed during the conversation and may well be completely different (due to proxy and redirect servers) than the media path, so that keep-alives have a limited functionality. If it is desired to test the liveness of a signaling server, it is always possible to send either OPTIONS or (re)INVITE messages.

Why does SIP not have a Content-Transfer-Encoding header?
The Content-Transfer-Encoding header was primarily meant to allow message bodies to be transformed into formats that could be transferred on channels that were not 8 bit clean. HTTP, which makes use of many of the MIME headers, is 8 bit clean, and thus did not need Content-Transfer-Encoding. SIP followed suit, and so does not use it either. Content-Encoding is used for things like compression, which is different. (J. Rosenberg)

I want SIP to be more compact. What can I do?
First, one should realize that in general, SIP exchanges are only going to be a tiny fraction of the overall session bandwidth. A typical SIP call setup takes less than 1000 bytes, or the equivalent of one second of highly compressed (G.729) audio. Some additional space savings can be realized by using short headers. (A realistic example for an audio call setup takes a total of about 640 bytes, of which about 69 bytes are SIP headers.)
In general, more substantive savings are possible by using either payload compression (RFC 2393) or link-layer compression, e.g., at the PPP layer. For the example above, the total size is reduced to about 520 bytes with gzip compression.
Does SIP do conference control?
SIP leaves conference control, such as the election of a chair or floor control, to other protocols. SIP can be used for non-conferencing applications and floor control may be used outside the scope of SIP-initiated calls, so it seemed best to separate the functionality. However, SDP may be used to indicate which media are subject to floor control and what tools and protocols are to be used. Unfortunately, there is no IETF-standardized floor control protocol.

What is the relationship between MGCP and SIP?
The details of combining the two in a system are still being fleshed out. MGCP is a device control protocol, where a slave (gateway (MG)) is controlled by a master (media gateway controller (MGC), call agent). SIP may be used between controllers, in a peer-to-peer relationship. Note that to the SIP side, the MGC looks like a node with a large number of connections, but otherwise the same as a "native" SIP device. Similarly, the MG is completely unaware that the call between MGCs is established via SIP. Only the MGC needs to understand both protocols.


What is SIP+ and how does it relate to SIP
SIP+ was a proposal by Level3 on how to extend SIP to interconnect two MGCs. This functionality is now being provided by various orthogonal SIP extensions, including the carriage of multipart MIME types, the INFO method and others. These are being documented in a BCP draft. The name SIP+ is obsolete and should not be used to avoid confusion.

Can H.323 and SIP be used together?
Yes. SIP can locate the called party and determine its capabilities, including H.323. H.323 is then used to connect the two parties.
Unfortunately, there is currently no specification on translating between the two. Conversion is made more difficult by the multiple versions of H.323 (v1, v2, v3). However, there is at least one product (Lucent PacketStar IP) that allows SIP and H.323 terminals to call each other.
How do I interconnect Q.931 (ISDN signaling) and SIP?
A gateway that initiates an ISDN call based on a SIP call or vice versa is reasonably straightforward, as sketched in this figure.


How do I interconnect ISUP (SS7 signaling) and SIP?
SIP can be used either between SS7 nodes or to trigger a phone call in an SS7 network. While all the details have not been worked out, the basic call flow is similar to the ISDN case.

What are the different addresses in SIP?
SIP INVITE requests involve three addresses:
1. The host address where the request came from. Responses are sent back to the same host address, regardless of what the From header indicates. Note that different requests for the same call can come from different hosts.
2. The From address contains the logical source of the request. It remains unmodified as a SIP request traverses proxies, for example. The From address may not be the same as the host address that generated the SIP request, although that's the typical case.
3. The session description (e.g., SDP) contains one or more addresses where the caller expects media data (audio, video) to be sent. For some services, this address may not be the same as the From address.
Can SIP be used for Internet telephony gateways (ITGs)?
Yes, in two ways. First, it can indicate to the Internet-based caller that the callee is reachable via an ITG, via the Contact header. Secondly, two ITGs connecting parties on the PSTN can signal new calls to each other, with the destination phone number contained in the request URL.

How do I put a call on hold?
The party wishing to put the other party on hold sends a (re)INVITE, with a session description containing a null (0.0.0.0) address. When used with SDP, the ``c'' address field of one or more media types is set to zero.


When a subscriber gets a NOTIFY with a lower CSEQ, can it return an error and still keep the subscription? Should it return 200 OK?
If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number, the request is out of order and MUST be rejected with a 500 (Server Internal Error) response.500 (Server Internal Error) responses do not kill the dialog, only the transaction.


What will happen if a sip message when a sip response has more than one via header?
If more than one Via header field value is present in a response, the UAC SHOULD discard the message. The presence of additional Via header field values that precede the originator of the request suggests that the message was misrouted or possibly corrupted.


If a UAS receives an INVITE with more value in the route header field, what shall the UAS do? Ignore or forward according to the route header field? How could a UAS identify the request is for itself, if the UAS has a role of proxy?
SIP Entity must have the capability to analyze the request, If the Request Line URI having your URI or number then it is belongs to you... Otherwise do the following, a) Discard that invite if it is a UAb) Process and forward that INVITE to the Next hop as specified in Route Header ... If it act as a proxy (or proxy & UA).


When should a BYE pass through an intermediate proxy vs. going right to the UAS?Upon receiving a BYE, where should the OK be sent? To the the IP address in the CONTACT or the FROM?
The BYE is routed according to rules for in-dialog requests. See rfc3261, section 12.2.1.1, in particular the discussion of remote target and route set. Once the next-hop has been identified, the procedure in rfc3261, section 8.1.2 is used to calculate the address of the next-hop server. The 200 OK to BYE is sent to the address in the top-most Via header (rfc3261, section 18.2.2).


To-Tag
The UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response or a final response that does establish a dialog, in which a tag MAY be present)

Use of To-Tag
If the request forks and several UASs return final responses, the final responses may be distinguished and identified by their to-tags.
How do I achieve, that an inbound Invite will pass the proxy? I'm sure that I have to modify the Register Message of that client with the information, that Requests must be sent to the proxy, but I don't know why.
The SIP application can modify the contact of REGISTER message with its own address. This shall ensure that any inbound INVITE message for that client shall reach to your SIP application. or
Path extension header (RFC3327) can also help Registrar server to know about the path to be used for inbound message towards an address-of-record (client in your case). If your SIP application puts its address in Path header then inbound INVITE shall reach to yourSIP application.


Use of branch parameterThe "branch" parameter is included by every forking proxy. The token MUST be unique for each distinct request generated when a proxy forks. CANCEL requests MUST have the same branch value as the corresponding forked request. When a response arrives at the proxy it can use the branch value to figure out which branch the response corresponds to. A proxy which generates a single request (non- forking) MAY also insert the "branch" parameter. CANCEL and non-200 ACK requests MUST have the same branch parameter value as the corresponding request they cancel or acknowledge.


Difference between 181 and 3xx
The proxy sends back a 181 response to the caller to indicate that the original call is being forwarded to a new destination (URI) & subsequently sends an INVITE to the new callee.
181 is used to inform the UAC that the call is being forwarded (by the UAS or some intermediate proxy, I suppose). I assume that the reason for this response is that a forwarded call might have a longer set-up time (until a 180 is returned to the UAC) than usual, so the UAS wishes to reassure the UAC that the call is making progress. The 181 response must have a to-tag. But the UAC can choose its own to-tag for the 181, as (in principal) the 181 is a response to a separate fork of the INVITE than the fork that is being forwarded to its ultimate destination.
The difference between 181 and 3xx level forwarding is that 181 indicate proxy level forwarding while 3xx response is mostly used in UA level forwarding.


UAC sends out INVITE UAS responds with RINGING UAC sends out CANCEL UAS does not respond to CANCEL (for example, it dies). UAC cancel transaction Times Out.Should the UAC also delete the INVITE Client Transaction that it was originally trying to CANCEL?
Yes, also because older UAS won't send 487 responses for INVITE anyway, so the UAC needs to handle this case.
Should a proxy server also do this action (i.e. Terminate the INVITE if the CANCEL times out?
When proxy received Cancel, it should send response 200. Cancel is hop by hop, not end to end. The timeout of Cancel transaction shouldn't affect ICT. If UAS dies, proxy should return 408 when Timer C fire, and UAC should maintain a timer for IOC in case of proxy dies.
CANCEL can terminate any pending request other than ACK or CANCEL; it is typically useful only for INVITE. If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request Option Tags Option tags are used in header fields such as Require, Supported, Proxy-Require, and Unsupported in support of SIP compatibility mechanisms for extensions. The option tag itself is a string that is associated with a particular SIP option (that is, an extension). It identifies the option to SIP endpoints. Option tags are case-insensitive.Eg: 100rel, early-session, eventlist, histinfo, join. path, replaces. timer, privacy. RFC 3261 section 18.3 Framing says "In the case of message-oriented transports (such as UDP), if the message has a Content-Length header field, the message body is assumed to contain that many bytes. If there are additional bytes in the transport packet beyond the end of the body, they MUST be discarded. If the transport packet ends before the end of the message body, this is considered an error. If the message is a response, it MUST be discarded. If the message is a request, the element SHOULD generate a 400 (Bad Request) response. If the message has no Content-Length header field, the message body is assumed to end at the end of the transport packet.

In the case of stream-oriented transports such as TCP, the Content-Length header field indicates the size of the body. The Content-Length header field MUST be used with stream oriented transports."

How should a UAS behave in case it receives a message on TCP having content-length value
1] less than message body length?
2] Greater than message body length?When using TCP, if the sender screws up and includes a body that is larger than the Content-Length says, then the recipient will see this as a body that has been truncated based on the content-length value. This can't be detected by sip level parsing, but *may* be detected if/when the body is parsed, because the body is likely to appear incomplete.
And in that case, the part of the body supplied by the sender that extends beyond the content-length value will be parsed by the recipient as the beginning of a new message. Most likely it won't be a valid beginning of a SIP message, and so error recovery will take place at that point. (It won't result in an error response because there isn't a message to respond to.)
On the flip side, if the sender includes a body that is smaller than specified by the Content-Length header, then one of two things will happen:- the end of the tcp stream will be detected before all the bytes called for by the content-length have been received. In this case an error can be generated, but a new connection will need to be established to deliver it.
- Reading of bytes for the message will stall until the sender sends another sip message. Then some of that message will be interpreted as the missing part of the body. Again, at the sip level this won't cause any problem for *that* message, but an error may be detected in the syntax of the body if/when the body is parsed. After processing that message, there will be an attempt to process the remaining bytes as a sip message. Because the header of that message has already been consumed as part of the prior body, the remainder won't be a valid beginning of a SIP message, and so an error recover will take place.


If we have started a OOD-REFER and wish to CANCEL the dialog; i.e. the originator of the dialog wishes the cancel the Dialog. Can I send a CANCEL message if we have not received a confirmation 2xx message and a BYE message if we have received a dialog Confirmation?
You can not send a CANCEL to cancel REFER. You can send another REFER with method CANCEL/BYE in Refer-To header to terminate the dialog created as a result of initial REFER. That also needs you to know the dialog identifiers of that dialog that you want to cancel or bye. You can get that by subscribing to "dialog" event package.


When the transaction is at "Proceeding" state (i.e.: after client receiving the 1xx response), the only way to move the transaction to next state is to receive final response (200-699). Then what happen if final response is lost, would the client transaction be stuck in this state forever and never terminated? By looking at the text description in section 17.1.1.2, I could not find any clear statement say Timer B should continue at this state or not. How it works if there's no timer?The state machine for the INVITE transaction has no timer for exiting the proceeding state. This is an application layer problem. Proxies use timer C to control exit, and UAs do whatever they want to give up at some point and send CANCEL. This remains unclear to people, probably because text on this subject doesn’t appear in the transaction section itself.

When should timer B be stopped after reaching "proceeding" state "confirmed" state? Or should it be stopped at all?Timer B should be stopped the moment a provisional response is received, i.e., when the FSM enters the "Proceeding" state. From the FSM diagram, it is clear that there are no transitions corresponding to timer after the FSM leaves the "calling" state. If you let this timer run, the transaction may (depending on your implementation) timeout even after receiving a provisional response. For following scenario.
1. Alice send INVITE to Bob.
2. Before receiving any message, Alice terminated the call. In the other word, it send CANCEL to Bob.
3. Because of using UDP or some other reasons, Bob receives CANCEL before INVITE.
4. Bob send 481 for CANCEL, and then process INVITE, 180 or 200 will be sent.
5. Alice receive 481, then cease retransmission of CANCEL. After that Alice receives 180 or 200.
Q1. Now what should be taken to inform Bob to cease the retransmission, or just let it be?
Q2. The other reason in 3 may be that the retransmission of INVITE cannot ceased by sending CANCEL. So can the INVITE transaction be ceased by sending CANCEL?Section 9.1 of RFC 3261, “If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request ".. Is it possible to send a final response to the initial request before having received PRACK?It depends ... RFC 3262 says: The UAS MAY send a final response to the initial request before having received PRACKs for all unacknowledged reliable provisional responses, unless the final response is 2xx and any of the unacknowledged reliable provisional responses contained a session description. In that case, it MUST NOT send a final response until those provisional responses are acknowledged.
The scenario is basically like this:UAC ß> SIP PROXY ß---> UAS
- uac send an invite to proxy (the invite is for some client of the remote UAS)- it forwards it to UAS (based on static routing definition or domain info or SRV)- later uas sends a 407 response (proxy auth or www auth), with UAS ip in the Contact header field- the proxy receives this and forward it to UAC (without changeing the Contact field)- here are two behaviors depending the client: a) the UAC send a new invite , with the digest auth, to the proxy b) the UAC send a new invite , with the digest auth, direct to the UAS.
The question is which is the correct behavior? a or b?
"a" is the correct answer because the Contact header field specifies the address where the UAS wants to receive subsequent requests for this dialog. In this case, you received a 4xx response, so no dialog was created. And when the UAC ends the second INVITE request, it should determine the destination using the same routing function it used for the initial INVITE (as you say, static route, DNS SRV, etc). Presumably, that same routingfunction will resolve to the same proxy (although, I guess it could even resolve to a different proxy if, for example, some load sharing were done).

Difference between via and Record Route header
The Via header governs the path that the response will take. The Record-Route header governs the path that subsequent requests within the dialog will take. So the UAS doesn't use the Record-Route header to determine where to send a response.

How the user can abort ongoing call transfer, can i send REFER with "Expires" set to 0 to abort the ongoing call transfer process...?No. Aborting an ongoing REFER is difficult. You have to send a REFER with Target-Dialog specifying the dialog identifiers of the INVITE that was sent in response to the original REFER, and add "?method=BYE" to the Refer-To. This will cause the target UA to send a BYE within the dialog that it started in response to the original REFER.



Push to Talk (PTT)

What is Push to Talk?
Push to Talk (PTT) is a walkie-talkie type service that allows you to instantly reach others by eliminating the dialing and ringing steps in a regular cellular call. Push to Talk calls can be made to one person or to a group of people.

How do I make a Push to Talk call?
The Push to Talk service must be initialized on your phone for it to become active. This is accomplished by pressing the PTT Key and following the prompts. Once initialized, you will need to add other Push to Talk subscribers into your PTT Contacts in order to place a call to them. After adding and saving your contacts press and release the PTT Key to view individuals and groups. Highlight the person you wish to call, then push and hold the PTT Key. You may begin speaking after the tone.
The PTT Contact list will display icons next to each contact indicating whether the person is available to receive Push to Talk calls.

What is the Availability status of the person?
Invitation in Progress: This displays when you have first sent a request to a person to join your contacts. Once the person has accepted your invitation this changes to the appropriate indicating their current availability status
Do Not Disturb: This displays when a person has changed their availability to Do Not Disturb. Push to Talk calls can not be placed to this person.
Silent/Vibrate: This indicates a user has set their ringer to either Silent or Vibrate (ring/vibrate excluded) indicating they are most likely in a quiet environment.
Available: This indicates the person can receive calls.
Unavailable: This displays when a person has turned Push to Talk off, powered down their phone, or if the service has detected that this person is out of coverage. NOTE: A person may show available when they have gone out of coverage. However, call attempts to this person will not go through and once a call is attempted the person's availability will be automatically updated.

What is the Availability status of the group?
Invitation in Progress: This displays when you have first sent a request to establish this group. Once one group member has accepted your invitation this changes to one of the status below.
Do Not Disturb: This displays if everyone in the group has set themselves to Do Not Disturb.
Silent/Vibrate: This displays if everyone in the group has set their ringer to silent/vibrate.
Available: If anyone in the group is available to participate in the group call this will display.
Unavailable: This displays if everyone in the group has logged out of Push to Talk, been detected as out of coverage, or if they have turned their phones off.

What is a PTT Contact? PTT Contacts is the list of other Push to Talk subscribers which you have added to your phone. It is a separate list from your phone's Address Book and can be accessed by pressing and quickly releasing your PTT Key.


Presence Service
· Presence is defined as the willingness and ability of a user to communicate with other users on the network. · SIP is particularly well suited as a presence protocol. SIP location services already contain presence information, in the form of registrations.· Presence User Agent (PUA): A Presence User Agent manipulates presence information for a presentity. · Presence Agent (PA): A presence agent is a SIP user agent which is capable of receiving SUBSCRIBE requests, responding to them, and generating notifications of changes in presence state. · Presence Server: A presence server is a physical entity that can act as either a presence agent or as a proxy server for SUBSCRIBE requests.

No comments: