INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Jobs

MWI stopped working,

MWI stopped working,

(OP)
MM 5.2.1 on SIP to audocodes then QSIG to CM 6.3. MWI stopped out of the blue. Not working on any stations. Several different errors in operational history viewer. All seem to have something to do with Port 0 but I dont know what that is.

I have done the MWI data base rebuild and the FEDBsync but neither made a difference.

MWI request to 'Reset' the lamp has been called for extension: 101463 on port 0
WARNING NT significant event with ID '3221227238' was reported with strings 'Reset\n101463\nProxy/gateway temporarily unavailable\n'.

MWI request to 'Reset' the lamp has been called for extension: 101496 on port 0
MWI notification being sent to high-level component for extension 101486, error Reset, request Proxy/gateway temporarily unavailable from port 0
MWI request to 'Set' the lamp has been called for extension: 101497 on port 0
MWI notification being sent to high-level component for extension 101497, error Set, request Proxy/gateway temporarily unavailable from port 0

RE: MWI stopped working,

Port 0 in SIP is the MWI port.
Is this a multi-MAS system or single?
Looks like it is referring to the SIP gateway has unavailable.
Any reset changes on the switch or MM?

RE: MWI stopped working,

(OP)
It is a single MAS. Since we upgraded the CM in May we have been trying to get a direct SIP connection to it so during testing the BP would have me change the PBX config to point to the SM instead of the audiocodes. Then we change it back after testing. But we had not done any testing like that for 2 weeks when this problem started so the SIP IP address is the Audiocodes gateway. The ports to it are 1-23 and they function for the call traffic going through. Is there a distinct configuration item that would be port 0?

RE: MWI stopped working,

In the VMSC do you have an entry for the gateway and a PBX as well?

And are you using IP or name for the connection to the gateway. You said that you had been changing the connection between the Audiocodes and the CM so it may be that something is not set right or has been changed in the CM or the gateway.

You need to turn on the SIP trace in the VMSC so that it will put out detailed info on the SIP connection in the OHV.

Ken Means

www.tel-is.com
"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)

RE: MWI stopped working,

(OP)
Just a gateway titled audiocodes and with the IP address of the audiocodes device. During testing we would change the address to the SM. I hear you about the recent changes but nothing has been changed for 2 weeks.

I dont see anything for turning on SIP tracing in the Op hist viewer or VMSC. Where would that be?

RE: MWI stopped working,

(OP)
I found the sip trace info in another of your posts. Thanks Ken

RE: MWI stopped working,

(OP)
Ken,

It took a few tries but I finally saw sip traces by starting live capture first then turning them on. Nothing shows up that seems related to MWI. These traces do. I could not get it to export so I copied these one at a time. They were from an MWI process

MWI notification being sent to high-level component for extension 301179, error Set, request busy device from port 0
Socket connect timed out.
MWI notification being sent to high-level component for extension 101115, error Set, request Unknown error from port 0
MWI request to 'Set' the lamp has been called for extension: 301179 on port 0
MWI notification being sent to high-level component for extension 101383, error Set, request busy device from port 0

Other traces show SIP talk to the audiocodes so I sniffed the MAS ethernet interface and see a lot of talk to the audiocodes SIP address. Mostly UDP but some TCP and no apparent timeouts on any socket. It looks more like an internal process, whatever that high-level component is that is busy and returning unknown errors.

RE: MWI stopped working,

Has anything been changed on the T-1 Qsig side ? This is something that would happen if the qsig port was not open or available for outbound.

I will keep looking but if this was working and now it is not i don't think that it changed itself.

Ken Means

www.tel-is.com
"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)

RE: MWI stopped working,

Have you reset the gateway?

Ken Means

www.tel-is.com
"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)

RE: MWI stopped working,

(OP)
Yes I reset the gateway and MSS and MAS. Rebuilt the mdi data base and did the fedbsync. Everything else over the qsig is working which makes me think it is internal to the mas not a problem over the qsig.

RE: MWI stopped working,

I think it is a problem between the MAS and the gateway or the gateway and the PBX. If the MM is trying to send the MWI then it knows that it needs to be updated and is sending the command it always has. The rejection is come back due to the gateway /PBX not allowing it or that it is blocked in some way.

Did you say you are using TCP or TLS ?

If it is tls i would change it to TCP

With out having access to the system it is had to tell.

Ken Means

www.tel-is.com
"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)

RE: MWI stopped working,

if you can post some screen shots of the PBX setup and the SIP domain name.

Ken Means

www.tel-is.com
"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)

RE: MWI stopped working,

I'm not sure if this is your particular problem, but I've seen a similar problem on a couple systems at MM 5.2. When you change the SIP Gateway info sometimes the data is changed, but not removed from the VMD database. If you look at it in VMSC the Gateway info appears to be correct, but in reality you have additional Gateway info that doesn't display and has not been removed. I'd look at the traces as Ken suggests and just verify that the MWI SIP Notify messages are really going to the AudioCodes gateway and not something else that doesn't exist.

Chuck
RCT Technologies

RE: MWI stopped working,

(OP)
I figured this out, sort of, at least it is working again. I noticed that the session manager that was being used in our testing of the direct SIP link CM to MM without the audiocodes) was crashed or gone into standy mode. When I started it again and restarted MM for the 20th time MWI started working. I did a packet trace and can see the notifys going from the MAS to the Session manager. Even though all the other communication is going to the audiocodes. So after completing our testing and reverting back to the audiocodes link the MWI process is still using the Session manager address. That sounds like what Chuck was describing only it is just affecting the MWI process.

MWI problem resolved, 3 problems left.

1) The system is running split now with part of the connection using each path. Is there a rebuild/resync process for the VMD data base like I have been using on the MWI and FEDB?

2) The reason we have not cut over to the direct SIP connections is that the SIP history information is breaking the coverage for any call made by a vector. There is this string of history entries starting with the vdn that called the vector and the MM is using the first entry in the history for the mailbox lookup. I have seen posts about this problem but never saw any solutions. The BP is stumped. We applied all current SPs and patches to the MM, no help.

3) Our SIP trunk for CM is still being installed but I am worried about the stability of the SM. It is a HP DL360 G7 and from what I have read it seems like it is going into standby mode like an idle PC. The button is red/amber and when I press it, it starts answering pings pretty quick. I don't know what the OS is but it seems like something in the OS config is letting it go to standby when idle.

RE: MWI stopped working,

For item 2 how is the call getting to the vdn?

Ken Means

www.tel-is.com
"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)

RE: MWI stopped working,

(OP)
The call goes to vdn from incoming call treatment on a trunk. The vdn can also be dialed directly and the same thing happens. The vdn goes to a vector. In the vector the option to enter extension works but if it rolls to voicemail it uses the number of the VDN and doesn't find the mailbox. Option to dial by name should go to a caller app at ext 100057 but it doesn't.

RE: MWI stopped working,

(OP)
This closed thread describes the same problem

thread1496-1651135: calls going to mailbox of originating extension, not end extension

The sip trace from the session manager has
100005 - the vdn
101348 - my extension which is the account it should have gone to
100081 - the voicemail hunt group extension

The OHV on MM shows the call was to 100005.

I think its a CM problem but because of the MM involvement I thought their MM threads could help.

RE: MWI stopped working,

Check out the Avaya Configuration notes for the MM with SM Section 8 Considerations / Alternatives:

Called party information is not identified by MM in certain call scenarios such as when using vectoring.

This was corrected in Avaya CM 3.1.4 and CM 4.0.1; corresponding changes were made in the minimum required MM release as noted in Section 2.0.
If you are integrating to an Avaya CM 3.1.4 (or later) or CM 4.0.1 (or later) you need to activate the necessary features in the Modular Messaging System to support these releases. On MM go to C:\Avaya_Support\Registry_Keys on each MAS and double-click on the file “CalledPartyAlgorithm-New1.reg.”

MAS services must be restarted for it to take effect. This will change the way MM reads the SIP History Information records used to integrate the call.


Chuck
RCT Technologies

RE: MWI stopped working,

(OP)
Wow Chuck thanks. It described our problem exactly. It took a while to get time t test it but I did it last night and the cover is going to the correct MM account now. The register change in the Avaya support directory is dated from 2008. It really hard to believe our BP didnt have any knowledge of it.

Thanks again

RE: MWI stopped working,

I had forgotten all about that.

It's funny but years ago people were upset that it did not work like that. As it would go to the mailbox of the last number it hit and not the first (Called Party) number.

Ken Means

www.tel-is.com
"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)

RE: MWI stopped working,

Hi Of all the threads I have looked at this one seems to be the closest at describing the issue we are trying to resolve.
We are setting up call accounting on ships using CO trunks for the shorelines. We are wanting to monitor outgoing long distance phone call. We need to be able to capture the outgoing long distance #'s called using our CDR. We are using a G650 platform with S8400 servers. We are using VDN to vectors to TAC for each of the 12 CO shoreline trunks we are connected to. If we dial the TAC # for each CO trunk directly then th outgoing # we get a CDR of all the outgoing digits dialed and We can see the digits doing a list trace trunk. If we dial the long distance # directly we do not get the digits dialed in the CDR. The list trace shows that the TAC was dialed and it went to the vector but no outgoing phone # is displayed. We have tried and researched all we can with regards to this and have used every possible CDR parameter and trunk parameter setting. The outgoing LD phone # does get dialed and answered so those digits must be somewhere!
How can we get the outgong digits in the CDR when using VDN and vector to a TAC?
Thanks.
Jerry DePasquale
Tellecom
Truestone LLC

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Resources

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close