Applies To:

Show Versions Show Versions

Manual Chapter: Troubleshooting
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Troubleshooting

Log Messages

Configuration Validation Errors

Table 1. Configuration Validation Errors
Configuration Failure Condition Error Message
Virtual server config does not have SIP router profile but has SIP session profile SIP session profile requires SIP router profile also to be assigned to the virtual server <name>
Virtual server config does not have SIP session profile but has SIP router profile SIP router profile requires the SIP session profile to also be assigned to the virtual server <name>
Deleting a route which is in use by a SIP router profile The route <name> is referenced by one or more router profiles
Deleting a peer which is in use by a SIP route. The peer <name> is referenced by one or more SIP routes.
Duplicate route attached to router. Same [request-uri, from-uri, to-uri, virtual-server-name] combination in route <name> exists in the profile <name>
Peer refers to non-existent route. Peer <name> refers to non-existing Static-Route <name>
Route refers to non-existent peer. Static Route <name> refers to non-existing Peer <name>

Connection Termination Reasons

If logging of reset cause is enabled via the tm.rstcause.log db variable, the reason for connection termination is logged to /var/log/ltm.

Reset reason examples:

Table 2. Connection Termination Reasons
Reason Why Text Description
SIP Error Unexpected internal signaling
SIP parser error Unable to parse SIP message on a stream transport (like TCP)

MRF SIP Troubleshooting Logs

If MRF SIP diagnostic log events are enabled via the log.mrsip.level db variable, the following events will be logged to /var/log/tmm?.

Table 3. MRF SIP Troubleshooting Logs
Event Text Log Level Description
MR SIP: Invalid config attribute <name> in profile <name> Error An unexpected configuration attribute was found. For example, an unsupported persist-key was used.
MR SIP: Missing header <name> in the message Error One of the mandatory SIP header attributes (To, From, Call-ID, Route, Via) was missing. Since the message will not be accepted without the required attributes, this error occurs when an iRule script removes all instances of one of the required scripts after parsing.
MR SIP: Decrypt branch parameter failed with error : <error_text> Error Unable to decrypt our generated Via header.
MR SIP: Encrypt branch parameter failed with error : <error_text> Error Unable to encrypt our generated Via header.
MR SIP: Generation of AES encryption key failed Error Unable to generate AES encryption key for Via header encryption.
MR SIP: Parse error reading number for <value> value near <offset> Status code <status code> Notice Unable to parse a number for the specified value near the specified offset of an input SIP message. If error response is configured, the specified status code response will be returned and the corresponding stats counter will be incremented.
MR SIP: Parse error bad sip protocol version in headline near <offset>. Status Code <status code> Notice Invalid sip protocol version near the specified offset of an input SIP message. If error response is configured, the specified status code response will be returned and the corresponding stats counter will be incremented.
MR SIP: Parse error invalid or malformed uri in headline near <offset>. Status Code <status code> Notice The SIP URI in the headline of an input SIP message is invalid or malformed. If error response is configured, the specified status code response will be returned and the corresponding stats counter will be incremented.
MR SIP: Parser error invalid headline near <offset>. Status Code <status code> Notice The headline of the incoming sip message is invalid near the specified offset. If error response is configured, the specified status code response will be returned and the corresponding stats counter will be incremented.
MR SIP: Parser error to many headers near <offset>. Status Code %d. Notice The incoming SIP message contains to many headers to be processed. The header near the specified offset should be the first header that exceeded the limit. If error response is configured, the specified status code response will be returned and the corresponding stats counter will be incremented.
MR_SIP: Parser error extraneous header field near <offset> Status code <status code> Notice The incoming SIP message contains a extra field in a header near the specified offset. If error response is configured, the specified status code response will be returned and the corresponding stats counter will be incremented.
MR_SIP: Parser error header to large near <offset>. Status Code <status code>. Notice The incoming SIP message has a header line that is too long near the specified offset. If error response is configured, the specified status code response will be returned and the corresponding stats counter will be incremented.
MR_SIP: Parser error missing header code <code>. Status Code <status code>. Notice The incoming SIP message is missing a required header. The displayed code is a bit-field that can be decoded with access to the internals of the sip parser. If error response is configured, the specified status code response will be returned and the corresponding stats counter will be incremented.
MR_SIP: Parser error CSEQ method does not match headline tag <tag> : <tag>. Status Code <status code> Notice The incoming SIP message has a mis-match between the headline tag. If error response is configured, the specified status code response will be returned and the corresponding stats counter will be incremented.
MR_SIP: Parser max-forwards value has reached zero. Status Code <status code> Notice The incoming sip message has been forwarded too many times while being routed, causing the max-forwards value to be decremented to zero. The BIG-IP® system will not process this message. If error response is configured, the specified status code response will be returned and the corresponding stats counter will be incremented.
MR_SIP: Server in maintenance mode. Status Code 503 Notice The server has been placed in maintenance mode and will not process traffic. If error response is configured, status code 503 response will be returned and the corresponding stats counter will be incremented.
MR_SIP: Loop detected. Status code 482. Notice The incoming SIP message contains a SIP round loop. If error response is configured, status code 482 response will be returned and the corresponding stats counter will be incremented.
MR_SIP: Missing Media Connection attributes. Status Code 488. Notice The incoming SIP message is missing required Media Connection Attributes. If error response is configured, status code 488 response will be returned and the corresponding stats counter will be incremented.
MR_SIP: Too many media sessions <count> / <count limit>. Error Code <code> Notice The number of media sessions in <count> has exceeded the configured <limit count>. If error response is configured, the specified code response will be returned and the corresponding stats counter will be incremented.

SIP Troubleshooting Logs

If MRF SIP diagnostic log events are enabled via the log.mrsip.level db variable, the following events will be logged to /var/log/tmm?.

Table 4. SIP Troubleshooting Logs
Event Text Log Level Description
Max Global Registration limit reached Error MR SIP: Subscriber registration failed %s, configured max global registration value :%u reached
Concurrent Session Per Subscriber limit reached Error MR SIP: concurrent session per subscriber limit %u reached, subscriber cannot make calls: %s
Non registered subscriber call out Error MR SIP: non registered subscriber %s, call dropped. Change SIP session configuration to allow non registered subscriber call out
Subscriber registration failed Error MR SIP: subscriber %s, unable to register, received non-2xx SIP response"
HUDEVT_SA_COOKIE_PICK event failed Error MR SIP: HUDEVT_SA_COOKIE PICKED event error
Listener creation failed Error MR SIP: Failed to create Listener %K for the subscriber %s
Listener deleted Error MR SIP: Listener deleted due translation lookup failure %K

sipdb Tool

The sipdb tool will be used to display or delete the persistence or media records from session database. The persistence records are created in LB mode when persistence is configured.

The media records are created in ALG mode.

Usage

sipdb [options]
sipdb --persist [--delete] [--router=name] [--key=value] [--type=persistence_type] [--ipproto=protocol] [–verbose]
sipdb --media [--delete] [--router=name] [-key=call-id]
sipdb --register [–delete] [--router=name] [-key=subscriber uri]
sipdb --help

Options

Table 5. Options
Option Description

--persist

-s

Indicates persistence mode. This option should be used to display or delete persistence records. This is the default mode.

Each record displays the persistence type, persistence key, originating ip:port, destination ip:port, protocol and the time remaining.

The records are grouped by the SIP router profile.

To delete the persistence record the record key has to be specified. Details are given below in the example section

--media

-m

Indicates media mode. This option should be used to perform operations on media records.

The media mode displays the Callid, Origination IP:RTP Port, RTCP Port, Interface name Destination IP: RTP Port, RTCP Port, Interface name.

In ALG-Translation mode, the output displays the translated address for the subscriber.

--register

-g

Indicates register mode. This option should be used to perform operations on register records.

The register mode displays the subscriber private address and translated address and the lifetime of the registration.

--help

-h

Displays the help text.

--router = name

-r name

The sip router profile name. This option is used to filter the output matching records for the specified SIP router profile.

The default partition '/Common' should be specified. For example '/Common/siprouter'

The option can be used for both modes i.e. persist and media modes.

--key=value

-k value

Specifies the key for the session record. The option is used to filter the display with the specific key or delete a specific key.

For persistence mode the key is either a SIP Call-ID, Source Address or Custom value.

For Media mode the key is SIP Call-ID.

For register mode the key is the subscriber uri.

--delete

-d

To delete a particular record.

This option along with the mode and the key details specifies the record to be deleted.

For persistence mode to delete a record the router name, key, persistence type and ip proto values have to be specified.

To delete a media entry the router name and SIP Call-ID needs to be specified.

--type = value

-t value

Type of persistence entry.

The option is applicable when deleting a persistence record.

Following are the applicable values.

[C|c] For Call-ID id persistence
[S|s] For Source Address persistence
[O|o] For Custom type persistence

--ipproto = value

-p value

Either TCP or UDP.

The option is applicable when deleting a persistence record.

--verbose

-v

This option is applicable in persistence mode.

Displays the destination transport and pool name in addition to the default display.

Examples

Default Display of Persistence Entries
#sipdb
Router: /Common/siprouter       Number of entries: 1
Key                             Originator             Destination           Proto Timeout
--------------------------------------------------------------------------------------------------------------------------------
C 1-8834@10.10.20.7             10.10.20.2:35462       10.10.10.2:5060       TCP   175
 
Router: /Common/siprouter_alg      Number of entries: 1
Key                             Originator             Destination           Proto Timeout
--------------------------------------------------------------------------------------------------------------------------------
C 1-8835@10.10.20.7             10.10.20.2:35462       10.10.10.2:5060       TCP   175
Verbose Display of Persistence Entries
# sipdb -v
Router: /Common/siprouter       Number of entries: 1
Key                             Originator             Destination            Proto Timeout Transport    Pool Name
-------------------------------------------------------------------------------------------------------------------------------------
C 1-8872@10.10.20.7             10.10.20.2:56913       10.10.10.2:5060        TCP   175     vs:vs_sip    sip_pool
 
Router: /Common/siprouter_alg       Number of entries: 1
Key                             Originator             Destination            Proto Timeout Transport    Pool Name
-------------------------------------------------------------------------------------------------------------------------------------
C 1-8874@10.10.20.7             10.10.20.2:56913       10.10.10.2:5060        TCP   175     vs:vs_sip    sip_pool
To filter the above record for a particular SIP router profile name
#sipdb --persist –router /Common/siprouter --verbose
#sipdb --persist –router=/Common/siprouter --verbose
#sipdb --persist -r /Common/siprouter
 
Router: /Common/siprouter       Number of entries: 1
Key                    Originator             Destination            Proto Timeout Transport  Pool Name
-------------------------------------------------------------------------------------------------------------------------------------
C 1-8872@10.10.20.7    10.10.20.2:56913       10.10.10.2:5060        TCP   175     vs:vs_sip  sip_pool
To filter the record for a persistence key
#sipdb --persist –key 1-8872@10.10.20.7 --verbose
 
Router: /Common/siprouter       Number of entries: 1
Key                    Originator             Destination            Proto Timeout Transport  Pool Name
-------------------------------------------------------------------------------------------------------------------------------------
C 1-8872@10.10.20.7    10.10.20.2:56913       10.10.10.2:5060        TCP   175     vs:vs_sip  sip_pool
To delete the above record
sipdb persist --delete --key 1-8872@10.10.20.7   --router /Common/siprouter --type C --ipproto TCP
 
Record Successfully deleted

Moving router and/or virtual to different traffic group

The BIG-IP® system does not support changing the traffic group or a router and/or virtual server. MRF stores state that has a different lifetime than a connection in an internal in-memory database (known as session db). This includes persistence tables (SIP LB), call tables (SIP ALG), and registrations tables (SIP ALG), etc. Records stored in session db are auto replicated between the active and standby device. Part of the key for each entry in the session db is the identifier for a traffic-group. If the traffic-group of a virtual and/or router instance is changed all data stored in session db will be orphaned.

Config changes not loading, or stats don't show up on new router instance

Most changes to config are applied to existing connections. Changes to the set of profiles used by a connection only apply to new connections. Since many message routing protocols use long lived connections, some config changes will not effect existing connections. For example replacing the router profile used by a virtual server will not apply to existing connections. Thus all traffic on existing connections will still be routed through the previous router instance and the stats for that traffic will be included with the previous router instance. To apply the traffic to the new router instance, the existing connections will need to be closed forcing the clients to create new connections.

iRule changes not loading

Changes to iRule scripts attached to a virtual or transport-config do not change the scripts executing on existing connections. New connections will use the updated scripts. To cause the new script code to be applied, all existing connections (both client side and server side) will need to be closed and new connections created. This may be avoided by moving the business logic of the script to a procedure as follows:

ltm rule mylib {
    proc sip_ingress {} {
        if { [SIP::is_request] and [clientside] } {
            # do something
            # change here
        } else {
            # do something else
            # change here
        }
    }
}
ltm rule routing {
    when SIP_INGRESS {
        call mylib::sip_ingress
    }
}

Dropped UDP datagrams

Dropped UDP datagrams have been observed at very low traffic rates (100 calls per second). One cause has been MPI latency. Try making sure the 'scheduler.hsbpollpode.ltm' db var is set to "always". This has been show to reduce the MPI call latency.

MRF Debugging

Did the message reach the message router?

There are multiple places where processing can stop or a failure can occur. The stats of the profiles added to the virtual server (or transport-config) should be used to determine if the message reached the message router. From the transport profile's stats (TCP/UDP/SCTP), it can be determined if packets were received by the transport filter. From the protocol profile's stats (sipsession), it can be determined if the received packets were correctly parsed into messages. If an error was found in the message parsing this should be detectable using the protocol's stats.

The message router profile (siprouter) stats should increment with each message received. The result of each messages routing operation should also be represented in the stats.

Why did the message fail routing

The MR_INGRESS event is raised for each message before it enters routing . Once routing is complete either MR_EGRESS or MR_FAILED event is raised. The message metadata can be logged during these events to help debug the results of routing. Some fields and their usage follows:

Metadata Field Populated Purpose
lasthop before MR_INGRESS Contains the TMM and flow_id of the originating connection of the message
nexthop before MR_INGRESS (or during MR_INGRESS) Selects the destination connection for the message
route after routing (or during MR_INGRESS) The value of the selected route (peer list). If set during MR_INGRESS, this route will be used instead of performing route lookup
originator before MR_INGRESS The IP, port and rtdom_id of the originator of the connection. Also contains the transport type and name of the originating connection.
status after routing The results of the route lookup
attempted after routing (or during MR_INGRESS) The list of destination hosts attempted. This list of hosts will be treated as marked down when performing peer selection and load balanced pick.
retry_count after routing The number of times this message has been submitted for routing
Why did the message fail routing

The MR_INGRESS event is raised for each message before it enters routing . Once routing is complete either MR_EGRESS or MR_FAILED event is raised. The message metadata can be logged during these events to help debug the results of routing. Some fields and their usage follows:

Metadata Field Populated Purpose
lasthop before MR_INGRESS Contains the TMM and flow_id of the originating connection of the message
nexthop before MR_INGRESS (or during MR_INGRESS) Selects the destination connection for the message
route after routing (or during MR_INGRESS) The value of the selected route (peer list). If set during MR_INGRESS, this route will be used instead of performing route lookup
originator before MR_INGRESS The IP, port and rtdom_id of the originator of the connection. Also contains the transport type and name of the originating connection.
status after routing The results of the route lookup
attempted after routing (or during MR_INGRESS) The list of destination hosts attempted. This list of hosts will be treated as marked down when performing peer selection and load balanced pick.
retry_count after routing The number of times this message has been submitted for routing
MR:route_status: "queue full"

One reason for MR_FAILED would be when MR:route_status is set to "queue full". This result can happen when the following conditions are met:

  1. MRF-SIP profile with TCP for transport.
  2. SIP Peer has very few pool members.
  3. One of the pool member is down.
  4. Burst of SIP Traffic with message size > 2K Bytes.

There are 2 configurable items (Max-Pending-Messages and Max-Pending-Bytes) in the router config to define the queue capacity. If the incoming traffic is high with large messages then the possibility of filling up the queue increases significantly before the connection request timeout occurs on the pool member which is down.

If the message size is larger than 2k then try increasing the Max-Pending-Bytes first. Otherwise, increase Max-Pending-Messages. If neither increase works, then increase both values.

Messages received on per-client created connections

All messages received on an outgoing connection created using the per-client connection mode, will automatically be forwarded to the connection that received the request which caused the outgoing connection to be created. This includes request messages received on this connection. This is because the connection acts as a direct connection for communication between the original client and the other device. This routing is done be setting the nexthop of all messages received to the last hop of the original request message.

For example:

A SIP INVITE request is received on a connection from 10.10.10.21 to 10.10.20.50. This message gets routed to proxy server 10.20.30.85 using a transport-config that does not configure SNAT and has a connection-mode of per-client. An outgoing connection will be created from 10.10.10.21 to 10.20.30.85. All messages (whether responses of requests) received on the outgoing connection will be automatically routed to the SIP endpoint at 10.10.10.21 using the original incoming connection.

To route a message received on a per-client created connection to another device, the nexthop field will have to be cleared using the MR::message nexthop none command as follows:

when MR_INGRESS {
  MR::message nexthop none
  MR::message route config /Common/other_tc host 10.20.30.40:1234
}

Debugging Request Routing

Overview

SIP Request routing: Request messages are routed via iRule, Persistence or Route Table.

  1. An iRule may direct MRF how to route a message during MR_INGRESS. To set the route, use the ‘MR::message route …’ command.
  2. A persistence entry using the same persistence key (often call-id) if present will route a message. In MRF persistence entries are bi-directional and remember both SIP devices communicating in the dialog. The persistence table can be accessed via the sipdb tool. The two endpoints in the persistence table are identified as the originator and the destination. The destination of originator versus destination has to do with which direction the original request message that created the persistence entry. If a message arrives that generates the same persistence key, the address of the source of the message will be matched against the destination in the persistence record to determine which direction the message is flowing.
  3. If no persistence record is found, the best route table entry for the router is used to select the destination for the route. Attributes of the message are matched against the message to determine which route applies for the current message. MRF SIP route table implementation can match against the message’s request-URI, from-URI, to-URI and originating virtual server. If the message was received on a connection that was initiated by the BIG-IP, the parameters of that connection were likely defined by a transport-config. Messages arriving on a transport-config connection will not match any routes which are filtered by a virtual server.

Request Routing Debugging

iRules can be used for route debugging. Remember that the iRule needs to be on each transport in the system (virtual servers and transport-configs). MR_INGRESS event runs on the connection that received the request message. MR_EGRESS event runs on the connection that the message is being sent out. MR_FAILED event runs on the connection that received the request message when a message failed to be routed.

SIP iRule commands can be run in the MR iRule events. MRF communicates with the SIP parser to instruct it as to which message is currently used during the MR event.

To know if a message is a request or a response, the following conditional can be used:

If {[SIP::response code] eq “”} { # this is a request message

During MR_INGRESS, the message’s route can be examined as follows:

Log local0. “route [MR::message route]”

The transport type and name can be inspected (in v12.0 and later) via an iRule command as follows:

Log local0. “transport [MR::transport]”

An example script for MR_INGRESS is as follows:

when MR_INGRESS {
  log local0. “transport: [MR::transport] flow_id: [MR::flow_id]”
  if {[SIP::reponse code] eq “”} {
    log local0. “request [SIP::method] persist key [SIP::persist] route [MR::message route]”
  } else {
    log local0. “response [SIP::response code] nexthop [MR::message nexthop] route [MR::message route]"
  }
}

After routing has occurred, the messages route field will be populated with the value of the selected route and either MR_EGRESS will be executed or MR_FAILED. If routing succeeded, the route status will be set to “route found” and MR_EGRESS event will be raised on the outgoing connection. If routing failed, the route status will be set and MR_FAILED event will be raised on the incoming connection.

when MR_EGRESS {
  log local0. “transport: [MR::transport] flow_id: [MR::flow_id]”
  if {[SIP::reponse code] eq “”} {
    log local0. “request [SIP::method] persist key [SIP::persist] route [MR::message route]”
  } else {
    log local0. “response [SIP::response code] nexthop [MR::message nexthop] route [MR::message route]"
  }
}
 
when MR_FAILED {
  log local0. “transport: [MR::transport] flow_id: [MR::flow_id] route status [MR::message status]”
  if {[SIP::reponse code] eq “”} {
    log local0. “request [SIP::method] persist key [SIP::persist] route [MR::message route]”
  } else {
    log local0. “response [SIP::response code] nexthop [MR::message nexthop] route [MR::message route]"
  }
}
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)