SIP call flow diagrams

We have been working on ways to help us help customers debug SIP issues. SIP (Session Initiation Protocol) is what commonly is used for VoIP (Voice over IP). All of our VoIP services use SIP.

One of the challenges is training the staff to understand SIP properly. Following a SIP trace can be a tricky at the best of times. Some tools like wireshark do a good job as showing the call flow for a SIP call from a packet dump. But we needed something more generic that allowed us to look at SIP messages we capture for diagnostics and made it simple for staff to help a customer.

The real trick is presenting an overview of the whole call flow. We finally managed to get something pretty neat this week, thanks to some work by my son on the front end, which looks quite good. We have mouse-over to see each SIP message in full.

Here is a screen shot. You'll need to blow it up to see the detail.

Given that this was in fact just one junk call I got this morning, which I answered and told them to go away, it is quite impressive that it involves 8 separate (colour coded) call legs. It also involves 8 devices which we can see (plus many more before the call gets to us and more where it goes on to try calling my mobile). In this instance the call tried two SNOM phones and a SIP2SIM connection, and set up call recording in two separate places (one as part of the A&A service, and one on our call server in the office). Just getting the system to work out what packets are related to the overall call flow is a challenge in the first place!

I think this sort of thing will help staff understand SIP much more clearly and understand what is happening when customers have SIP related issues.

P.S. before you ask, no, this call flow trace is not available to customers - managing security on collecting and showing traces is proving to be a bit of a challenge as a call normally involves at least two separate parties and could involve many more. And no, we have not had a data retention notice so won't be storing these traces for any length of time - they are for diagnostics only

Explaining the diagram:-

The red on the left is the incoming call from an external call server for a call from the PSTN to B.voiceless. You can see the normal sequence of INVITE, 100 Trying, 180 Ringing, 200 OK, ACK to establish the call, and then BYE and 200 OK where the call was finally hung up.

The next part is b.voiceless passing that call to boxless. Here you see that it tries, and gets 401, so tries again with authentication details. The rest follows the same pattern with 180, 200, ACK, then BYE and 200.

From boxless it gets interesting. The yellow is a call to a SNOM at the office. It has INVITE, 100 Trying, 180 Ringing (repeatedly), but finally when answered on another phone is sent a CANCEL and gets 200 OK to that, so sends a 487 Request Terminated and gets an ACK to that.

The green call from boxless is just the same, but to a SNOM phone at home, except this goes 180 ringing and then 200 Ok, with ACK. That is where I answer the phone. Eventually there is a BYE and 200, showing I hung up the call from that phone. It is the 200 Ok on this call that prompts the CANCEL on the two other calls (yellow and blue).

The blue call from boxless is a call out to my mobile handled by A.voiceless that passes the call on to an external gateway (orange call). Both of these only get as far as 100 Trying, before there is a CANCEL because I have answered the call on another phone. This is because the mobile network takes time to start ringing, and I answered before the call got that far.

The light grey call from b.voiceless to noiseless is the call recording leg for the incoming call to the original number. Similarly, boxless also does recording and that causes the purple call to noiseless. Note, they were not the same noiseless - we have shown the calls based on known names where possible to simplify, but the call leg summary (not shown) and mouse-over text make it clear that we actually used two different recording servers in this case as noiseless is a pool of machines.

It is the BYE from my SNOM at home (the green call) that prompts the BYE back to b.voiceless and then on to the caller as well as the BYE to the call recording servers (noiseless).

Did you spot the error?