Call transfer - one way audio

[noside12000]

Hello,

We've been struggling for this for the past few days now and I do hope someone can provide any suggestions on going about this one. When when our agents receive a call via queue on a sip trunk and does a warm transfer to an external number via sip trunk, the moment the agent does the transfer, it'll be a one way audio on the party welcoming the transferred call.
Already checked the trunk to trunk transfer on system features and disconnect supervision on the trunk and set to yes for both.

Thank you.

 

[kyle555]

What's the SDP look like in the flow? Sounds like something is getting tripped up in send-only.

SIP loves that. Cutting off half a stream if unnecessary by re-inviting with a media attribute of send-only. Like if you pressed a hold key and sent your original caller to a gateway for music, CM's reinvite to the party being held would say send-only.

Depending on how you're transfer flows are juggled around and what the SDP flows look like, I'd suspect that.

 

[noside12000]

Thank you for the feedback, is there something to look at the SDP message to know what you're referring to?

 

[kyle555]

a=send-only or recv-only.

Like if I hammered the hold key, you'd see me reinvite you with "send-only". That means I ain't listening to you, I'm just sending hold music. When I unhold, I send SDP with either send/recv or not specifying sending or receiving at all (that's interpreted as 2 way audio).

 

[noside12000]

Thanks for Tht insight. I've the sdp message and all were a=sendreceiv

 

[noside12000]

Anything to look at the TG settings? Thank you guys

 

[kyle555]

Were all the c= lines consistent? I'd think for the original caller, it'd always be c= B1 IP of SBC on the outside and...what on the inside? A1? G450?

If you can reproduce it at will, packet capture on A1 and B1, see if both legs of audio are getting to you. I can tell you on my carrier SIP trunks that behind the scenes (you'd never see it) that between different elements we could have gone send only and messaging to you may always be sendrecv. You can test that out by trying a hold/unhold once the one way call is setup.

That, or the SBC/CM/SM are mungling it up somewhere and not shuffling and pinning down on a G450 would fix it.

If you do the transfer warm - as in, outsider calls avaya phone, conference/transfer, dial external party, avaya phone introduces outsider to destination, do all 3 talk nice while a G450 is connecting all 3 legs together?

 

[noside12000]

Hi Kyle,

C= seems to be persistent with the IP of DSP resource, in my case, it's the G450 media gateway.

Does anyone know this field on the signaling group page?

H.323 Station Outgoing Direct Media? = currently set to N

Many thanks.

 

[kyle555]

That field has caused problems in certain scenarios. My case was at Y, calls out a IP trunk, to another system with the same carrier, with a misconfigured Nuance Speech Reco system wouldn't work. send/recv send-only stuff getting jumbly. Having that at N, or using SIP phones couldn't reproduce the problem.

The options will, when CM sends a SIP invite out for a call a h323 station made, put in the c=line the IP of the H323 phone. If disabled, it'll offer a DSP in the c=line. Once the call is answered, if it can shuffle, CM will reinvite with the c=line of the H323 phone. If you pick yes, you can save a SDP exchange to shuffle.

Careful though, you're looking at 2 call legs. Original caller in, and conference/xfer leg out. The first leg, once the user presses conference, will always get a reinvite with SDP to the G450 for hold. If you get a traceSBC going and hit 'd', you'll get a table of calls. You'd probably have 4. Outsider to B1, outisder A1-->SM/CM and the same for the xfer out leg. Having the trace tool only show per call is nice to preserve your sanity.