why one way audio when using ringback override 180

[spanky21662]

Sorry, first ever post.

Working with an TA904 2nd Gen, recently upgraded to firmware T900G2A-R11-12-0-E.  We have a SIP to PRI config on the 904. Our switch is a Meta.  PBX... I will need to ask for that one..

From the Meta, we point 5 PORTED Number to the SIP/PRI (904) as DID's... then we have 50 new DID's that we own the NPA/NXX that point to the SIP/PRI (904) as well... With the command "ringback override 180" on the voice trunk T01 type sip,  all works, except that we get one way audio on the 50 DID's that are our NPA/NXX... all works fine for the 5 ported numbers that we send to the SIP/PRI (904) as DIDs...

As soon as I remove the command, "ringback override 180"... I have two way voice... but now, there is a long silence waiting for someone or voice mail to answer the DID call.

I attached my 904 config... and again... sorry, first post EVER... so if you need more info... let me know... I will update as soon as I know what the PBX is... I just know it is new PBX for the customer, as we went from an Analog hand off (8 numbers) to a PRI hand off... 5 Ported numbers and 50 new DIDs.

[Anonymous]

Tim, can you please capture the output of the following 3 debugs running together during a failed call?

debug sip stack message

debug voice verbose

debug isdn l2-format

Thanks

Jay

[spanky21662]

The captures you requested:

Also, the PBX is a new Avaya IP500 OFFICE, Avaya 1400/1408/1416 Series Digital Telephones,

[Anonymous]

Tim, just to confirm, was ringback override 180 enabled or disabled during that capture? Thanks

[spanky21662]

Enabled… so the result on the DID was one way audio… again, the ported numbers (5 of them) that we treat in our Meta Switch, are built as DID numbers as well, just like the 50 DID’s that we own the NPA/NXX on.

Thanks..

[spanky21662]

Sorry, didn’t finish my thought… The 5 ported numbers, are working fantastic built as DIDs in our Meta… no issues at all.. the one way is only happening on the 50 DID’s that we own… but again, they are built exactly the same as the 5 ported numbers…

My thought is a setting in the Avaya IP Office Release 9.1.6

Thanks again.

[Anonymous]

Tim, what looks strange to me is that the Metaswitch is re-inviting the call after the 183 from us:

3:47:54.430 SIP.STACK MSG     Rx: UDP src=10.10.250.2:5060 dst=10.255.252.4:5060

13:47:54.431 SIP.STACK MSG         INVITE sip:9896680146@10.255.252.4:5060;transport=udp SIP/2.0

I would suggest opening a ticket with support for live troubleshooting. Thanks

Jay

[spanky21662]

Thank you, A support Case has been opened.

[spanky21662]

I wanted to provide an update, as this issue has been resolved.

It was real dumb… for our network, up until this install, 100% of our PRI customers, the PBX vendor provided the ringback… this PBX vendor said over and over, she cannot provide ringback… even though she is using this very modern Avaya IP Office system, odd. Maybe someone can tell me if that is true or not or where I can tell this Vendor where to go into the system to turn it on… but I digress, again, real dumb on my part… when we built the PBX interface in the MetaSwitch, there is a field that says: “PBX PROVIDES RINGBACK”… and as always before, using our handy templet, said “YES”… so to fix this issue… I just had to change that to “NO”… and all better… I told you it was dumb…

Thanks again for all the GREAT help from Adtran… as always, Adtran Tech Support are some of the BEST around….

[spiretech]

for people that come across this, i ran into the same issue and found the underlying real problem. when using the ringback override, the adtran switches the rtp stream between two ports, but it doesn't send proper sdp packets to indicate that and newer versions of asterisk ignore the sdp and thus don't talk to the correct port for the audio. sdp packets have a version (v=#) field and that is supposed to change when the sdp is giving new information. the adtran always presents v=0 and so asterisk ignores the sdp packet that switches back to the real audio stream. there is an asterisk setting (ignoresdpversion) that can supposedly get around this, but i haven't tested that. in my case i didn't actually need the ringback override, it was just left over from a copy/paste.

i don't know if adtran monitors these boards, but this is a bug that should be fixed.