Greetings All,
I hope I haven't missed a previous thread on this. Here is the scenario:
Carrier hand off to an Adtran. Originally it was a 3448 but we're putting in a 6210 instead.
IPBX is ShoreTel with a connection to their Call Center Product (separate server).
Carrier - .198
Adtran - .196
PBX Server .200
ECC Server .201
SIP Trunk Switch .208
Call comes in hits an Auto Attendant on .200 (Full audio) and once you press an option to get transferred to the call center server .201 , it has a faint clicking sound followed by silence and a loss of the audio stream.
Upon looking at the pcap, it appears that the transfer to .201 is successful and establishes the audio stream to the Contact Center Server .201 , but immediately after the trunk switch .208 initiates a new invite back out to the Adtran, which starts a chain of invite SDP, 100 trying, and bouncing between ShoreTel <> Adtran and Adtran <> Carrier until eventually the ShoreTel sends a bye message.
I'm guessing that this second invite is to put the caller on hold or to re-invite as it presents to the agent. With an Ingate SBC there is a setting called inhibit hold to handle this type of situation, or a setting with the signaling order of re-invites, but we much prefer the usage of Adtran's SBCs.
Is there something specific that has to be done in Adtran programming to allow for this or do the 6000 series / 908e's do this natively?
Appreciate any guidance
I believe I am having a similar issue, using Netvanta 7100 - have you figured out a resolution?
The customer ended up yanking SIP out before I got a definitive answer due to other issues, but I believe the solution was to add
ip rtp symmetric-filter
to the config. For some reason that line got left out of the configuration when it was installed. Though it was a default config with other installations on this one the engineers who installed it missed the line, and when I was doing a sanity check I missed that one at first glance.
I got mine fixed! 😃
With a little help from Adtran support, we found the invite was sending out the wrong IP for the return, so we had to add the domain command to the trunk, with the proper IP as the from header. (in a nutshell)
Thanks for getting back to me! Sorry they pulled SIP out!