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:

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?.

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?.

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

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.

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.

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 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.

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:

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
}

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.

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]"
  }
}