Transfer or transferred call drops with 481

[ciosys]

When a outside call is answered at the front desk and then transfered to Phone2, if Phone2 tries to transer to Phone3 the call is disconected with a 481 error message.  They are using version 4.4.2.6875

The  front desk phone is a Polycom IP-670 and the Phone2 is a Snom 300 andf Phone3 is a Snom 360.  I have attaced a trace file.

Thanks

Bob

[Anonymous]

ciosys,

Can you explain this call flow in more detail including extensions?  For example an inbound call from xxx-xxx-xxxx gets sent to extension  xxxx on an ECS, then is blind transferred to extension yyyy, the call is placed on hold and then finally assisted transferred to extension zzzz.  Is this is an ECS (10.0.17.10 ) setup using an Ingate (10.0.17.11)?  Please confirm that and also include any other devices the calls flow through with their IPs.  At a high level it looks like the problem may be the Polycom receives an INVITE with “replaces” containing a call-ID the Polycom does not know about, but we will need a much better grasp on the entire call flow and all the parties involved to be sure. If you are sensitive to external phone numbers being available in this post you will need to remove your previous attachment or let me know so I can remove it.

Thanks,
Matt

[ciosys]

Please block the phone numbers

the outside phone is xxx-xxx-xxxx

the client phone number is yyy-yyy-yyyy

Receptionist 1002 00-04-F2-1C-E2-F9 10.0.17.124 (polychom)

Phone1 180 00.04.13.28.B3.CD 10.0.17.116 (snom 300)

Phone2 1012 00.04.13.28.B3.C7 10.0.17.104 (SNOME 300)

Is this is an ECS (10.0.17.10 ) setup using an Ingate (10.0.17.11)? Yes

The Polychom is new and replaced a Snom that was having issue with combining multiple calls instead of sending one

Hope this helps

Bob

Message was edited by: matt - removed phone numbers and attachment

[Anonymous]

Ciosys,

Some of the phone numbers and IP addresses supplied did not match up with the PCAP.  When following the PCAP one thing that sticks out is the fact that the Polycom (x1002) had a call up to the external number already before the new call came in. For us to move forward with this you would need to get a new PCAP of this situation when all phones are in an idle state.  If you can collect that and then upload it to our public FTP server by following the instructions below I would be happy to look further into it.  Please note I will need to know the exact file name of the PCAP after you upload it to our FTP server so I can retrieve it.

Open Internet Explorer web browser
Type the following URL:  ftp://ftp.adtran.com
Double-click the "Incoming" folder
Drag and drop files from PC into the Internet Explorer window

Thanks,
Matt

[ciosys]

Just uploaded the files

Thanks

Bob

Message was edited by: matt - removed personal contact information

[Anonymous]

Bob,

Can you reply with the file names?  I will need those to retrieve the files.  Also, when responding via e-mail make sure to delete your signature so your personal contact information is not posted.  I removed it all from your last message.

Thanks,
Matt

[ciosys]

I used the email address as the file name. Should have mentioned that

Message was edited by: matt - removed personal contact information

[Anonymous]

Bob,

This capture did not appear to contain any complete VoIP call flows.  Can you collect another and re-upload it to the FTP server?  All the phones need to be in an IDLE state, then start the capture, recreate the issue, hang up all the calls, stop the capture, and upload the file.  It is critical that the capture be started before the first call comes in.  If you change the call flow with different extensions or anything else I will need you to detail each step of the call flow so I can follow it.

Thanks,
Matt

[ciosys]

<file-name> call failed

here it is, thank you for your patience

[Anonymous · Accepted solution]

Bob,

Attached is a diagram of the call flow and the exact problem in the packet capture. I highlighted the issue with a red rectangle in both attachments. 

The call flow is very long, but this generic breakdown can help you follow it.  One thing to note is the DID you were calling to create this issue is routed to x100, which then points to x1002.  That is not an issue, but helps someone going through the call flow.

• Ingate INVITEs ECS <external caller> to <DID>
• ECS REFERs Ingate to x100
• Ingate INVITEs ECS <external caller> to x100
• ECS INVITEs <external caller> to x1002 (Polycom 670 - 10.0.17.130)
• x1002 puts <external caller> on hold
• x1002 INVITEs x180 (10.0.17.116 - SNOM 300)
• x1002 REFERs <external caller> to x180
• Ingate INVITEs <external caller> to x180
• ECS INVITEs <external caller> to x180
• x180 puts <external caller> on hold
• x180 REFERs <external caller> to x102
• Ingate INVITEs with Replaces <external caller> to x102
• ECS INVITEs <external caller> to x102 (10.0.17.108)
• x102 sends SIP 481

The problem appears to be that the INVITE the Ingate sends in frame 747 of the packet capture contains a Replaces header and it should not.  The Replaces header contains a Call-ID that x102 does not know about so it replies back to the INVITE with a SIP 481 Call Leg/Transaction Does Not Exist causing the issue you are seeing.

To remedy this issue I would suggest you contact Ingate, provide them with the packet capture, and this explanation.

Thanks,
Matt

[ciosys]

Thank you for your assistance, I will contact Ingate

Message was edited by: matt - removed personal contact information

[Anonymous]

I went ahead and flagged this post as “Assumed Answered.”  If any of the responses on this thread assisted you, please mark them as either Correct or Helpful answers with the applicable buttons.  This will make them visible and help other members of the community find solutions more easily.  If you still need assistance, I would be more than happy to continue working with you on this - just let me know in a reply.

Thanks,

Matt