[asterisk-users] Asterisk 1.8.7.0 connectivity to Avaya SM

Tue Feb 26 16:11:26 CST 2019

Hello all, I hope someone can help me with this old Asterisk version. I have to run this version because of a custom IVR written on it. Porting it would take much too long and we'd have to hire a consultant because of all the hooks it has into Oracle databases and real-time information.

We have a brand-new Avaya phone system in place and we will be cutting over to it in late March 2019.

Presently:

  *   We have an Asterisk 13.3.2 server with no phones registered to it, acting as a PSTN gateway. Calls come into it and get distributed to other Asterisk boxes with phones.
  *   If a call comes in from the provider marked as having been dialed as xxx-xxx-6711 (those are digits, not a pattern) it gets routed to the IVR box
  *   The IVR box runs Asterisk 1.8.7.0 and a custom IVR.

Where we have to get to:

  *   The new Avaya Session Manager has to have a working SIP trunk to the IVR so it can pass calls that come into xxx-xxx-6711 to it.

What the problem is:

  *   I don't fully understand what's going on here, neither how it works now, nor what I need to do to make Avaya's SM happy.
  *   When I do sip show peers on my IVR box, I see the Avaya session manager:

jerec*CLI> sip show peers

Name/username              Host                                    Dyn Forcerport ACL Port     Status

sessionmgr1                10.10.0.17                                          5060     OK (1 ms)

  *   The Avaya engineer says he is seeing "SIP/2.0 400 Bad FROM header" in his trace screen, and his SM status screen shows "500 NOT REACHABLE" as the status for our IVR.
     *   He says we are sending

"asterisk" sip:asterisk@(null):0;tag=as682f2c53

as the "From" in the SIP header.

  *   He wants us to send
10.10.0.103 at mcts.org<mailto:10.10.0.103 at mcts.org>
or more likely
<sip:10.10.0.103 at mcts.org<mailto:10.10.0.103 at mcts.org>>

instead.

  *   Pings from either end to the other work just fine.
  *   nmap doesn't show port 5060 open. It shows only port 22/tcp open. But then again, my main asterisk PBX doesn't show that port open either. So I don't think that means anything.

The IVR machine (Asterisk 1.8.7.0) sip.conf file has an old section for the old PSTN gateway, and a new section I just added for the session manager.
Old section for existing connections to the IVR:

[general]
;context=transit-ivr
context=incoming
disallow=all
allow=ulaw
canreinvite=no

[sipivr]
host=dynamic
secret=1NA6oZjTg1rjhZN8lArDgzLI7z8V2fxV
type=peer
;context=transit-ivr
context=incoming
dtmfmode=inband

The new section, with many failed experiments commented out, is after the [sipivr] section:
[sessionmgr1]
type=peer
;type=friend
port=5060
host=10.90.0.17
dtmfmode=inband
allowguest=yes
qualify=yes
realm=mcts.org
promiscredir=yes
;Some have suggested using canreinvite=no with Avaya- didn't try that yet
;canreinvite=no
canreinvite=yes
transport=tcp
;context=incoming
context=from-internal
;username=10.90.0.103
fromdomain=mcts.org
disallow=all
allow=ulaw
allow=alaw
tcpenable=yes
tcpbindaddr=0.0.0.0:5060

Nothing I tried seems to make it stop sending asterisk@(null) in the header. This is supposed to be a sip trunk, not an extension, so I think I should NOT be user a username or secret. I'm not even sure what promiscredir does, or if it's helping or harming me.

There's virtually nothing in the logs about this connection, other than this:
[Feb 26 16:05:42] NOTICE[32142] chan_sip.c: Peer 'sessionmgr1' is now Reachable. (1ms / 2000ms)

Can anyone help?

Thomas M. Peters | Sr. Systems Administrator |  tpeters at mcts.org<mailto:tpeters at mcts.org>
Desk: 414.343.1720 | Helpdesk: x3400 or  helpdesk at mcts.org<mailto:helpdesk at mcts.org>
Milwaukee County Transit System <http://www.ridemcts.com/>

1942 N 17th Street | Milwaukee, WI  53205
Check us out on Facebook<https://www.facebook.com/mcts> & Twitter <https://twitter.com/RideMCTS>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20190226/ea8bbf9a/attachment.html>