Consult transfer dropping

[Yort Mantup]

Having an issue with one of our sites (90) total where all sites use a centralized sip service at our corporate office (also where CUCM's reside).  All of the sites are connected by a VPN Internet Connection back to corporate.  The one site's issue is when the office staff takes a call from the PSTN and attempts to do a consult transfer to another desk phone, the call is dropping on the caller side (other sites do not have this issue). They are able to do a normal transfer with no issues. The second part of the issue is one member of the office staff takes a call and another call comes in on the hunt group, it rings and when answered, no one is there and call is dropped.

There are two office members that take calls from parents. They are part of a hunt group.  All 90 sites are a standard setup so unsure what the cause is.  Does a consult transfer require MTP resources?  I believe a regular transfer does not.

Thanks

[Yitzakh Stine]

If this is a localized issue (i.e. it's only happening at the one site) I would check and ensure there are no major discrepancies between the basic settings and configurations at this site and the others. However, I'm assuming you've already done this?

Also, when you say the call is dropping on caller side, do you mean PSTN side? Or Transfer pilot? I don't believe MTP resources would be necessary for this situation.

[Yort Mantup]

Thank you for the reply.  Yes, this site is the only one having this issue.  

Call Example

PSTN Call - answered by phone A - transfer to phone b --> talk to person at phone b --> transfer (the caller is no longer there, dropped).

But normal transfer works fine  Answer - Transfer to phone b - Transfer.  

I know in the transfer process when the transfer is pressed it will put the calling party on hold and create a new call leg.  In a consult transfer, is second call leg created and is this where it's failing?  If that is correct, I am unsure what to troubleshoot for that piece. 

[Adam Pawlowski]

I think when you do this, you are triggering media changes and re-invite. When I had this type of trouble recently, this was also reproducible with ad-hoc conferencing. It wasn't a problem with the architecture in our case. Here, if the original call agent invites media to phone B and there is no media pathway you'd get dead air, the call shouldn't just disappear. For us it ended up being some ALG on a firewall that decided it would be on, and it was re-writing SDP information improperly. We turned that off and the problem went away. I would see if you can debug or monitor the SIP transaction, where you should be able to see what is going on. The call could drop as well for lack of resourcing if there's some lack of transcoder or otherwise but you should be notified by monitoring if this happens.

[Yort Mantup]

Thank you for the reply.  Can I ask what type of FW you are using?  We swapped out all Cisco ASA's last year for Palo Alto's and this issue surfaced but only for this site and another (out of 90) sites.  The configuration is pretty much a cookie cutter template for all schools and we have combed thru the configs looking for an anomaly.   We are taking packet captures later today.