SIP Traces, Pings and Messages¶

SIP Traces¶

SIP Tracing is a diagnostic tool for phone systems using SIP (Session Initiation Protocol) for interactions across trunks and between endpoints. Traces give detailed information about calls and call attempts while debugging and troubleshooting.

Uses of SIP protocol include call setup, maintenance, and tear-down, this tool is typically used only for call connection issues.

Call quality issues are often identified using other methods.

Here is an example describing a SIP trace:

    sequenceDiagram
    autonumber
    Alice->>Bob: INVITE
    Bob-->>Alice: 100 Trying
    Bob-->>Alice: 180 Ringing
    Bob->>Alice: 200 OK (Connected)
    Alice->>Bob: ACK
    Note over Alice,Bob: The call is active
    Alice->>Bob: BYE
    Bob->>Alice: 200 OK

Alice and Bob represent the parties on the call. Alice sends an INVITE packet to Bob. Then Bob sends a 100 Trying (provides you the feedback that your request is getting processed by a SIP Application) message together with 180 Ringing (the Destination User Agent has received the INVITE message and is alerting the user of the call).

Further, 200 OK is sent which means the calls are connected.

The ACK message is sent from Alice to Bob confirming that the call has got connected.

To view the SIP Trace of a call:

1. Click a Call ID to view its SIP traces.

2. Click SIP traces to view the SIP trace.

   

3. Toggle between Relative Time and Absolute Time for a specific time of day.

4. Options to download as Text or an Image.

• How to correlate a Reply to an Initial Request

The correlation of a Reply to an Initial Request can be done when the Invites have the same CSequence

    sequenceDiagram
    autonumber
    Alice->>Bob: INVITE (cseq 123)
    Bob-->>Alice: 100 Trying
    Bob-->>Alice: 180 Ringing
    Bob->>Alice: 408 Ring Timeout (cseq 123 INVITE)

SIP Pings¶

Case 1: Normal SIP Ping

    sequenceDiagram
    autonumber
    Alice->>Bob: INVITE (cseq 1)
    Bob-->>Alice: 100 Trying
    Bob-->>Alice: 180 Ringing
    Bob->>Alice: 200 OK (Connected)
    Alice->>Bob: ACK
    Note over Alice,Bob: The call is active
    Bob->>Alice: OPTIONS
    Alice->>Bob: 200 OK
    Note over Alice,Bob: The call has ended
    Alice->>Bob: BYE
    Bob->>Alice: 200 OK

Case 2: Alice Disappears

    sequenceDiagram
    autonumber
    Alice->>Bob: INVITE (cseq 1)
    Bob-->>Alice: 100 Trying
    Bob-->>Alice: 180 Ringing
    Bob->>Alice: 200 OK (Connected)
    Alice->>Bob: ACK
    Note over Alice,Bob: The call is active
    Bob->>Alice: OPTIONS
    Note over Alice,Bob: We did not get a reply, other side disappears 
    Note over Alice,Bob: We will drop the call
    Bob->>Alice: BYE (No SIP Ping Reply)

In this case, the call is half-way connected and Alice doesn't reply to the message sent by Bob. Bob decides to drop the call.

If Alice is alive, then you may get a reply, if there is a reply, then this is likely a premature disconnection and there is a fault with the SIP ping on Alice's side.

Case 3: 3-party Example

    sequenceDiagram
    autonumber
    Alice->>ConnexCS: INVITE (cseq 1)
    ConnexCS-->>Alice: 100 Trying
    ConnexCS->>Charlie: INVITE (cseq 1)
    Charlie-->>ConnexCS: 100 Trying
    Charlie-->>ConnexCS: 180 Ringing
    ConnexCS-->>Alice: 180 Ringing
    Charlie->>ConnexCS: 200 OK (Connected)
    ConnexCS->>Alice: 200 OK (Connected)
    Alice->>ConnexCS: ACK
    ConnexCS->>Charlie: ACK
    Note over Alice,Charlie: The call is active
    ConnexCS->>Alice: OPTIONS
    Alice->>ConnexCS: 200 OK
    ConnexCS->>Charlie: OPTIONS
    Charlie->>ConnexCS: 200 OK
    Note over Alice,Charlie: Call Disconnects
    Charlie->>ConnexCS: BYE
    ConnexCS->>Alice: BYE
    Alice->>ConnexCS: 200 OK
    ConnexCS->>Charlie: 200 OK

In this case, the communication happens between 3 parties. ConnexCs is sending OPTION packets in both the directions (to Alice and Charlie).

Case 4:Missing SIP Ping Call Disconnection (Charlie disappears)

    sequenceDiagram
    autonumber
    Alice->>Bob: INVITE (cseq 1)
    Bob-->>Alice: 100 Trying
    Bob->>Charlie: INVITE (cseq 1)
    Charlie-->>Bob: 100 Trying
    Charlie-->>Bob: 183 Ringing
    Bob-->>Alice: 183 Ringing
    Charlie->>Bob: 200 OK (Connected)
    Bob->>Alice: 200 OK (Connected)
    Alice->>Bob: ACK
    Bob->>Charlie: ACK
    Note over Alice,Charlie: The call is active
    Bob->>Alice: OPTIONS
    Alice->>Bob: 200 OK
    Bob->>Charlie: OPTIONS
    Note over Alice,Charlie: No reply from Charlie, we need to disconnect
    Bob->>Charlie: BYE
    Bob->>Alice: BYE
    Alice->>Bob: 200 OK

In this case, when we send the OPTION packet to Charlie, he doesn't reply. The OPTION message disappears and we need to disconnect the call.

Another scenario is when ConnexCS sends message to Charlie and Charlie is active on the call, he will send a BYE message to Alice and we won't see a reply to that.

SIP Messages¶

ACK Message¶

An ACK is an Acknowledgement of a final reply.

    sequenceDiagram
    autonumber
    Alice->>Bob: INVITE
    Bob-->>Alice: 100 Trying
    Bob-->>Alice: 180 Ringing
    Bob->>Alice: 200 OK (Connected)
    Alice->>Bob: ACK
    Note over Alice,Bob: The call is active
    Alice->>Bob: BYE
    Bob->>Alice: 200 OK

Cancel Message¶

CANCEL message indicates that the previous request was terminated by the user. In this case, the CANCEL message is sent from Alice to Bob.

Cancel can be due to PDD timer being too high or ringing exists for a longer duration.

Bob should send 487 Canceled message to Alice.

    sequenceDiagram
    autonumber
    Alice->>Bob: INVITE
    Bob-->>Alice: 100 Trying
    Alice->>Bob: CANCEL (PDD Too High)
    Bob->>Alice: 487 Canceled
    Alice->>Bob: INVITE
    Bob-->>Alice: 100 Trying
    Bob-->>Alice: 180 Ringing
    Alice->>Bob: CANCEL (Alternative, Ringing Too Long)
    Bob->>Alice: 487 Canceled

200 OK Message¶

200 OK is a Success message. To understand how the 200 OK is related to we need to follow back the original cseq.

For example, if you don't see a 200 OK for a BYE message it means the other side has disappeared.

Re-Transmissions¶

Re-transmissions occur when the same INVITE is sent more than once. This means the same packets were sent more than once.

Re-transmissions only happen on UDP. Re-transmissions occur when packets either don't reach the receiver or get lost in transmission. Thus, re-transmissions are done after a certain time interval using specific timers.

Here is an example describing Re-transmissions:

sequenceDiagram
autonumber
rect rgb(127, 0, 255)
rect rgb(100, 180, 255)
rect rgb(252, 110,153)
Alice->>Bob: INVITE (cseq 1)
end
Note over Alice,Bob: 500ms delay
rect rgb(252, 110,153)
Alice->>Bob: INVITE (cseq 1)
end
rect rgb(252, 110,153)
Bob-->>Alice: 100 Trying
end
rect rgb(252, 110,153)
Bob-->>Alice: 180  Ringing
end
rect rgb(252, 110,153)
Bob->>Alice: 200 OK (Connected)
end
rect rgb(252, 110,153)
Alice->>Bob: ACK
end
end
Note over Alice,Bob: The call is active
rect rgb(100, 180, 255)
rect rgb(252, 110,153)
Alice->>Bob: BYE
end
rect rgb(252, 110,153)
Bob->>Alice: 200 OK
end
end
end

Alice and Bob represent the parties on the call. Alice sends an INVITE packet to Bob. INVITE is an initial request.

Then Bob sends a 100 Trying (provides you the feedback that your request is getting processed by a SIP Application) message along with 180 Ringing (the Destination User Agent has received the INVITE message and is alerting the user of the call). 100 Trying and 180 Ringing are provisional responses.

The re-invites get absorbed when they're received. When Bob receives the INVITE packet and a special timer is set (please see the below timer table) to how long it should wait for re-transmissions. If any packet is received within this time-frame, the packet gets ignored.

Further, 200 OK is sent which means the calls gets connected. 200 OK is a final reply.

The ACK is message is sent from Alice to Bob confirming that the call has been connected.

Each line is a Message.

From 1 message (INVITE) to message 5 (ACK), it's considered as a single Transaction.

Similarly, messages 6 (BYE) and 7 (200 OK) are also considered as a single Transaction.

From message 1 to message 7, the whole conversation is a Dialog.

You can have take a look at the various SIP Timers in the table below:

Table source: IBM; Original Ref: RFC 3261

Various Timers¶

     sequenceDiagram
    autonumber
    Alice->>Bob: INVITE
    Note over Alice,Bob: First Reply Timer (500ms)
    Bob-->>Alice: 100 Trying
    Note over Alice,Bob: PDD Timer (5s)
    Bob-->>Alice: 180 Ringing
    Note over Alice,Bob: Ring Timer (30s)
    Bob->>Alice: 200 OK (Connected)
    Alice->>Bob: ACK
    Note over Alice,Bob: Max Call Duration Timer (1 hour)
    Alice->>Bob: BYE
    Bob->>Alice: 200 OK

Here, Alice sends an invite to Bob and it's expected to get a reply (100 Trying) within in 500ms which is a First Reply Timer.

Then a PDD timer set for 5s to hear the ringing. Post-dial delay (PDD) is the measurement of how long it takes for a calling party to hear a ring-back tone after initiating a call.

The time from when the respondent's phone starts ringing until it's answered; is a Ring Timer.

When the call is active Max Call Duration Timer comes into the picture. When this timer is active, the active call gets disconnected when it reaches the maximum time of an active call.

Re-Invite¶

   sequenceDiagram
   autonumber
   Alice->>Bob: INVITE (cseq 1)
    Bob-->>Alice: 100 Trying
    Bob->>Charlie: INVITE (cseq 1)
    Charlie-->>Bob: 100 Trying
    Charlie-->>Bob: 180 Ringing
    Bob-->>Alice: 180 Ringing
    Charlie->>Bob: 200 OK (Connected)
    Bob->>Alice: 200 OK (Connected)
    Alice->>Bob: ACK
    Bob->>Charlie: ACK
    Note over Alice,Charlie: The call is active
    Bob->>Alice: REINVITE
    Alice->>Bob: 200 OK
    Bob->>Charlie: REINVITE
    Charlie->>Bob: 200 OK
    Note over Alice,Charlie: Call Disconnects
    Charlie->>Bob: BYE
    Bob->>Alice: BYE
    Alice->>Bob: 200 OK
    Bob->>Charlie: 200 OK

In case of a Re-Invite, it re-establishes an entire call.

Here, Alice starts a call with Bob, the call is active without any issues and the media is through UK. But as a provider we detect the call isn't going through UK. Thus, we send the Re-Invite to Alice to send the media through us and we can place the call on a different server in real-time and in the middle of the call. Thus, a Re-Invite can contain some extra information also.

SIP Session Timers¶

The SIP Session Timer feature adds the capability to periodically refresh SIP sessions. It sends repeated INVITE or RE-Invite requests.

To enable UAs or proxies to determine the state of a SIP session, these requests get issued across active call legs.

Session timers and Session refresh requests work together. They control whether active sessions remain active and completed sessions get terminated.

Then check Supported: timers. It means the customer has this functionality, but that doesn't necessarily mean it's enabled.

You can also check the minimum session interval allowed by Min-SE: 300.

You can check Session expiration using Session-Expires: 1800. At half the session's expiration time, it will send a REINVITE.

Suppose ConnexCS has a customer who sends traffic and they have Supported: timers, but actually, they don't support timers. So as soon as they receive a Re-Invite their system breaks. On behalf of the customers ConnexCS can reply that if it sees an invite from the upstream, it should get absorbed by the server and reply with a 200 OK. The Intercept Re-Invite feature can help achieve this issue.

To ignore the system breakdown due to Supported: timers ConnexCS can use another feature Remove Timers.

Remove Timers will inform the destination that this customer doesn't support the SIP Session Timer.

If the Customer supports the timers but Supported: timers aren't visible.

If the Customer supports the timers, but Supported: timers isn't visible; ConnexCS can add Supported: timers and the headers Min-SE: 300, Session-Expires: 1800 on customer's behalf.