One way audio for transfered calls

[ejvl]

Hi,

One of our customers use a Midsize Enterprise 6.2.0.0.3105, CM 06.2-02.0.
All works fine, but there is one problem.
When the customer received a call, and want to transfer to a mobile phone, or other number, mobile phone is ringing, mobile phone answered, the caller hear for one second audio and then silence…
The mobile phone hear the caller, but the caller didn’t hear the mobile phone.
The CM connect to the Session Manager, tot the Session Border Controller, to the SIP provider.
The SIP provider says that the conversation is in Sendonly and not in send and receive, but I can’t find anything about that.
When the customer calls directly to a mobile phone there is no problem, but when the customer did a transfer, there is a problem with one way audio…
Any idea where to look?

Signalling group:
Group Number: 3 Group Type: sip
IMS Enabled? n Transport Method: tcp
Q-SIP? n
IP Video? y Priority Video? y Enforce SIPS URI for SRTP? y
Peer Detection Enabled? n Peer Server: SM



Near-end Node Name: procr Far-end Node Name: SM
Near-end Listen Port: 5060 Far-end Listen Port: 5060
Far-end Network Region: 1

Far-end Domain:
Bypass If IP Threshold Exceeded? n
Incoming Dialog Loopbacks: allow RFC 3389 Comfort Noise? n
DTMF over IP: rtp-payload Direct IP-IP Audio Connections? n
Session Establishment Timer(min): 3 IP Audio Hairpinning? y
Enable Layer 3 Test? y
Alternate Route Timer(sec): 7

Trace:

09:13:34 active station 3702 cid 0x370c
09:13:34 G711A ssff ps:20
rgn:18 [10.121.254.7]:2482
rgn:18 [10.121.254.221]:2052
09:13:34 dial 0062 route:ARS
09:13:34 term trunk-group 3 cid 0x370c
09:13:34 dial 006xxxxxxxx route:ARS
09:13:34 route-pattern 88 preference 1 location 18/ALL cid 0x370c
09:13:34 seize trunk-group 3 member 208 cid 0x370c
09:13:34 Calling Number & Name NO-CPNumber NO-CPName
09:13:34 SIP>INVITE sip:8806xxxxxxxx9@10.100.0.15 SIP/2.0
09:13:34 Call-ID: 0c621513b11e71abcf5887d6000
09:13:34 Calling Number & Name NO-CPNumber NO-CPName
09:13:34 SIP<SIP/2.0 100 Trying
09:13:34 Call-ID: 0c621513b11e71abcf5887d6000
09:13:34 Proceed trunk-group 3 member 208 cid 0x370c
09:13:35 SIP<SIP/2.0 200 OK
09:13:35 Call-ID: 7FD19CFC-FD8D11E6-BAD7A54F-C48351D@62.140.159.
09:13:35 225
09:13:35 SIP>ACK sip:anonymous@10.100.0.5:5060;transport=tcp SIP/2.0
09:13:35 Call-ID: 7FD19CFC-FD8D11E6-BAD7A54F-C48351D@62.140.159.
09:13:35 225
09:13:35 SIP<SIP/2.0 183 Session Progress
09:13:35 Call-ID: 0c621513b11e71abcf5887d6000
09:13:38 SIP<SIP/2.0 183 Session Progress
09:13:38 Call-ID: 0c621513b11e71abcf5887d6000
09:13:38 G711A ssff ps:20
rgn:1 [10.100.0.6]:35284
rgn:18 [10.121.254.221]:2050
09:13:38 xoip options: fax:T38 modemT ttyff uid:0x500fa
xoip ip: [10.121.254.221]:2050
09:13:38 SIP<SIP/2.0 180 Ringing
09:13:38 Call-ID: 0c621513b11e71abcf5887d6000
09:13:38 Alert trunk-group 3 member 208 cid 0x370c
09:13:35 225
09:13:35 SIP>ACK sip:anonymous@10.100.0.5:5060;transport=tcp SIP/2.0
09:13:35 Call-ID: 7FD19CFC-FD8D11E6-BAD7A54F-C48351D@62.140.159.
09:13:35 225
09:13:35 SIP<SIP/2.0 183 Session Progress
09:13:35 Call-ID: 0c621513b11e71abcf5887d6000
09:13:38 SIP<SIP/2.0 183 Session Progress
09:13:38 Call-ID: 0c621513b11e71abcf5887d6000
09:13:38 G711A ssff ps:20
rgn:1 [10.100.0.6]:35284
rgn:18 [10.121.254.221]:2050
09:13:38 xoip options: fax:T38 modemT ttyff uid:0x500fa
xoip ip: [10.121.254.221]:2050
09:13:38 SIP<SIP/2.0 180 Ringing
09:13:38 Call-ID: 0c621513b11e71abcf5887d6000
09:13:38 Alert trunk-group 3 member 208 cid 0x370c
09:13:35 225
09:13:35 SIP>ACK sip:anonymous@10.100.0.5:5060;transport=tcp SIP/2.0
09:13:35 Call-ID: 7FD19CFC-FD8D11E6-BAD7A54F-C48351D@62.140.159.
09:13:35 225
09:13:35 SIP<SIP/2.0 183 Session Progress
09:13:35 Call-ID: 0c621513b11e71abcf5887d6000
09:13:38 SIP<SIP/2.0 183 Session Progress
09:13:38 Call-ID: 0c621513b11e71abcf5887d6000
09:13:38 G711A ssff ps:20
rgn:1 [10.100.0.6]:35284
rgn:18 [10.121.254.221]:2050
09:13:38 xoip options: fax:T38 modemT ttyff uid:0x500fa
xoip ip: [10.121.254.221]:2050
09:13:38 SIP<SIP/2.0 180 Ringing
09:13:38 Call-ID: 0c621513b11e71abcf5887d6000
09:13:38 Alert trunk-group 3 member 208 cid 0x370c
rgn:1 [10.100.0.101]:2072 (GW1)
rgn:18 [10.121.254.221]:2066 (GW18)
09:13:45 xoip options: fax:Relay modemT ttyff (igc)
xoip ip: [10.100.0.101]:2072
09:13:45 xoip options: fax:Relay modemT ttyff (igc)
xoip ip: [10.121.254.221]:2066
09:13:45 idle station 3702 cid 0x370e
VOIP data from: [10.121.254.221]:2050
09:13:46 Jitter:6 0 0 0 0 0 0 0 0 0: Buff:14 WC:12 Avg:6
09:13:46 Pkloss:2 0 0 0 0 0 0 0 0 0: Oofo:0 WC:2 Avg:2
09:14:07 idle trunk-group 3 member 208 cid 0x36fd
09:14:16 TRACE COMPLETE station 3702 cid 0x0

 

[kyle555]

What kind of SBC? Get traces on either side of that. So, what's happening is that buddy on CM hits transfer, that puts the original caller on hold - getting your "sendonly" attribute to send him music and ignore anything he sends you because he's on hold. Presumably when that call flow is completed, you would send a SDP update in a reinvite or 200OK message with m=sendrecv or not specifically mentioning sendonly or recvonly would make the call 2 way again.

Now, there's 2 ways to put calls on hold. RFC 2543 and RFC 3264. Avaya's SBCE, on it's server interworking profile can either let both ends do their thing, or interwork one way to the other should your call server and sip carrier do it differently. 2543 is with a c=0.0.0.0 line, 3264 is with c=the real IP but m=sendonly or m=inactive.

Maybe turn off shuffling in the sig group, maybe see if you can work the interworking profile in your sbc. See what signaling on either end of the sbc looks like upon completion of the conference/xfer and go from there.

Last option is turning on SA8965 for shuffling with SDP, but Avaya will hate you for it. For every problem it fixes, you'll find another it causes