Purpose
This release of the SIP User Agent implementation supports the following methods, responses, and headers per SIP RFC 2543 Bis-05.
Methods
SIP call control methods identify the type of request that is being made.
|
Method |
Supported |
Description |
Information Reported to Host |
|---|---|---|---|
|
INVITE |
Yes |
Invites a target to participate in a session; establishes a connection. Also used to change call state or capabilities, such as CODEC used. Supported with or without SDP because of the Delayed Media feature. |
The Request for Service message reports the receipt of the INVITE method using the following TLVs: SIP Extensions (0x294A)
|
|
|
|
|
To & From Username are also reported in Called Party Number TLV (0x2717) and Calling Party Number TLV (0x2718) formats respectively Call ID (0x2950) Remote-Party-ID (0x2959) RPID-Privacy (0x295A) Subject Header (0x295B) Top VIA Header. Privacy, P-Asserted-Identity, P-Preferred-Identity, P-Access-Network-Info. Referred-By URI (0x2929) Referred-By parameters (0x292A) Remote Signaling IP address & Port for TCP Calls 0x294E & 0x294F respectively. Media destination IP address, Port, Payload Type and Payload size in the SDP for non-CAM. For CAM it is reported within the Media Local End Point Information (0x29FF). |
|
Re-INVITE (Offer) |
Yes |
Used to change media used for the call and to put a call on/off hold |
PPL Event Indication to report receipt of ReINVITE in the following TLV: If present, SDP is reported within the Local End Point Info TLV (0x29FF) |
|
180 Ringing |
Yes |
The called party is alerted |
PPL Event Indication to report receipt of 180 received: SIP Extensions TLV (0x294A) |
|
182 Called Queued |
Yes |
The called party is unable to take the call immediately so the calling party is put on hold. |
PPL Event Indication to report receipt of 182 received: SIP Extensions (0x294A) |
|
183 Session Progress |
Yes |
Informs about the progress of the call. Mosty used to establish an early media connection. |
PPL Event Indication to report receipt of 183 received: SIP Extensions 0x294A |
|
PRACK |
Yes |
Makes the non-100 provisional responses reliable. |
PPL Event Indication to report receipt of PRACK received. No data reported. |
|
Yes |
Acknowledges receipt of a final response to an invite request |
Not reported to the host. |
|
|
ACK with SDP |
Yes |
Reports receipt of ACK with SDP in case of delayed media scenario. |
PPL Event Indication to report receipt of ACK with SDP contains the following TLV: SDP if present is reported within the Local End Point Information (029FF) |
|
BYE |
Yes |
Indicates that either the originator or the target wishes to end the call after the INVITE transaction is successfully completed. |
Channel released 0x49 in case of CAM. Channel released with data 0x69 in case of non-CAM calls. |
|
CANCEL |
Yes |
Indicates tha the originator wishes to cancel the INVITE request it had sent. |
The host receives a channel-released messages. |
|
REGISTER |
Yes |
Registers with a server |
The PPL Event Indication message reports the receipt of the REGISTER message using the TLVs below. The CSP does not generate the REGISTER message. SIP To Username (0x2919) |
|
REFER |
Yes |
Indicates that the recipient should contact a third party using provided contact information; initiates a transfer. |
The PPL Event Indication reports the receipt of the REFER method in the following TLVs: SIP Request URI User Name (0x2954) The PPL Event Indication reports the recived for REFER (Blind and Consultative) SIP Reponse Code (0x2915) |
|
NOTIFY |
Yes |
Provides information about a state change; not related to specific session. |
The PPL Event Indication to report the receipt of the NOTIFY and the REFER request (Blind and Consulative) sent out. SIP Response Code 0x2915 The CSP support generation of the NOTIFY message. |
|
SUBSCRIBE |
Yes |
Used by a SIP entity to declare its interest in a particular event. SIP entity subscribes to a certain event of a class of events. |
Reporting is not supported. The CSP supports generation of the SUBSCRIBE method. |
|
INFO |
Yes |
Transports any mid call information. |
PPL Event Indication to report receipt of INFO received: SIP Mesasge Body (0x295C) PPL Event Indication to report the response for INFO sent out: SIP Response Code (0x2915) |
|
OPTIONS |
Yes |
Solicits information about features supported by SIP servers such as supported methods and media capabilities. |
PPL Event Indication reports receipt of OPTIONS in the following TLVs: SIP Request URI User Name (0x2954) CSP does not support generation of OPTIONS method. |
SIP response codes indicate the status of a session. Responses with 1xx response codes are also call provisional responses, while the remaining response codes (2xx, 3xx, 4xx, 5xx, and 6xx) indicate final responses.
This release of the SIP Implementation treats the 4xx, 5xx, and 6xx responses as rejected calls.
|
Code Type |
Function |
|---|---|
|
1xx |
Informational: Trying, ringing, forwarding, queuing, in progress |
|
2xx |
Successful: OK |
|
3xx |
Redirection: Indicate additional information for call forwarding |
|
4xx |
Request Failure: Indicate request errors such as missing information |
|
5xx |
Server Failures: Time outs, unavailable services, and other server errors |
|
6xx |
Global Failures: Busy declined, not found, not acceptable |
|
Responses |
Supported |
Notes |
|
100 Trying |
Yes |
|
|
180 Ringing |
Yes |
The called party is alerted. PPL Event Indication message reports receipt of 180 Ringing in the following TLV: SIP Extensions (0x294A) |
|
181 Forwarded |
Yes |
Treated as 180 Ringing Response. |
|
182 Called Queued |
Yes |
The called party is unable to take the call immediately so the calling party is put on hold. PPL Event Indication message reports receipt of 182 Queue using the following TLVs: SIP Extensions (0x294A) |
|
183 Session Progress |
Yes |
Informs the progress of the call. Mostly used to establish an early media connection. PPL Event Indication message reports receipt of 183 Session Progress using the following TLVs: SIP Extensions 0x294A |
|
200 OK |
Yes |
PPL Event Indication to report receipt of Answer using the following TLVs: SIP Contact Display Name (0x292B) SIP Contact Parameters (0x292C) SIP Contact Username (0x292D) Media Local End Point Information (0x29FF) |
|
300 Multiple Choices |
Yes |
Supports Redirections. |
|
301 Moved Permanently |
Yes |
|
|
302 Moved Temporarily |
Yes |
|
|
305 Use Proxy |
Yes |
|
|
380 Alternative Service |
Yes |
|
|
400 Bad Request |
Yes |
For outbound call (UAC), these responses are treated as Call Rejected. |
|
401 Unauthorized |
Yes |
Supports basic and digest. |
|
402 Payment Required |
No |
Treated as Call Rejected. |
|
403 Forbidden |
No |
Treated as Call Rejected. |
|
404 Not Found |
Yes |
Generate and accept responses. For outbound calls, these responses are treated as Call Rejected. |
|
405 Method Not Allowed |
Yes |
Generate and accept responses. For outbound calls, these responses are treated as Call Rejected. |
|
406 Not Acceptable |
No |
Treated as Call Rejected. |
|
407 Proxy Authentication Required |
Yes |
Treated as Call Rejected. |
|
408 Request Timeout |
No |
Treated as Call Rejected. |
|
409 Conflict |
No |
Treated as Call Rejected. |
|
410 Gone |
No |
Treated as Call Rejected. |
|
411 Length Required |
No |
Treated as Call Rejected. |
|
413 Request Entity Too Large |
No |
Treated as Call Rejected. |
|
414 Request – URI Too Long |
No |
Treated as Call Rejected. |
|
415 Unsupported Media |
Yes |
Generate and accept responses. For outbound calls, these responses are treated as Call Rejected. |
|
420 Bad Extension |
Yes |
Generate and accept responses. For outbound calls, these responses are treated as Call Rejected. |
|
422 Session Timer Duration Too Small |
Yes |
Retry the INVITE method with new session interval. |
|
480 Temporarily Not Available |
Yes |
Generate and accept responses. For outbound calls, these responses are treated as Call Rejected. |
|
481 Call Leg Transaction Does Not Exist |
Yes |
Generate and accept responses. For outbound calls, these responses are treated as Call Rejected. |
|
482 Loop Detected |
No |
Treated as Call Rejected. |
|
483 Too Many Hops |
No |
Treated as Call Rejected. |
|
484 Address Incomplete |
No |
Treated as Call Rejected. |
|
485 Ambiguous |
No |
Treated as Call Rejected. |
|
486 Busy Here |
No |
Treated as Call Rejected. For outbound calls, these responses are treated as Call Rejected. |
|
500 Server Internal Error |
Yes |
Treated as Call Rejected. For outbound calls, these responses are treated as Call Rejected. |
|
501 Not Implemented |
No |
Treated as Call Rejected. |
|
502 Bad Gateway |
No |
Treated as Call Rejected. |
|
503 Service Unavailable |
Yes |
Generate and Accept Responses. |
|
504 Gateway Timeout |
No |
Treated as Call Rejected. |
|
505 SIP Version Not Supported |
Yes |
Generate and Accept Responses. |
|
513 Message Too Large |
Yes |
Treated as Call Rejected. |
|
600 Busy Everywhere |
No |
Treated as Call Rejected. |
|
603 Decline |
No |
Treated as Call Rejected. |
|
604 Does Not Exist Anywhere |
No |
Treated as Call Rejected. |
|
606 Not Acceptable |
No |
Treated as Call Rejected. |
Each SIP message is accompanied by a header. The following are the required fields in all messages (see Methods.)
Table B-3 Required Fields
|
Required Field |
Description |
|
From |
The address of the session originator; expressed as a SIP URL. |
|
To |
The address of the session target; expressed as a SIP URL. |
|
Call-ID |
A unique identifier assigned to all of the SIP messages related to a call. |
|
Cseq |
The SIP call control method and an identifying sequence number |
Table B-4 Supported Headers
|
Header |
Supported |
Compressed Header |
|---|---|---|
|
Accept |
No |
|
|
Accept-Encoding |
Yes |
Not applicable |
|
Accept-Language |
No |
|
|
Allow |
Yes |
|
|
Authorization |
Yes |
|
|
Call-ID |
Yes |
i |
|
Contact |
Yes |
m |
|
Content-Disposition |
Yes |
Not applicable |
|
Content - Encoding |
No |
|
|
Content-Length |
Yes |
l |
|
Content-Type |
Yes |
c |
|
Cseq |
Yes |
Not applicable |
|
Date |
No |
|
|
Encryption |
No |
|
|
Expires |
Yes |
Not applicable |
|
From |
Yes |
f |
|
Hide |
No |
|
|
In-Reply-To |
No |
|
|
Max - Forwards |
No |
|
|
MIME - Version |
No |
|
|
Min-SE |
Yes |
|
|
Organization |
No |
|
|
Priority |
No |
|
|
Proxy - Authenticate |
Yes |
|
|
Proxy - Authorization |
Yes |
|
|
Proxy - Require |
No |
|
|
Record-Route |
Yes |
Not applicable |
|
Require |
Yes |
|
|
Retry-After |
Yes |
Not applicable |
|
Response-Key |
No |
|
|
Route |
Yes |
Not applicable |
|
Server |
No |
|
|
Session-Expires |
Yes |
|
|
Subject |
No |
|
|
Supported |
Yes |
|
|
Timestamp |
No |
|
|
To |
Yes |
t |
|
Unsupported |
No |
|
|
User-Agent |
Yes |
Not applicable |
|
Via |
Yes |
v |
|
Warning |
No |
|
|
WWW-Authenticate |
Yes |
|
Important! You must set the System Timer accurately on the Matrix Controller card.
Instead of being assigned to specific devices the way that telephone numbers traditionally are assigned, SIP URLs are assigned to the individual users who participates in SIP sessions. As a result, when a phone call (or other interactive session) is made to a SIP address, it can be routed to the appropriate individual regardless of a change in physical location or IP telephone device.
The From and To fields in every message header contain the SIP URLs of the session's originator and target.
SIP URLs use the same format as IP addresses or e-mail addresses:
<sip:user-id@server-address:port;parameters;?header-names=values>.
The formats of some sample SIP URLs might appear as:
sip:123@OPENet.com
sip:3333@10.1.1.123
sip:johndoe@sip.OPENet.net:5070
John Doe<sip:johndoe@sip.OPENet.net:5070>
SIP Interoperability Compliance with the CSP
The following is required for SIP Interoperability compliance with the CSP:
• SIP User Agent supports RFC 2543 Bis-05 and RFC 2327.
• SDP provided in Invite for Media negotiation.
• RTP with G.711 must be supported.
Normally, a SIP INVITE message specifies the CODECS to be used in the media description part of the SDP. The CODECS that appear first in the list are those with a higher priority for usage. However, the CSP requires the use of a route table that specifies a CODEC (any CODEC supported by CSP).
If the CODEC listed in the route table appears anywhere in the media description of the SDP (regardless of priority) then that CODEC is used first.
Example: The Pulse Code Modulation U Law (PCMU) is specified in the route table. The SDP specifies Pulse Code Modulation A Law (PCMA) first in the media description and PCMU second. Normally PCMA is used if the other end supports it, but because the way the CSP handles the call, PCMU is used because it appears in the media description list. If PCMU did not appear in the media description, then PCMA would be used.