Most of the time it' the verbose nature of the systems to perform a handoff. I.e., They are chatty!
There are two methods to reduce the chatter that I know of: 1) On the CUBE the command mid-call signlaing passthru media-change (spellcheck?) 2) On the CUCM a service param called Duplex Streaming Enabled set to True Maybe others know of more. Anyway, if neither of these commands reduce the delay, you would need to look at a ladder diagram of the end-to-end (which is why sip end-to-end is nice) signaling to see where the delay comes from. On Fri, Aug 14, 2020 at 8:16 AM f...@browardcommunications.com < f...@browardcommunications.com> wrote: > Hello, thanks again for the help, a combination of Diversion and PAI is > finally what let the call go through with ATT, so that is working now. > Issue now is, there is a very long delay between the time the caller > selects the option, and the call actually gets routed, any thoughts on what > would cause this delay? > Thank you. > > > > > Sent from my iPhone > > On Jul 30, 2020, at 4:41 PM, Anthony Holloway < > avholloway+cisco-v...@gmail.com> wrote: > > Midcall signaling wont help the calling number issue. The link I posted > has examples. > > On Thu, Jul 30, 2020 at 3:29 PM f...@browardcommunications.com < > f...@browardcommunications.com> wrote: > >> Thank you. >> So, it looks like I have 3 options: >> - Set the midcall signaling, which I am trying tonight >> >> - setting the sip trunk on calling party selection to “last redirect >> number” >> And reset >> >> - then if all else fails I will try the sip profile. >> >> Do you have an example sip profile / dial-peer config handy? >> >> Thank you much! >> >> >> >> Sent from my iPhone >> >> On Jul 30, 2020, at 3:46 PM, Anthony Holloway < >> avholloway+cisco-v...@gmail.com> wrote: >> >> If your assessment is correct about the calling number, the carrier will >> see the original or outside caller's phone number in the From field and >> reject your call. I see this being solved most of the time with a SIP >> Profile on the outgoing dial-peer, which adds either a Diversion header or >> a P-Asserted-Identity header. >> >> E.g., >> >> https://community.cisco.com/t5/collaboration-voice-and-video/configure-and-troubleshoot-call-forward-to-the-pstn-using-sip/ta-p/3118287 >> >> On Wed, Jul 29, 2020 at 6:45 AM f...@browardcommunications.com < >> f...@browardcommunications.com> wrote: >> >>> >>> Greetings all, this might be simple fix, I just haven’t dealt with this >>> in a while. >>> >>> We have a unity AA that, when external callers call, select menu >>> options, etc. Unity will send the call back to. CtiRp, which then CFA to an >>> external number. You hear the Unity transfer message, 1 second of MoH, then >>> 10 seconds of nothing, then the call drops. >>> >>> Internal calls to the CFA ctirp works >>> >>> Internal calls to the unity ctirp then back to the CFA ctirp works. >>> >>> I tried having unity call the pstn number directly with same results >>> >>> I think the issue is with the calling number is why the carrier is >>> sending the 603, but it is next to impossible to get them to tell us that. >>> >>> Call flow: >>> Pstn>sipt>cucm >unity>cucm>ctirp-CFA-pstn >>> >>> Where would I change the calling number being CFA’ed from Unity to the >>> PSTN? >>> >>> Any ideas? >>> >>> Thank you. >>> >>> /FW >>> >>> Sent from my iPhone >>> _______________________________________________ >>> cisco-voip mailing list >>> cisco-voip@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/cisco-voip >>> >>
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip