Static on VOIP handsets during transfer & Duplicate invites

Question

Can anyone with experience assist me with the following capture that I took from two VOIP handsets transferring a call to a SIP desk phone. What is the recommended next step for troubleshooting after receiving the data below? I don't have a ton of experience with VOIP so I'm uncertain.

RTP Stream Analysis

Max delta = 1798.95 ms at packet no. 30095 
Max jitter = 877.89 ms. Mean jitter = 314.40 ms.
Max skew = -1825.33 ms.
Total RTP packets = 656   (expected 656)   Lost RTP packets = -652 (-99.39%)   Sequence errors = 652 
Duration 13.08 s (-2560 ms clock drift, corresponding to 6435 Hz (-19.57%)

VOIP CALL FLOW

Invite SDP (g711)--->
Invite SDP (g711)--->
Invite SDP (g711)--->
Invite SDP (g711)--->
<----100 Trying
<----407 Proxy Auth
<----100 Trying
<----407 Proxy Auth
<----100 Trying
<----407 Proxy Auth
<----100 Trying
<----407 Proxy Auth
ACK---->
ACK---->
ACK---->
ACK---->
Invite SDP (g711)--->
Invite SDP (g711)--->
<---100 Trying
<---100 Trying
Invite SDP (g711)--->
Invite SDP (g711)--->
<---100 Trying
<---100 Trying
<---180 Ringing
<---180 Ringing
<---180 Ringing
<---180 Ringing
<---200 OK SDP (g711)
<---200 OK SDP (g711)
<---200 OK SDP (g711)
<----RTP(g711U)
<----RTP(g711U)
ACK---->
ACK---->
ACK---->
ACK---->
RTP(g711U)---->
RTP(g711U)---->
<---REFER
<---REFER
<---REFER
<---REFER
202 Accepted---->
202 Accepted---->
202 Accepted---->
202 Accepted---->
NOTIFY---->
NOTIFY---->
NOTIFY---->
NOTIFY---->
BYE---->
BYE---->
BYE---->
BYE---->
<----407 Proxy Auth
<----407 Proxy Auth
<----407 Proxy Auth
<----407 Proxy Auth
BYE---->
BYE---->
BYE---->
BYE---->
<----200 OK
<----200 OK
<----200 OK
<----200 OK
<----200 OK
<----200 OK
<----200 OK
<----200 OK

Why are there so many repeated invites, etc. above? Everything is duplicated and I'm not sure if this is normal behavior..and if it it's normal behavior what could be the root cause? I'm leaning towards the assumption that the issue is a network congestion issue?! ...but I'm quite uncertain at this point. Any help would be greatly appreciated..also I can provide additional information if needed. Thank you.

Answer 1

0

Why are there so many repeated invites, etc. above?

One reason could be, that all your frames are duplicated, maybe due to a problem with your capture setup (mirroring traffic of ingress and egress port on the switch) !! Can you please try to capture the frames only once, because the duplicated frames makes troubleshooting harder than it needs to be ;-)) You can try to de-duplicate the capture file with editcap.

Then there are some of the following messages:

Status: 401 Unauthorized
Status: 407 Proxy Authentication Required

which indicates failed authentication and thus a retry.

Regards
Kurt

answered 30 Mar '15, 07:05

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

Kurt, I don't believe that there is any error on my part with the captures.. I believe that there is something within the network that is causing these duplicates. I've used the same process to capture at other locations and my results have never shown duplicates. I've used the same process to make captures today and these captures show no duplicates.. I'm baffled as to why this location is showing duplicates..could this possibly be a symptom of network congestion? Maybe the data is being re transmitted?

(30 Mar '15, 08:06) georgennc

You can see a capture on multiple interfaces, whereby a remote capture and a local interface carry the same traffic. That's the duplication.

(30 Mar '15, 08:09) Jaap ♦

Apply this filter

ip.addr eq 10.7.16.159 and sip

then look at frames #3062 and #3066. They look identical to me, besides the destination mac address AND the IP ID (0000 in 3062). That does not look like a "re-transmission". That looks like packet duplication somewhere.

Furthermore, as @Jaap mentioned, you have also captured all frames twice via remote capture, see frames #3069 and #3077 (duplicates of 3062 and 3066, encapsulated in rpcap).

As a result, you are seeing the same SIP frame 4 times.

Maybe the data is being re transmitted?

No. The frames are simlpy captured several times at different locations, see above...

(30 Mar '15, 08:24) Kurt Knochner ♦

There must have been another interface selected by default when I took my capture. I'll recapture the data and post it in a few hours. Thank you all for your assistance.

(30 Mar '15, 09:06) georgennc

There must have been another interface selected by default when I took my capture.

maybe.

I'll recapture the data and post it in a few hours. Thank you all for your assistance.

I guess, if you're doing the capturing in the right way, there won't be any duplicates and "re-transmissions" any more..

In that case: If a supplied answer resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions. For extra points you can up vote the answer (thumb up).

(30 Mar '15, 09:09) Kurt Knochner ♦

I ensured that only one interface was being captured this time. I don't see nearly as many errors but there was still static on the line during the transfer. Link: https://drive.google.com/file/d/0B6jI0xk_UGx_Y05pTU5HQnZXclk/view?usp=sharing

(30 Mar '15, 11:40) georgennc

I ensured that only one interface was being captured this time.

The SIP frames are still duplicates. See frame #6 and #7 as well as #8 and #9. Same as before. Identical frames, just two differences: IP ID 0000 (#6 and #9) and different mac addresses.

I still believe there is something wrong with the capture setup. Can you please add more details about your capture setup?

Where did you capture (I can see it in the summary, but I want confirmation)
How did you capture (rpcap, switch mirror port, etc.).

(30 Mar '15, 11:47) Kurt Knochner ♦

showing 5 of 7 show 2 more comments