Downloads |
 Feedback
|
Table Of Contents
Prerequisites for SIP RFC Compliance
Restrictions for SIP RFC Compliance
Information About SIP RFC Compliance
SIP Header Fields, Network Components, and Methods
SIP SDP Usage, Transport Layer Protocols, and DNS Records
Flexibility of Content-Type Header
Allow Header Addition to INVITEs and 2xx Responses
Simultaneous Cancel and 2xx Class Response
Via Header Parameters and Merged Request Detection
Loose-Routing and the Record-Route Header
Multiple INVITE Requests Before a Final Response
Mid-call Re-INVITE Request Failure
PRACK Request with a New Offer
Reliable Provisional Response Failure
SIP RFC 3261, RFC 3262, and RFC 3264 Compliance
SIP TCP and UDP Connection Enhancements
Dynamic Transport Switching (UDP to TCP) for Large SIP Requests
Expanded Range of the max-forwards Command
How to Configure SIP RFC Compliance
Configuring Compliance to RFC 2543
Configuring Compliance to RFC 2782
Configuring Compliance to RFC 3261
Configuring Compliance to RFC 3261, RFC 3262, and RFC 3264
Configure TCP and UDP Connection Enhancements
Configure Dynamic Transport Switching (UDP to TCP) for Large SIP Requests
Configuration Examples for SIP RFC Compliance
SIP Gateway Compliance to RFC 3261, RFC 3262, and RFC 3264: Example
Achieving SIP RFC Compliance
First Published: February 25, 2002Last Updated: May 17, 2010This chapter describes how to use or configure Cisco IOS Session Initiation Protocol (SIP) gateways to comply with published SIP standards. It discusses the following features:
•
RFC 4040-Based Clear Channel Codec Negotiation for SIP Calls
•
•
•
•
•
Note
Feature History for RFC4040-Based Clear Channel Codec Negotiation for SIP Calls
15.0(1)XA
This feature is supported on Cisco IOS SIP time division multiplexing (TDM) gateways and Cisco Unified Border Elements (Cisco UBEs). For details about enabling this feature, see the encap clear-channel standard and voice-class sip encap clear-channel commands in the Cisco IOS Voice Command Reference at http://www.cisco.com/en/US/docs/ios/voice/command/reference/vr_book.html.
Feature History for SIP: Core SIP Technology Enhancements
12.2(13)T
This feature was introduced to achieve compliance with SIP RFC 2543-bis-04, later published as RFC_3261.
Feature History for SIP - DNS SRV RFC 2782 Compliance
12.2(2)XB
This feature was introduced.
12.2(8)T
This feature was integrated into the release.
Feature History for SIP: RFC 3261 Enhancements
Feature History for SIP Gateway Compliance to RFC 3261, RFC 3262, and RFC 3264
Finding Feature Information
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
•
•
•
•
Prerequisites for SIP RFC Compliance
•
•
Note
Restrictions for SIP RFC Compliance
•
–
–
–
–
•
Information About SIP RFC Compliance
This section contains the following information:
•
SIP RFC 2543 Compliance
The Cisco SIP gateway complies with RFC 2543. However, RFC 3261 has now replaced (obsoleted) RFC 2543. See "Restrictions for SIP RFC Compliance" section and "SIP RFC 3261 Compliance" section for more information about what is and is not supported in the new RFCs.
SIP RFC 2782 Compliance
SIP on Cisco VoIP gateways uses Domain Name System Server (DNS SRV) query to determine the IP address of the user endpoint. The query string has a prefix in the form of "protocol.transport."as defined by RFC 2052. This prefix is attached to the fully qualified domain name (FQDN) of the next-hop SIP server.
A second prefix style has been added to Cisco VoIP gateways and is now the default. This second style is defined by RFC 2782, which obsoleted RFC 2052 in February 2000. This new style is in compliance with RFC 2782 and appends the protocol label with an underscore "_" as in "_protocol._transport." The addition of the underscore reduces the risk of the same name being used for unrelated purposes.
SIP RFC 3261 Compliance
RFC 3261, which obsoletes RFC 2543, defines the SIP signaling protocol for creating, modifying, and terminating sessions. Cisco's implementation of RFC 3261 supports the following:
•
•
•
•
•
Benefits of RFC 3261 include the following:
•
•
This section contains the following information about basic SIP functionality:
•
•
•
•
•
SIP Header Fields, Network Components, and Methods
Table 2 through Table 4 show RFC 3261 SIP functions—including headers, components, and methods. They also show if the specific functionality is supported by Cisco SIP gateways.
Table 3 SIP Network Components
User Agent Client (UAC)
Yes
User Agent Server (UAS)
Proxy Server
No
Redirect Server
Yes
Registrar Server
SIP Responses
Table 5 through Table 10 show SIP responses that are supported by Cisco SIP gateways in compliance with RFC 3261.
Cisco SIP gateways do not initiate the use of keepalive messages for calls that they originate or terminate. If the remote gateway uses a keepalive message, the SIP gateway complies.
SIP SDP Usage, Transport Layer Protocols, and DNS Records
Table 11 through Table 13 show SIP SDP usage, transport protocols, and DNS records that are supported in RFC 3261. They also show if the specific functionality is supported by Cisco SIP gateways.
Table 12 SIP Transport Layer Protocols
Multicast UDP
No
TCP
Yes
TLS
No
Unicast UDP
Yes
Table 13 SIP Domain Name System (DNS) Records
RFC 3263 Type A
Yes
RFC 3263 Type NAPTR
No
RFC 3263 Type SRV
Yes
SIP Extensions
Table 14 shows supported SIP extensions.
SIP Security
Table 15 and Table 16 show SIP security encryption and responses supported in RFC 3261. They also show if the specific functionality is supported by Cisco SIP gateways.
SIP DTMF Relay
Cisco SIP gateways support DTMF relay in accordance with RFC 2833. The DTMF relay method is based on the transmission of Named Telephony Events (NTE) and DTMF digits over a Real-Time Transport Protocol (RTP) stream.
Cisco SIP gateways also support forwarding DTMF tones by means of cisco-rtp, which is a Cisco proprietary payload type.
Table 17 shows SIP DTMF relay methods. It also shows if the specific method is supported by Cisco SIP gateways.
SIP Fax Relay and T.38
Table 18 shows fax relay modes that are supported by Cisco SIP gateways in compliance with RFC 3261. It also shows if the specific method is supported by Cisco SIP gateways.
Table 18 Fax Relay Modes Supported in RFC 3261
T.38 Fax Relay
Yes
Cisco Fax Relay
Yes, except on Cisco AS5350 and Cisco AS5400
Cisco SIP gateways support T.38 and T.37 fax relay, store, and forward mechanisms. Table 19 is based on Annex-D of the T.38 ITU recommendation, Procedures for Real-Time Group 3 Facsimile Communication over IP Networks, June 1998. The table indicates recommendations from the standard and if Cisco SIP gateways support the requirements.
SIP URL Comparison
When Uniform Resource Locators (URLs) are received, they are compared for equality. URL comparison can be done between two From SIP URLs or between two To SIP URLs. The order of the parameters does not need to match precisely. However, for two URLs to be equal, the user, password, host, and port parameters must match.
In Cisco IOS Release 12.3 and later releases, the maddr and transport parameters were removed and no longer used in Cisco SIP gateway implementations. However, in Cisco IOS Release 15.1(1)T and later releases, the maddr parameter is reintroduced so that the sender of a SIP request can specify a different destination for responses to those requests by specifying the maddr value for the URL in the Via header.
If a compared parameter is omitted or not present, it is matched on the basis of its default value. Table 20 shows a list of SIP URL compared parameters and their default values.
.
Table 20 SIP URL Compared Parameters and Default Values
User
—
Password
—
Host
Mandatory
Port
5060
User-param
IP
Assuming that a comparison is taking place, the following is an example of equivalent URLs:
Original URL:
sip:36602@172.18.193.120Equivalent URLs:
sip:36602@172.18.193.120:sip:36602@172.18.193.120;tag=499270-A62;pname=pvaluesip:36602@172.18.193.120;user=ipsip:36602@172.18.193.120:5060487 Sent for BYE Requests
RFC 3261 requires that a UAS that receives a BYE request first send a response to any pending requests for that call before disconnecting. After receiving a BYE request, the UAS should respond with a 487 (Request Cancelled) status message.
3xx Redirection Responses
See the "Configuring SIP Redirect Processing Enhancement" section in the "Basic SIP Configuration" module in this guide.
DNS SRV Query Procedure
In accordance with RFC 3261, when a Request URI or the session target in the dial peer contains a fully qualified domain name (FQDN), the UAC needs to determine the protocol, port, and IP address of the endpoint before it forwards the request. SIP on Cisco gateways uses Domain Name System Server (DNS SRV) query to determine the protocol, port, and IP address of the user endpoint.
Before Cisco IOS Release 12.2(13)T, the DNS query procedure did not take into account the destination port.
Note
Where,
A = Number of entries in the DNS SRV record
B = Number of INVITE request retries configured using the retry invite command
C = Waiting time for the SIP user agent configured using the timers trying command
CANCEL Request Route Header
A CANCEL message sent by a UAC on an initial INVITE request cannot have a Route header. Route headers cannot appear in a CANCEL message because they take the same path as INVITE requests, and INVITE requests cannot contain Route headers.
Interpret User Parameters
There are instances when the telephone-subscriber or user parameters can contain escaped characters to incorporate space, control characters, quotation marks, hash marks, and other characters. After the receipt of an INVITE message, the telephone-subscriber or user parameter is interpreted before dial-peer matching is done. For example, the escaped telephone number in an incoming INVITE message may appear as:
-%32%32%32Although 222 is a valid telephone number, it requires interpretation. If the interpretation is not done, the call attempt fails when the user parameter is matched with the dial-peer destination pattern.
user=phone Parameter
A SIP URL identifies a user's address, which appears similar to an e-mail address. The form of the user's address is user@host where "user" is the user identification and "host" is either a domain name or a numeric network address. For example, the request line of an outgoing INVITE request might appear as:
INVITE sip:5550100@example.comThe user=phone parameter formerly required in a SIP URL is no longer necessary. However, if an incoming SIP message has a SIP URL with user=phone, user=phone is parsed and used in the subsequent messages of the transaction.
303 and 411 SIP Cause Codes
RFC 3261 obsoletes the SIP cause codes 303 Redirection: See Other and 411 Client Error: Length required.
Flexibility of Content-Type Header
The Content-Type header, which specifies the media type of the message body, is permitted to have an empty Session Description Protocol (SDP) body.
Optional SDP "s=" Line
The "s=" line in SDP is accepted as optional. The "s=" line describes the reason or subject for SDP information. Cisco SIP gateways can create messages with an "s=" line in SDP bodies and can accept messages that have no "s=" line.
Allow Header Addition to INVITEs and 2xx Responses
The use of the Allow header in an initial or re-INVITE request or in any 2xx class response to an INVITE is permitted. The Allow header lists the set of methods supported by the user agent that is generating the message. Because it advertises what methods should be invoked on the user agent sending the message, it avoids congesting the message traffic unnecessarily. The Allow header can contain any or all of the following: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, NOTIFY, INFO, SUBSCRIBE.
Simultaneous Cancel and 2xx Class Response
According to RFC 3261, if the UAC desires to end the call before a response is received to an INVITE, the UAC sends a CANCEL. However, if the CANCEL and a 2xx class response to the INVITE "pass on the wire," the UAC also receives a 2xx to the INVITE. When the two messages pass, the UAC terminates the call by sending a BYE request.
UPDATE-Request Processing
RFC 3261, which obsoletes RFC 2543, defines the SIP signaling protocol for creating, modifying and terminating sessions. The SIP Extensions for Caller Identity and Privacy feature provides support for the following SIP gateway implementations that are compliant with the RFC 3261specification:
•
•
•
•
•
•
SIP UPDATE Requests
SIP accomplishes session management through a series of messages that are either requests from a server or client, or responses to a request. SIP uses an INVITE request to initiate and modify sessions between user agents (UAs), and uses the ACK method to acknowledge a final response to an INVITE request. In some cases a session needs to be modified before the INVITE request is answered. This scenario occurs, for example, in a call that sends early media, the information sent to convey call progress during an established session, and for which the INVITE request has not been accepted. In this scenario either the caller or callee should be able to modify the characteristics of a session, for instance, by putting the early media on hold before the call is answered. Prior to the SIP UPDATE method, which allows a client to update session parameters, there was no mechanism to allow a caller or callee to provide updated session information before a final response to the initial INVITE request was generated. The SIP Extensions for Caller Identity and Privacy feature provides support for the UPDATE method and enables the gateway capability to receive and process, but not send, UPDATE requests. The gateway also updates the session timer value after the call is active.
A user agent client (UAC) initiates a session by sending an INVITE request to a user agent server (UAS). The UAS responds to the invitation by sending the following response codes:
•
•
•
A PRACK response is used to acknowledge receipt of a reliably transported provisional response, including a response with early media indication, while the ACK is used to acknowledge a final response to an INVITE request. A PRACK establishes an early dialog between UAC and UAS, a requirement to receive UPDATE requests with a new offer.
When a 2xx response is sent it establishes a session and also creates a dialog, or call leg. A dialog established by a 1xx response is considered an early dialog, whereas a final response establishes a confirmed dialog. The SIP UPDATE method allows a UAC to update session parameters, such as the set of media streams and their codecs, without affecting the dialog state. Unlike a re-INVITE request, a SIP UPDATE request may be sent to modify a session before the initial INVITE request is answered without impacting the dialog state itself. The UPDATE method is useful for updating session parameters within early dialogs before the initial INVITE request has been answered, for example, when early media is sent.
The SIP UPDATE method makes use of the offer and answer exchange using Session Description Protocol (SDP), as defined in the IETF specification, RFC 3264, An Offer/Answer Model with the Session Description Protocol (SDP). One UA in the session generates an SDP message that constitutes the offer, that is, the set of media streams and codecs the UA wants to use, along with IP addresses and ports where the UA wants to receive the media. The other UA generates an answer, an SDP message responding to the offer.
In the Cisco SIP implementation, a UAS can receive an UPDATE request in both early and confirmed dialogs. The point at which the offer is generated, the UPDATE is received, the presence or absence of reliable provisional response and SDP, are all factors that determine how the gateway handles the UPDATE request. An UPDATE request generates a response indicating one of several possible outcomes:
•
•
•
The following sections discuss how UPDATE requests are received and processed in various scenarios and call flows.
UPDATE Request Processing Before the Call Is Active
When the gateway sends a reliable provisional response with SDP, the response includes an Allow header that lists the UPDATE method and informs the caller of the gateway capability to support UPDATE processing.
Figure 13 shows a call where the UAS sent a reliable provisional response (ANSWER 1) to an INVITE request (Offer 1). The18x early media response indicated the gateway capability to support UPDATEs. The UAC sent a provisional acknowledgement (PRACK) and received a 200 OK response to the PRACK request. The UAC requested the UAS modify the existing session media parameters of the early dialog by sending an UPDATE request (Offer 2). The UAS accepted Offer 2 by sending a 200 OK response. If media negotiation had failed, the UAS would have sent a 488 Unacceptable Media response instead. Later the UAS sent a 200 OK final response to the initial INVITE request. The UAS sent an ACK request acknowledging the final response to the INVITE request.
Figure 13 UPDATE for Early Media
In Figure 14 the gateway received an UPDATE (Offer 2) before responding to the INVITE request (Offer 1), causing the gateway to reject the request by sending a 500 Internal Server Error with a Retry-After header field set to a randomly chosen value between zero and ten seconds.
Figure 14 Initial UPDATE Rejected
In Figure 15 the initial INVITE request did not contain an offer, and the UAS gateway sent SDP with reliable provisional response (Offer 1) which was treated by the UAC as an offer.
Figure 15 UPDATE Request for Delayed Media
In Figure 16 the UAS received an UPDATE request with an offer (Offer 2) before receiving a PRACK, that is, before the early dialog is established, causing the UAS (gateway) to generate a 491 Request Pending response.
Figure 16 UPDATE Request Failure for Delayed Media
Error Responses to UPDATE Request Processing Before the Call Is Active
In other scenarios, additional rules apply to processing an UPDATE request with an offer when the gateway has sent a 200 OK response to an INVITE request but has not yet received an ACK. The following scenarios generate an error response and are shown in Figure 17:
•
•
Figure 17 Error Cases for UPDATE Requests
UPDATE Request Processing in the Active State
RFC 3261 recommends using a re-INVITE request, the SIP message that changes session parameters of an existing or pending call, to update session parameters after a call is active. UPDATEs received after a call is active are processed like a re-INVITE except that the 200 OK to update is not resent (see Figure 18).
Figure 18 UPDATE Request in the Active State
Figure 19 shows a UAC that sent a mid-call INVITE request which has not yet been answered. In this state, when the gateway receives an UPDATE request with a new offer, it sends a 491 Request Pending error.
Figure 19 Error Response to an UPDATE Request in the Active State
Via Header Parameters and Merged Request Detection
To meet specifications of RFC 3261, the SIP Extensions for Caller Identity and Privacy feature provides support for the branch parameter in the Via header of a request, the information used to identify the transaction created by that request. The branch parameter value begins with the value "z9hG4bK" indicating that the request was generated by a UAC that is RFC 3261 compliant. The SIP Extensions for Caller Identity and Privacy feature also adds support for generating the received parameter with the received address.
The SIP Extensions for Caller Identity and Privacy feature uses the branch and sent-by parameters to detect a merged request, that is, a request that has arrived at the UAS more than once by following different paths. If the request has no tag in the To header field, the UAS checks the request against ongoing transactions. If the From tag, Call-ID, and CSeq headers exactly match those headers associated with an ongoing transaction, but the topmost Via header, including the branch parameter, does not match, the UAS treats the request as merged. The UAS responds to a merged request with a 482 Loop Detected error.
Loose-Routing and the Record-Route Header
The SIP Extensions for Caller Identity and Privacy feature supports loose-routing, a mechanism that helps keep the request target and next route destination separate. The lr parameter, used in the uniform resource indicator (URI) that a proxy places in the Record-Route header, indicates proxy compatibility with RFC 3261. If the lr parameter is missing from a request, the UA assumes the next-hop proxy implements strict-routing in compliance with RFC 2543, and reformats the message to preserve information in the Request-URI.
Multiple INVITE Requests Before a Final Response
This feature implements support for processing multiple INVITE requests received by the UAS before it sends a final response to the initial INVITE request (see Figure 20). If the UAS gateway receives a second INVITE request before it sends the final response to the first INVITE request with a lower CSeq sequence number on the same dialog, the UAS returns a 500 Server Internal Error response to the second INVITE request. The error response also includes a Retry-After header field with a random value between 0 and 10 seconds.
Figure 20 Re-INVITE Request Rejected With a 5xx Response
Mid-call Re-INVITE Request Failure
TheSIP Extensions for Caller Identity and Privacy feature implements the mid-call re-INVITE request failure treatment shown in Figure 21. The UAC terminates a dialog when a non-2xx final response to a mid-call INVITE request is one of the following:
•
•
Figure 21 Dialog Termination After a 481 or 408 Response to Re-INVITE Request
PRACK Request with a New Offer
The SIP Extensions for Caller Identity and Privacy feature supports a PRACK request with a new offer (see Figure 22). If the UAC receives a reliable provisional response with an answer (Answer 1), it may generate an additional offer in the PRACK (Offer 2). If the UAS receives a PRACK with an updated offer, it generates a 200 OK with an answer (Answer 2) if negotiation is successful. Otherwise the UAS generates a 488 Unacceptable Media response.
Figure 22 Offer in PRACK Accepted
Reliable Provisional Response Failure
The SIP Extensions for Caller Identity and Privacy feature provides the treatment shown in Figure 23 when the UAS does not receive a corresponding PRACK after resending a 18x reliable provisional response for the maximum number of retries allowed or for 32 seconds. The UAS generates a 5xx response to clear the call.
Figure 23 Reliable Provisional Response Failure
Sample Messages
This section contains sample SIP messages collected at the terminating SIP gateway.
SIP UPDATE Request Call Flow Example
The following example shows an exchange of SIP requests and responses, including an UPDATE request before the call is active:
1w0d:SIP Msg:ccsipDisplayMsg:Received:INVITE sip:222@192.0.2.12:5060 SIP/2.0Record-Route:<sip:222@192.0.2.4:5060;maddr=192.0.2.4>Via:SIP/2.0/UDP 192.0.2.4:5060;branch=5,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK1D38From:<sip:111@192.0.2.14>;tag=3DD33DE4-10DFTo:<sip:222@192.0.2.4>Date:Mon, 08 Apr 2002 16:58:08 GMTCall-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14Supported:timerThe next line shows the UAC requires the provisional response be reliably transported.
Require:100relMin-SE: 1800Cisco-Guid:2729535908-1246237142-2148443152-4064420637User-Agent:Cisco-SIPGateway/IOS-12.xThe Allow header shows that the UPDATE method is supported.
Allow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTERCSeq:101 INVITEMax-Forwards:70Remote-Party-ID:<sip:111@192.0.2.14>;party=calling;screen=no;privacy=offTimestamp:1018285088Contact:<sip:111@192.0.2.14:5060>Expires:180Allow-Events:telephone-eventContent-Type:application/sdpContent-Length:262The following SDP constitutes the initial offer, including media streams and codecs, along with IP addresses and ports to receive media.
v=0o=CiscoSystemsSIP-GW-UserAgent 6579 1987 IN IP4 192.0.2.14s=SIP Callc=IN IP4 192.0.2.14t=0 0m=audio 17782 RTP/AVP 8 0 18 19c=IN IP4 192.0.2.14a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=rtpmap:18 G729/8000a=fmtp:18 annexb=noa=rtpmap:19 CN/80001w0d:SIP Msg:ccsipDisplayMsg:Sent:SIP/2.0 100 TryingVia:SIP/2.0/UDP 192.0.2.4:5060;branch=5,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK1D38From:<sip:111@192.0.2.14>;tag=3DD33DE4-10DFTo:<sip:222@192.0.2.4>;tag=24D435A8-C29Date:Sat, 07 Oct 2000 02:56:34 GMTCall-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14Timestamp:1018285088Server:Cisco-SIPGateway/IOS-12.xCSeq:101 INVITEAllow-Events:telephone-eventContent-Length:0In the following lines, the gateway responds by sending early media in answer to the initial offer.
1w0d:SIP Msg:ccsipDisplayMsg:Sent:SIP/2.0 183 Session ProgressVia:SIP/2.0/UDP 192.0.2.4:5060;branch=5,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK1D38From:<sip:111@192.0.2.14>;tag=3DD33DE4-10DFTo:<sip:222@192.0.2.4>;tag=24D435A8-C29Date:Sat, 07 Oct 2000 02:56:34 GMTCall-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14Timestamp:1018285088Server:Cisco-SIPGateway/IOS-12.xCSeq:101 INVITERequire:100relRSeq:5785Allow:UPDATEAllow-Events:telephone-eventContact:<sip:222@192.0.2.12:5060>Record-Route:<sip:222@192.0.2.4:5060;maddr=192.0.2.4>Content-Disposition:session;handling=requiredContent-Type:application/sdpContent-Length:191v=0o=CiscoSystemsSIP-GW-UserAgent 5565 7580 IN IP4 192.0.2.12s=SIP Callc=IN IP4 192.0.2.12t=0 0m=audio 18020 RTP/AVP 8 19c=IN IP4 192.0.2.12a=rtpmap:8 PCMA/8000a=rtpmap:19 CN/8000The following lines show the UAS receiving a PRACK for the 183 response.
1w0d:SIP Msg:ccsipDisplayMsg:Received:PRACK sip:222@192.0.2.12:5060 SIP/2.0Via:SIP/2.0/UDP 192.0.2.4:5060;branch=6,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK40AFrom:<sip:111@192.0.2.14>;tag=3DD33DE4-10DFTo:<sip:222@192.0.2.4>;tag=24D435A8-C29Date:Mon, 08 Apr 2002 16:58:08 GMTCall-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14CSeq:102 PRACKRAck:5785 101 INVITEContent-Length:01w0d:SIP Msg:ccsipDisplayMsg:Sent:SIP/2.0 200 OKVia:SIP/2.0/UDP 192.0.2.4:5060;branch=6,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK40AFrom:<sip:111@192.0.2.14>;tag=3DD33DE4-10DFTo:<sip:222@192.0.2.4>;tag=24D435A8-C29Date:Sat, 07 Oct 2000 02:56:34 GMTCall-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14Server:Cisco-SIPGateway/IOS-12.xCSeq:102 PRACKContent-Length:0The next lines show the UAS receiving an updated offer with different media streams and codecs.
1w0d:SIP Msg:ccsipDisplayMsg:Received:UPDATE sip:222@192.0.2.12:5060 SIP/2.0Via:SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bK10Via:SIP/2.0/UDP 192.0.2.14:5060To:<sip:222@192.0.2.4>;tag=24D435A8-C29From:<sip:111@192.0.2.14>;tag=3DD33DE4-10DFCall-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14CSeq:103 UPDATEContact:sip:111@192.0.2.14:5060Content-Length:262v=0o=CiscoSystemsSIP-GW-UserAgent 6579 1987 IN IP4 192.0.2.14s=SIP Callc=IN IP4 192.0.2.14t=0 0m=audio 17782 RTP/AVP 8 0 18 19c=IN IP4 192.0.2.14a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=rtpmap:18 G729/8000a=fmtp:18 annexb=noa=rtpmap:19 CN/8000The new offer in the UPDATE request is acceptable to the server, so it responds with the corresponding answer in the 200 OK message.
1w0d:SIP Msg:ccsipDisplayMsg:Sent:SIP/2.0 200 OKVia:SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bK10,SIP/2.0/UDP 192.0.2.14:5060From:<sip:111@192.0.2.14>;tag=3DD33DE4-10DFTo:<sip:222@192.0.2.4>;tag=24D435A8-C29Date:Sat, 07 Oct 2000 02:56:34 GMTCall-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14Server:Cisco-SIPGateway/IOS-12.xCSeq:103 UPDATEContent-Type:application/sdpContent-Length:191v=0o=CiscoSystemsSIP-GW-UserAgent 5565 7580 IN IP4 192.0.2.12s=SIP Callc=IN IP4 192.0.2.12t=0 0m=audio 18020 RTP/AVP 8 19c=IN IP4 192.0.2.12a=rtpmap:8 PCMA/8000a=rtpmap:19 CN/80001w0d:SIP Msg:ccsipDisplayMsg:Sent:SIP/2.0 200 OKVia:SIP/2.0/UDP 192.0.2.4:5060;branch=5,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK1D38From:<sip:111@192.0.2.14>;tag=3DD33DE4-10DFTo:<sip:222@192.0.2.4>;tag=24D435A8-C29Date:Sat, 07 Oct 2000 02:56:34 GMTCall-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14Timestamp:1018285088Server:Cisco-SIPGateway/IOS-12.xCSeq:101 INVITEAllow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTERAllow-Events:telephone-eventContact:<sip:222@192.0.2.12:5060>Record-Route:<sip:222@192.0.2.4:5060;maddr=192.0.2.4>Content-Type:application/sdpContent-Length:191v=0o=CiscoSystemsSIP-GW-UserAgent 5565 7580 IN IP4 192.0.2.12s=SIP Callc=IN IP4 192.0.2.12t=0 0m=audio 18020 RTP/AVP 8 19c=IN IP4 192.0.2.12a=rtpmap:8 PCMA/8000a=rtpmap:19 CN/80001w0d:SIP Msg:ccsipDisplayMsg:Received:ACK sip:222@192.0.2.12:5060 SIP/2.0Via:SIP/2.0/UDP 192.0.2.4:5060;branch=7,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK230From:<sip:111@192.0.2.14>;tag=3DD33DE4-10DFTo:<sip:222@192.0.2.4>;tag=24D435A8-C29Date:Mon, 08 Apr 2002 16:58:08 GMTCall-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14Max-Forwards:70CSeq:101 ACKContent-Length:01w0d:SIP Msg:ccsipDisplayMsg:Sent:BYE sip:222@192.0.2.4:50605060;maddr=192.0.2.4 SIP/2.0Via:SIP/2.0/UDP 192.0.2.12:5060;branch=z9hG4bKCAFrom:<sip:222@192.0.2.4>;tag=24D435A8-C29To:<sip:111@192.0.2.14>;tag=3DD33DE4-10DFDate:Sat, 07 Oct 2000 02:56:35 GMTCall-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14User-Agent:Cisco-SIPGateway/IOS-12.xMax-Forwards:70Route:<sip:111@192.0.2.14:5060>Timestamp:970887414CSeq:101 BYEContent-Length:01w0d:SIP Msg:ccsipDisplayMsg:Received:SIP/2.0 200 OKVia:SIP/2.0/UDP 192.0.2.12:5060;branch=z9hG4bKCAFrom:<sip:222@192.0.2.4>;tag=24D435A8-C29To:<sip:111@192.0.2.14>;tag=3DD33DE4-10DFDate:Mon, 08 Apr 2002 16:58:29 GMTCall-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14Server:Cisco-SIPGateway/IOS-12.xTimestamp:970887414Content-Length:0CSeq:101 BYELoose-Routing Call Flow Example
The following sample message shows a loose-routing request:
1w0d:SIP Msg:ccsipDisplayMsg:Received:INVITE sip:222@192.0.2.12:5060 SIP/2.0The SIP messages in the following call flow have the Request-URI set to the SIP URI of the destination UA instead of the SIP URI of the next-hop destination, that is, the SIP proxy server.
Record-Route:<sip:222@192.0.2.4:5060;lr;maddr=192.0.2.4>Via:SIP/2.0/UDP 192.0.2.4:5060;branch=9,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK2394From:<sip:111@192.0.2.14>;tag=3DD3A404-12A3To:<sip:222@192.0.2.4>Date:Mon, 08 Apr 2002 16:58:34 GMTCall-ID:B2474766-4A4811D6-8015A410-F242231D@192.0.2.14Supported:timerMin-SE: 1800Cisco-Guid:2991015782-1246237142-2148770832-4064420637User-Agent:Cisco-SIPGateway/IOS-12.xAllow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTERCSeq:101 INVITEMax-Forwards:70Remote-Party-ID:<sip:111@192.0.2.14>;party=calling;screen=no;privacy=offTimestamp:1018285114Contact:<sip:111@192.0.2.14:5060>Expires:180Allow-Events:telephone-eventContent-Type:application/sdpContent-Length:262v=0o=CiscoSystemsSIP-GW-UserAgent 1981 1761 IN IP4 192.0.2.14s=SIP Callc=IN IP4 192.0.2.14t=0 0m=audio 18354 RTP/AVP 8 0 18 19c=IN IP4 192.0.2.14a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=rtpmap:18 G729/8000a=fmtp:18 annexb=noa=rtpmap:19 CN/80001w0d:SIP Msg:ccsipDisplayMsg:Sent:SIP/2.0 100 TryingVia:SIP/2.0/UDP 192.0.2.4:5060;branch=9,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK2394From:<sip:111@192.0.2.14>;tag=3DD3A404-12A3To:<sip:222@192.0.2.4>;tag=24D49BE8-2346Date:Sat, 07 Oct 2000 02:57:00 GMTCall-ID:B2474766-4A4811D6-8015A410-F242231D@192.0.2.14Timestamp:1018285114Server:Cisco-SIPGateway/IOS-12.xCSeq:101 INVITEAllow-Events:telephone-eventContent-Length:01w0d:SIP Msg:ccsipDisplayMsg:Sent:SIP/2.0 180 RingingVia:SIP/2.0/UDP 192.0.2.4:5060;branch=9,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK2394From:<sip:111@192.0.2.14>;tag=3DD3A404-12A3To:<sip:222@192.0.2.4>;tag=24D49BE8-2346Date:Sat, 07 Oct 2000 02:57:00 GMTCall-ID:B2474766-4A4811D6-8015A410-F242231D@192.0.2.14Timestamp:1018285114Server:Cisco-SIPGateway/IOS-12.xCSeq:101 INVITEAllow:UPDATEAllow-Events:telephone-eventContact:<sip:222@192.0.2.12:5060>Record-Route:<sip:222@192.0.2.4:5060;lr;maddr=192.0.2.4>Content-Length:01w0d:SIP Msg:ccsipDisplayMsg:Sent:SIP/2.0 200 OKVia:SIP/2.0/UDP 192.0.2.4:5060;branch=9,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK2394From:<sip:111@192.0.2.14>;tag=3DD3A404-12A3To:<sip:222@192.0.2.4>;tag=24D49BE8-2346Date:Sat, 07 Oct 2000 02:57:00 GMTCall-ID:B2474766-4A4811D6-8015A410-F242231D@192.0.2.14Timestamp:1018285114Server:Cisco-SIPGateway/IOS-12.xCSeq:101 INVITEAllow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTERAllow-Events:telephone-eventContact:<sip:222@192.0.2.12:5060>Record-Route:<sip:222@192.0.2.4:5060;lr;maddr=192.0.2.4>Content-Type:application/sdpContent-Length:191v=0o=CiscoSystemsSIP-GW-UserAgent 5181 4737 IN IP4 192.0.2.12s=SIP Callc=IN IP4 192.0.2.12t=0 0m=audio 16720 RTP/AVP 8 19c=IN IP4 192.0.2.12a=rtpmap:8 PCMA/8000a=rtpmap:19 CN/80001w0d:SIP Msg:ccsipDisplayMsg:Received:ACK sip:222@192.0.2.12:5060 SIP/2.0Via:SIP/2.0/UDP 192.0.2.4:5060;branch=10,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK103DFrom:<sip:111@192.0.2.14>;tag=3DD3A404-12A3To:<sip:222@192.0.2.4>;tag=24D49BE8-2346Date:Mon, 08 Apr 2002 16:58:34 GMTCall-ID:B2474766-4A4811D6-8015A410-F242231D@192.0.2.14Max-Forwards:70CSeq:101 ACKContent-Length:01w0d:SIP Msg:ccsipDisplayMsg:Sent:BYE sip:111@192.0.2.14:5060 SIP/2.0Via:SIP/2.0/UDP 192.0.2.12:5060;branch=z9hG4bK18B6From:<sip:222@192.0.2.4>;tag=24D49BE8-2346To:<sip:111@192.0.2.14>;tag=3DD3A404-12A3Date:Sat, 07 Oct 2000 02:57:01 GMTCall-ID:B2474766-4A4811D6-8015A410-F242231D@192.0.2.14User-Agent:Cisco-SIPGateway/IOS-12.xMax-Forwards:70Route:<sip:222@192.0.2.4:5060;lr;maddr=192.0.2.4>Timestamp:970887440CSeq:101 BYEContent-Length:01w0d:SIP Msg:ccsipDisplayMsg:Received:SIP/2.0 200 OKVia:SIP/2.0/UDP 192.0.2.12:5060;branch=z9hG4bK18B6From:<sip:222@192.0.2.4>;tag=24D49BE8-2346To:<sip:111@192.0.2.14>;tag=3DD3A404-12A3Date:Mon, 08 Apr 2002 16:58:54 GMTCall-ID:B2474766-4A4811D6-8015A410-F242231D@192.0.2.14Server:Cisco-SIPGateway/IOS-12.xTimestamp:970887440Content-Length:0CSeq:101 BYESIP RFC 3261, RFC 3262, and RFC 3264 Compliance
The Internet Engineering Task Force (IETF) continually updates SIP standards. This feature describes the specific updates or optimizations that were made on Cisco SIP gateways to remain in compliance with the IETF. The following standards have been updated:
•
•
•
To provide quality service to our SIP customers, Cisco optimizes its SIP gateways to comply with the latest SIP-related RFCs. In addition, backward compatibility is maintained, providing customers interoperability with gateways that do not yet support the current RFCs.
This section contains the following information:
•
•
•
SIP Messaging Enhancements
The following changes or additions were made to SIP messaging:
•
•
•
•
If the UAC generated the request, the timer has a randomly chosen value between 2.1 and 4 seconds, in units of 10 ms. If the UAC did not generate the request, the timer has a randomly chosen value between 0 and 2 seconds, in units of 10 ms.
SIP TCP and UDP Connection Enhancements
Prior to RFC 3261, TCP support was optional for SIP user agents. RFC 3261 now requires support for both UDP and TCP. While Cisco SIP gateways already supported TCP, there have been several optimizations that are described below:
•
•
•
•
•
Failed Transmissions of 2xx Responses
The transmission of 2xx responses is in compliance with RFC 3261. If the transport is TCP and a gateway does not receive an acknowledgement to a 2xx response it sent to an INVITE message, the gateway retries the 2xx response over TCP. The retry ensures that a gateway receives a 200 OK message, eliminating the possibility that the 2xx response is lost when hops over the network use an unreliable transport such as UDP.
Reuse of TCP and UDP Connections
Prior to RFC 3261, a remote gateway could not initiate two requests over the same TCP connection. In addition, the gateway created a new connection for each new transaction, and after the completion of a transaction, the gateway closed the connection. Closing the connection, even if a subsequent request was destined for the same location as the previous transaction, resulted in potentially lower performance due to the large number of unnecessary open/close connections. With Cisco IOS Release 12.3(8)T, the gateway opens one TCP connection per remote IP address and port. The gateway opens a new connection only if a connection to the particular destination IP address and port is not already present. The gateway closes the connection when all requests that use that connection have terminated and no activity is detected for a given time period.
The timers connection command allows you to time out a TCP or UDP connection because of inactivity.
Transaction-Based Transport Switching and Usage
With Cisco IOS Release 12.3(8)T, if a new transaction request is larger than the threshold switchable value, it is sent over TCP. The threshold switchable value is a value that is 200 bytes or more than the interface or path's MTU. If the message size is smaller than the threshold switchable value, the original configured transport is used. The original transport means the transport configured under the dial peer for the initial Invite request or the transport specified in the incoming response's Contact or Record-Route headers in subsequent requests. In other words, the transport usage is now transaction-based instead of call-based.
Detection of Remote End Connection Closures
Remote gateway closures that go undetected can result in hung TCP connections. If a closed connection remains undetected, the corresponding connection entry is never removed from the connection table. Continuous occurrences of undetected closures can lead to the connection table being filled with invalid entries and valid SIP requests being rejected, requiring a router reboot. With Cisco IOS Release 12.3(8)T, the SIP gateway uses internal mechanisms to detect remote closures and to clean up the connection table. No user input is required to initiate the cleanup.
Creation of New Connections for Sending Responses in Case the Original Connection Dropped
With Cisco IOS Release 12.3(8)T, if a gateway tears down the connection of an incoming request before a response is sent, the receiving gateway creates a new connection to send out a response. The new connection is based on the port specified in the sent-by parameter of the Via header. Prior to Cisco IOS Release 12.3(8)T, a dropped connection resulted in failure of the call.
Dynamic Transport Switching (UDP to TCP) for Large SIP Requests
RFC 3261 states that large SIP requests, requests within 200 bytes of the maximum transmission unit (MTU), should be transmitted over TCP. Transport over TCP avoids UDP fragmentation, and the switch to TCP can occur even if the gateway is configured to use UDP. If the TCP transmission fails (for example if the terminating gateway does not support TCP), the message is then retried over UDP.
The capability to configure the MTU size on an Ethernet or Fast Ethernet interface already exists on the Cisco SIP gateways. If the MTU is not configured, the default MTU value is 1500 bytes. Assuming an MTU of 1500 bytes, requests larger than 1300 bytes are considered the threshold value for dynamic transport switching.
Two commands allow the user to enable or disable support for dynamic switching. Use the commands to avoid interoperability issues with gateways that do not support TCP and to maintain backward compatibility. The transport switch command can be configured at the global level, and the voice-class sip transport switch command can be configured at the dial peer level. The global configuration is considered only when there is no matching VoIP dial peer.
This feature is disabled by default.
Call-Hold Enhancement
RFC 3264 recommends that call-hold be initiated using the direction attribute (a=sendonly) in SDP. Cisco SIP gateways follow the new guideline, and SIP gateways can now initiate call-hold using either one of the two ways. The offer call-hold command allows the user to globally specify the format to initiate call-hold. That is, the gateway should use a=sendonly or conn addr=0.0.0.0; it cannot set usage to both. The default configuration is a=sendonly, because this is the RFC recommended method. Specifying a call-hold format is not available at the dial peer level.
Note
Expanded Range of the max-forwards Command
In compliance with RFC 3261, the max-forwards command was enhanced with a greater configurable range (1 to 70) and a higher default value (70).
How to Configure SIP RFC Compliance
This section contains the following procedures:
•
•
•
•
Note
–
–
•
Configuring Compliance to RFC 2543
No configuration tasks are required to enable RFC 2543. It is enabled by default.
Configuring Compliance to RFC 2782
To configure compliance with RFC 2782, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring Compliance to RFC 3261
No configuration tasks are required to enable RFC 3261. It is enabled by default.
Configuring Compliance to RFC 3261, RFC 3262, and RFC 3264
This section contains the following procedures:
•
•
Configure SIP Messaging
No configuration is necessary.
Configure TCP and UDP Connection Enhancements
To set the time before the SIP UA ages out a TCP or UDP connection because of inactivity, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configure Dynamic Transport Switching (UDP to TCP) for Large SIP Requests
RFC 3261 states that large SIP requests, within 200 bytes of the maximum transmission unit (MTU), should be transmitted over TCP. Transport over TCP avoids UDP fragmentation, and the switch to TCP can occur even if the gateway is configured to use UDP.
The configurations below describe setting the gateway to switch from UDP to TCP. The default MTU configuration of 1500 bytes on the interface is assumed. After configuration, the threshold value is 1300 bytes—that is, for all SIP requests over 1300 bytes, TCP is the transport mechanism.
You can configure dynamic transport switching on a dial-peer or global basis.
•
•
Configuring Dynamic Transport Switching for Large SIP Requests on a Dial-Peer Basis
To configure switching between UDP and TCP transport mechanisms for a specific dial peer, perform the following steps.
Note
•
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring Dynamic Transport Switching for Large SIP Requests on a Global Basis
To configure switching between UDP and TCP transport mechanisms on all the connections of a Cisco SIP gateway, perform the following steps.
Note
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Note
•
•
To learn more about these commands as well as other verification and troubleshooting commands, see the "Verifying SIP RFC Compliance" section and "Troubleshooting Tips" section.
Configure Call-Hold
To specify how the SIP gateway should initiate call-hold requests, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configure Max Forwards
To set the maximum number of proxy or redirect servers that can forward the SIP request, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Verifying SIP RFC Compliance
To verify SIP RFC compliance, perform the following steps as appropriate (commands are listed in alphabetical order).
Note
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Step 1
Use this command, after a call is made, to learn connection details.
The following sample output shows multiple calls to multiple destinations. This example shows UDP details, but the command output looks identical for TCP calls.
Router# show sip-ua connections udp detailTotal active connections : 2No. of send failures : 0No. of remote closures : 0No. of conn. failures : 0No. of inactive conn. ageouts : 0---------Printing Detailed Connection Report---------Note:** Tuples with no matching socket entry- Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port>'to overcome this error condition++ Tuples with mismatched address/port entry- Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port> id <connid>'to overcome this error conditionRemote-Agent:172.18.194.183, Connections-Count:1Remote-Port Conn-Id Conn-State WriteQ-Size=========== ======= =========== ===========5060 1 Established 0Remote-Agent:172.19.154.18, Connections-Count:1Remote-Port Conn-Id Conn-State WriteQ-Size=========== ======= =========== ===========5060 2 Established 0The following sample output shows sequential display and clearing of call statistics for connection to a particular target (in this case, 172.18.194.183, port 5060).
Caution
1.
Router# show sip-ua connections tcp detailTotal active connections : 1No. of send failures : 0No. of remote closures : 0No. of conn. failures : 0No. of inactive conn. ageouts : 0Max. tcp send msg queue size of 1, recorded for 172.18.194.183:5060---------Printing Detailed Connection Report---------Note:** Tuples with no matching socket entry- Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port>'to overcome this error condition++ Tuples with mismatched address/port entry- Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port> id <connid>'to overcome this error conditionRemote-Agent:172.18.194.183, Connections-Count:1Remote-Port Conn-Id Conn-State WriteQ-Size=========== ======= =========== ===========5060 1 Established 02.
Router# clear sip-ua tcp connection id 1 target ipv4:172.18.194.183:5060Purging the entry from sip tcp processPurging the entry from reusable global connection table3.
Router# show sip-ua connections tcp detailTotal active connections : 0No. of send failures : 0No. of remote closures : 0No. of conn. failures : 0No. of inactive conn. ageouts : 0Max. tcp send msg queue size of 1, recorded for 172.18.194.183:5060---------Printing Detailed Connection Report---------Note:** Tuples with no matching socket entry- Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port>'to overcome this error condition++ Tuples with mismatched address/port entry- Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port> id <connid>'to overcome this error conditionRemote-Agent:172.18.194.183, Connections-Count:0Step 2
Use this command to display SIP statistics, including UPDATE requests.
Router# show sip-ua statisticsSIP Response Statistics (Inbound/Outbound)InformationalTrying 1/4, Ringing 0/0,Forwarded 0/0, Queued 0/0,SessionProgress 1/4Success:OkInvite 1/2, OkBye 1/2,OkCancel 0/2, OkOptions 0/0,OkPrack 1/4, OkPreconditionMet 0/0,OkSubscribe 0/0, OkNotify 0/0,OkInfo 0/0, 202Accepted 0/0,OkUpdate 0/0Redirection (Inbound only):MultipleChoice 0, MovedPermanently 0,MovedTemporarily 0, UseProxy 0,AlternateService 0Client Error:BadRequest 0/0, Unauthorized 0/0,PaymentRequired 0/0, Forbidden 0/0,NotFound 0/0, MethodNotAllowed 0/0,NotAcceptable 0/0, ProxyAuthReqd 0/0,ReqTimeout 0/0, Conflict 0/0, Gone 0/0,ReqEntityTooLarge 0/0, ReqURITooLarge 0/0,UnsupportedMediaType 0/0, BadExtension 0/0,TempNotAvailable 0/0, CallLegNonExistent 0/0,LoopDetected 0/0, TooManyHops 0/0,AddrIncomplete 0/0, Ambiguous 0/0,BusyHere 0/0, RequestCancel 0/2,NotAcceptableMedia 0/0, BadEvent 0/0,SETooSmall 0/0, RequestPending 0/0Server Error:InternalError 0/0, NotImplemented 0/0,BadGateway 0/0, ServiceUnavail 2/0,GatewayTimeout 0/0, BadSipVer 0/0,PreCondFailure 0/0Global Failure:BusyEverywhere 0/0, Decline 0/0,NotExistAnywhere 0/0, NotAcceptable 0/0Miscellaneous counters:RedirectRspMappedToClientErr 0SIP Total Traffic Statistics (Inbound/Outbound)Invite 4/4, Ack 4/3, Bye 2/1,Cancel 2/0, Options 0/0,Prack 4/1, Comet 0/0,Subscribe 0/0, Notify 0/0,Refer 0/0, Info 0/0,Update 0/0Retry StatisticsInvite 1, Bye 0, Cancel 0, Response 0,Prack 0, Comet 0, Reliable1xx 0, Notify 0SDP application statistics:Parses: 6, Builds 10Invalid token order: 0, Invalid param: 0Not SDP desc: 0, No resource: 0Last time SIP Statistics were cleared: <never>
Troubleshooting Tips
Note
•
•
Sample output of some of these commands is shown below:
Sample Output for the debug ccsip transport Command
The operations captured here show the following:
•
•
•
•
•
Router# debug ccsip transport...1w1d: //18/8E16980D800A/SIP/Transport/sipSPISendInvite: Sending Invite to the transport layer1w1d: //18/8E16980D800A/SIP/Transport/sipSPIGetSwitchTransportFlag: Return the Global configuration, Switch Transport is TRUE1w1d: //18/8E16980D800A/SIP/Transport/sipSPITransportSendMessage: msg=0x64082D50, addr=172.18.194.183, port=5060, sentBy_port=0, is_req=1, transport=1, switch=1, callBack=0x614FAB581w1d: //18/8E16980D800A/SIP/Transport/sipSPITransportSendMessage: Proceedable for sending msg immediately1w1d: //18/8E16980D800A/SIP/Transport/sipTransportLogicSendMsg: switch transport is 11w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportGetInterfaceMtuSize: MTU size for remote address 172.18.194.183 is 5001w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportVerifyMsgForMTUThreshold: Interface MTU Size 500, Msg Size 10961w1d: //18/8E16980D800A/SIP/Transport/sipTransportLogicSendMsg: Switching msg=0x64082D50 transport UDP->TCP1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportSetAgeingTimer: Aging timer initiated for holder=0x64084058,addr=172.18.194.1831w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipCreateConnHolder: Created new holder=0x64084058, addr=172.18.194.1831w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostRequestConnection: Posting TCP conn create request for addr=172.18.194.183, port=5060, context=0x64128D5C1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportSetConnWaitTimer: Wait timer set for connection=0x64129BF4,addr=172.18.194.183, port=50601w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipCreateConnInstance: Created new initiated conn=0x64129BF4, connid=-1, addr=172.18.194.183, port=5060, transport=tcp1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessConnCreated: gConnTab=0x64128D5C, addr=172.18.194.183, port=5060, connid=1, transport=tcp1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipInstanceHandleConnectionCreated: Moving connection=0x64129BF4, connid=1state to pending1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWConnectionCreated: context=0x64128D5C1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessConnCreated: gConnTab=0x64128D5C, addr=172.18.194.183, port=5060, connid=1, transport=tcp1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: Posting send for msg=0x64082D50, addr=172.18.194.183, port=5060, connId=1 for TCP...Configuration Examples for SIP RFC Compliance
This section provides the following configuration example:
•
Note
SIP Gateway Compliance to RFC 3261, RFC 3262, and RFC 3264: Example
This section provides a configuration example to match the identified configuration tasks in the previous sections.
1w1d: %SYS-5-CONFIG_I: Configured from console by consoleBuilding configuration...Current configuration : 3326 bytes!!Last configuration change at 18:09:20 EDT Fri Apr 23 2004!version 12.3service timestamps debug uptimeservice timestamps log uptimeno service password-encryptionboot-start-markerboot system tftp mantis/c3640-is-mz.disc_w_pi 172.18.207.10boot-end-marker!clock timezone EST -5clock summer-time EDT recurringvoice-card 3!aaa new-model!aaa accounting connection h323 start-stop group radiusaaa nas port extendedaaa session-id commonip subnet-zero!ip cefip host example.com 172.18.194.183ip host CALLGEN-SECURITY-V2 10.36.54.81 10.1.0.0ip name-server 172.18.192.48!isdn switch-type primary-ni!trunk group 1!voice service voipsiprel1xx require "100rel"transport switch udp tcp!voice class uri 800 sippattern test@example.com!controller T1 3/0framing sflinecode amipri-group timeslots 1-24!controller T1 3/1framing sflinecode amipri-group timeslots 1-24gw-accounting aaa!interface Ethernet0/0description CentreComm Hub port 9 in PP070ip address 172.18.194.170 255.255.255.0no ip proxy-arpip mtu 500half-duplexno cdp enableip rsvp bandwidth 100 100!interface Serial3/0:23no ip addressno logging event link-statusisdn switch-type primary-niisdn incoming-voice voiceno cdp enable!interface Serial3/1:23no ip addressno logging event link-statusisdn switch-type primary-niisdn protocol-emulate networkisdn incoming-voice voiceno cdp enable!no ip http serverip classlessip route 0.0.0.0 0.0.0.0 172.18.194.1ip route 0.0.0.0 0.0.0.0 Ethernet0/0ip route 10.0.0.0 255.0.0.0 172.18.194.1ip route 172.16.0.0 255.0.0.0 Ethernet0/0!dialer-list 1 protocol ip permitno cdp run!radius-server host 10.13.84.133 auth-port 1645 acct-port 1646radius-server timeout 2radius-server key ciscoradius-server vsa send accountingradius-server vsa send authentication!control-plane!call application voice testapp79 tftp://172.18.207.10/mantis/my_app.tclcall application voice testapp888 tftp://172.18.207.10/mantis/AL_FEAT_SIP_URL_O_RV_79.tclcall application voice testapp888 mcid-dtmf 9876call application voice testapp888 test 5444!voice-port 1/1/0!voice-port 1/1/1!voice-port 3/0:23!voice-port 3/1:23!dial-peer cor custom!dial-peer voice 9876 voipdestination-pattern 9876voice-class sip transport switch udp tcpsession protocol sipv2session target ipv4:172.18.194.183session transport udp!dial-peer voice 222 potsincoming called-number .direct-inward-dial!sip-uamax-forwards 65retry invite 4retry bye 4retry cancel 4retry comet 4retry notify 4timers connection aging 15offer call-hold conn-addr!line con 0exec-timeout 0 0line vty 0 4password password1ntp clock-period 17179695ntp server 172.18.194.178ntp server 10.81.254.131!endAdditional References
The following sections provide references related to the Achieving SIP RFC Compliance.
Related Documents
Standards
MIBs
RFCs
Technical Assistance
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2002-2010 Cisco Systems, Inc. All rights reserved.
