[cisco-voip] Audio cut-through delays upon transfer

[Anthony Holloway]

Interesting.  I had to set that setting for the first time ever, when I
enabled the new Conference Now IVR in CUCM.  I'd never heard of that
parameter before then.  What are the side affects or negatives with using
this param?  Or can we just turn it on all the time as best practice, like
one might do with OPTIONS PING or Run on All Nodes.*

*I realize some speific situations call for other-than-best-practice
configuration.  YMMV.

On Thu, Jan 12, 2017 at 1:35 PM Pavan Dave (pavdave) <pavdave at cisco.com>
wrote:

> To piggy back on this, if you are going to be in situations where calls
> are going on and off hold and transferring,  setting duplex streaming to
> “True” on CUCM will also help.
>
> *Note *[image: http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gif]To
> prevent the SDP mode from being set to inactive in a multiple-hold
> scenario, set the Duplex Streaming Enabled clusterwide service parameter (*System
> > Service Parameters*) to *True*.
>
>
> http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/8_5_1/ccmsys/accm-851-cm/a08trnk.html#wp1149990
> (Step 10 under Table 41-1)
>
> Regards,
>
> Pavan Davé
>
> Contact Center TAC Engineer
>
> Cisco Systems – Richardson, TX, USA
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On Behalf
> Of *Anthony Holloway
> *Sent:* Thursday, January 12, 2017 12:51 PM
> *To:* Dana Tong <dana.tong at yellit.com.au>; cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] Audio cut-through delays upon transfer
>
>
>
> This sounds like the old
> too-many-messages-are-required-to-make-the-transfer-happen scenario.  Ok, I
> just made up that name, but basically the SIP messages are just busy doing
> whatever SIP messages do, to make the transfer happen.  From stopping
> media, to invoke MOH, to tearing down MOH, to transferring, to establishing
> media, it's just a lot, and takes a long time.
>
>
>
> You can cut down on the amount of messages in a few ways, but the one I
> see used most often is the command on the CUBE:
>
>
>
> voice service voip
>
>  sip
>
>   mid-call signaling passthru media-change
>
> !
>
>
>
> You can read more about it here:
>
>
> http://www.cisco.com/en/US/docs/ios-xml/ios/voice/cube_proto/configuration/15-2mt/cube-midcall-reinvite.html
>
>
>
> On Wed, Jan 11, 2017 at 10:00 PM Dana Tong <dana.tong at yellit.com.au>
> wrote:
>
> Hi all,
>
>
>
> I have a customer who is reporting a (one-way) audio delay after
> transferring calls with Cisco Jabber. They are almost all soft-phone users.
>
> There doesn’t appear to be any delays in the signalling.
>
>
>
> I’ve just asked them to clarify if this is for all calls or just external
> calls. PSTN access is via CUBE which is configured for early offer.
>
> When I tested I couldn’t see a problem but the customer insists that there
> is a delay for media being transmitted to the person who receives the
> transferred call.
>
>
>
> Has anyone seen this before at all?
>
>
>
> Cheers
>
> Dana
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170112/ac987a58/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 167 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170112/ac987a58/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 167 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170112/ac987a58/attachment-0001.png>