# Why redirection of VoIP calls to voicemail fails?

Hello, I'm in the VoIP field, and I am having an issue deciphering why I am not able to complete a call to voicemail. I have 2 phone systems tied together via a PRI, and I have a PRI for trunking to the outside world. ShoreTel is the VoIP system, and its also acting at the voicemail system for both Phone systems. Other system is a Tadiran TDM system. What is happening is, if I call from the outside world via cell phone or desk phone, into the ShoreTel and it then transfer to a Tadiran phone via the Tie PRI trunks, it rings 4 times, and instead of being transferred to the Voicemail on the ShoreTel, the call just ends. I have packet capture from the ShoreTel PRI that plugs into the Carrier, and a capture from the other ShoreTel PRI that plugs into the Tadiran. I see a lot of ICMP Destination Unreachable (Port Unreachable) messages, along with what look to be some UDP error messages. The 2 ShoreTel switches are on the same subnet, so there isn't any routing between them, they are plugged into the same network switch, and I can ping back and forth between the 2 ShoreTel PRI Switches. I was hoping someone would be able to look at my captures and help me figure out what is going on. This is for a big college, and they would really like their voicemail working. Thank you

Thank you everyone. Sindy, here are 2 links to the captures. First link is a Capture from the ShoreTel PRI switch that is connected to the carriers circuit, and the second link is a capture from the ShoreTel PRI switch that is connected to the Tadiran phone system. https://www.cloudshark.org/captures/5... https://www.cloudshark.org/captures/6...

edit retag close merge delete

So what's the Wireshark question here? You've seen the ICMP Destination (Port) Unreachable messages so someone is sending traffic where no one is listening. Sounds like a configuration or signalling error which support for either VoIP system should be able to clear up.

( 2017-10-31 06:42:23 +0000 )edit

Who is the source of the ICMP message? That server/router is telling you that the SIP/RTP message is not getting through because no one is listening to the port. But since the phone rang, SIP must be working and the RTP traffic carrying the voice is not working. So concentrate on the source IP.

( 2017-10-31 13:28:38 +0000 )edit

The ICMP port unreachable messages should indicate what was the destination IP and UDP port that was attempted to be contacted (you probably also captured the actual UDP packets that triggered this). I would presume that the service it is trying to contact is either down or the redirection is somehow incorrectly configured.

( 2017-11-02 05:15:22 +0000 )edit

You haven't said anything about the amount of voice traffic on the gateways while you were taking the capture. The icmp destination unreachable might as well be a red herring and it might be coming only temporarily, whenever one of the VoIP ends was still sending RTP while the other one had already stopped expecting it. This sounds odd on the same LAN but is not completely excluded.

So if you want a deeper look, publish your capture, login-free, at cloudshark or at any common file sharing service and edit your question with a link to it, and indicate the calling and called number of the call in question.

Now where is the redirect to voicemail configured? I assume that it is on the Tadiran TDM system, so the issue may as well be caused by what the Tadiran does after the no answer timer expires - it may send ...(more)

( 2017-11-02 19:27:15 +0000 )edit

Sort by » oldest newest most voted

Bad news only. Use Statistisc->I/O graph, set the time interval to 100 ms, and create three graphs with different colours, Y values in packets and the following display filters:

• tcp.port == 1026
• rtp
• icmp

Don't forget to activate the three graphs after defining them (using the checkbox in the leftmost column).

The graphs will show you that

• there were two call attempts while you were capturing; using Wireshark's RTP player you'll find that the longer one of them was the one of interest which should have been redirected after the No Answer timer has expired
• the icmp packets are there almost all the time because one of the shoretel boxes sends empty (zero payload length) UDP packets from its single port to monotonously increasing destination port numbers on the other shoretel box, but this port scanning activity disappears long before the wannabe redirected call ends, so I cannot imagine how the two would be related.

What is much worse is that the ShoreTel boxes talk to each other using some proprietary, binary-encoded protocol which Wireshark cannot dissect (the only information available in plaintext are SIP URIs and a few other pieces of information). So there is no easy way to find out what happens at signalling level when the No Answer timer on the Tadiran box expires.

Reverse-engineering of the Shoretel protocol might be the only possible way to understand what's going on without involving Shoretel support into the case, which may or may not be worth the result.

Plus you haven't stated cleanly which of the two Shoretel boxes hosts the voicemail accounts - if it is the one connected to Tadiran, there is no reason why it should inform the other one about an attempt to redirect the call to the voice mail even if it would take that attempt.

Update: more careful reading shows the following in the signalling flow from the PSTN - side Shoretel to the Tadiran-side one:

ACC_Queen-SGT1k-03.UA:
(++TGrp_4,p2++) ua_unexpected_cmd - 23:FUNC_ss_lg_refer
CALL ID = 0070000000b59cbc2cb0010494ee0b3,
leg_id_str = 01000013:172.16.240.253:R, leg state = 11:LEG_STATE_ACTIVE 18:eReason_BlindTransfer


immediately followed by

ACC_Queen-SGT1k-03.UA:  (++TGrp_4,p2++)  BYE, Reason = 85
CALL-ID - 0070000000b59cbc2cb0010494ee0b3, call_handle = 0x010005cf
LEG-ID - 01000013:172.16.240.253:R, leg_state = 11, leg_handle =0x010005d0


So it looks like the Tadiran has asked for transfer of the call to the voicemail but the calling Shoretel was unable to handle the request for some reason. As no SIP uri was present in the signalling flow in the opposite direction, I would wonder how the PSTN-side Shoretel should know which voicemail account to use, but I can imagine it can know that implicitly.

more

The message 'Destination Unreachable (Port unreachable)' is easy to understand:

• The destination is alive but the port you want to reach them on is closed on their end.

It often happens with SNMP, when the server polls a client device, if SNMP is not opened on the client.

Just make sure of the port you need to reach on the destination is opened there. It may not solved your phone / VM issue but you'll get rid of the icmp port unreachable for sure !

more