ICM scripting

[sirf02]

Hi,

i have the following requirement. Appreciate your thoughts.

I need to be able to transfer my queued calls to 3rd party destination outside Cisco platform. I am on  UCCE 11.6, CUBE and COLT being the SP.

When I use a label node in ICM scripting and transfer this call to 3rd party number once my local queue is full, if the other party is busy, the call fails through the wrong node of label node which is expected. But the problem is, it takes 30 secs after which the call fails to wrong node.

On analysis, it was noted that COLT has this delay of sending back  busy signal after 30 secs to ICM and i am told this 30 secs is the standard norm.

on the other hand, when i call this 3rd party number through my mobile I get busy tone instantly if its busy.

Question is - I need to be able to do supervised 3rd party call transfer from ICM using label node meaning if 3rd party is busy I should fail to wrong node of label node instantly so that I can transfer this call to other queue. I need to be able to check - if 3rd party number is busy dont transfer call and select next target.

Or

play some music till the time I get a response through wrong node of label node.

is this possible?

can divert label help here instead of label node?

thanks -Syed

[sirf02]

Any thoughts guys?

[bill.king1]

This may not be the recommended way to do this, but as a test, what happens if you change the time out for that label in CVP Ops Console?

So in other words, if the label you're sending to is 18005551212, create a specific dialed number pattern rule in CVP OAMP for that and make the timeout be short, like 5 seconds.

See if your call not goes out the failure leg after 5 seconds.

Again, unconventional and not sure it will work, but that's how I would test as a start.

[sirf02]

Not sure how will this timeout help get the busy tone from SP while SP is holding it for 30 secs and sending back 486 busy after 30 secs to label node. Then my label node fails through wrong node.

can a music be played in ICM while label node is waiting for 30 secs to get back busy tone from SP? currently there is silence of 30 secs while the label node is waiting for busy tone!

[bill.king1]

I'm saying the timeout will potentially be quicker if it is failing out the failure node after 5 seconds. Have you tried it to see if it is the service provider vs. CVP OAMP which is dictating that 30 seconds? If it works with 5 seconds, you could even potentially reduce it to say 2 to see if that is a more seamless transfer for you. But try it with something like 5 first to see if it makes any difference in the situation you're experiencing.

[sirf02]

SP has confirmed that 30 secs delay is from their end and its their standard norm hence was wondering how will CVP timeout will help me get rid of this delay!

[ptindall]

You don't actually say what the voice interface type is to the service provider.   This sounds like ISDN behaviour with the egress gateway honouring pi 8 in the disconnect so the caller can hear the inband tone/message.

[sirf02]

its a SIP trunk from CUBE to SP.

[ptindall]

Do you have a trace of the SIP messaging for a test call?

[sirf02]

I dont have a trace from CUBE but have a response from SP. below is the response.

The delay in relaying 486-Busy here is due to the “disconnect treatment” set on trunk which provides tones according to the release cause for example user busy, unallocated number etc with the set duration of 30sec i.e. happening here. However here due to delayed offer no tone was provided.

As suggested, we can change the “disconnect treatment” to default which will relay the signaling messages as per the response from Egress carrier.

[ptindall]

To me, that sounds like good news.   Doesn't the service provider changing the disconnect treatment to immediately relaying the disconnect give you the solution you need?

[sirf02]

like said in my initial post, 30 secs is their standard as per design, below is the response from SP.

"This is per design that COLT holds signaling for 30 seconds to allow time for voice message indicating unreachability to reach the origin"

can we play some music in ICM until(in our case 30 secs) we get a busy back from SP.

[ptindall]

Clearly, I'm not understanding something in the SP's response but it reads like they're suggesting changing their messaging to remove the delay -- "we can change the “disconnect treatment” to default which will relay the signaling messages as per the response from Egress carrier."

Regarding the ICM question, the only control you have on the media to the caller during a transfer is the CVP custom ringtone setting.  You could try that.

[sirf02]

well, not sure why SP should introduce delay. I always thought, when someone is busy I should be able to hear busy instantly regardless me calling external number using my mobile or through the system (ip phone or label node)

interestingly when i call external number through my mobile I hear back busy instantly.

when i call using ip phone/label node there is a delay of 30 secs and SP has agreed they have setup 30 secs as per design.

are all SPs doing the same like setting up 30 or few secs before sending back busy tone????

on the CVP custom ring tone,
does it play custom ring tone while I wait in the lablel node for 30 secs?

[ptindall]

When the CVP Call Server transfers a call, CVP will apply either its default ringback or the defined custom media while the transfer leg is being established until it is answered, rejected or the CVP no answer timeout expires.

The 30s delay on disconnection is a bit of a legacy thing to accommodate network announcements back to the caller, something that  was especially relevant when phones were analogue, had zero intelligence and couldn't display anything.  In band messages were the only way to provide call outcome/failure info.   To achieve that in ISDN the incoming disconnect would indicate the presence of inband information (using pi=8) and the IOS gateway could be configured to either delay the outgoing release for 30s until the caller had heard the message or ignore PI on disconnect and send the release immediately without the caller getting chance to hear the network announcement or progress tone.

With your SIP example, the 183 with early media is what opens the media path for the inband announcement / tone.  The SP is presumably delaying the call reject / busy to achieve the same as described above but they should be able to configure the trunk to send the 486 immediately as it doesn't make any sense when there's no human listening.  In CVP there is a property to cause proxying of the 183 back to the caller leg but that wouldn't help you to disconnect immediately; it would only affect what the caller hears from the far end.  I'm not aware on anything in IOS that would allow you to achieve the same as in the ISDN case as the 30s delay is applied by the SP your case and not (optionally) by the IOS voice gateway.