Why redirection of VoIP calls to voicemail fails?

edit

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.

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 !