AcceptCall processed by IsdnTmState base

[Anonymous]

Hi,

Recently I deployed a NetVanta 644.

The T1s are setup as PRIs in user mode.

I am getting the following messages in my event log:

TM.T02 23 AcceptCall processed by IsdnTmState base

TM.T03 23 AcceptCall processed by IsdnTmState base

These messages are on both T1s (I only setup 2 out of 4) and seems always to be on channel 23.

interface t1 0/1

  clock source line

  timing-domain 1

  system-timing primary

  tdm-group 1 timeslots 1-24 speed 64

  no shutdown

interface t1 0/2

  clock source line

  timing-domain 1

  system-timing secondary

  tdm-group 1 timeslots 1-24 speed 64

interface pri 1

  description pri 1

  connect t1 0/1 tdm-group 1

  role user

interface pri 2

  description pri 2

  connect t1 0/2 tdm-group 1

  role user

I have setup many TotalAccess 904s without these messages ever showing up.

The only difference was that those are setup as the network role.

What is the meaning of these messages and is it something I should look into further?

Thanks

Message was edited by: unified

I just received TM.T03 22 AcceptCall processed by IsdnTmState base I guess it's not limited to channel 23.

[Anonymous]

Hello,

Thank you for posting your question in our Support Community.  The message you are seeing looks like output that would be found in a debug voice verbose.  However, I have used your config in a lap setup to make test calls, and I have not seen it show up on the console or in a debug.  We may need some additional information to figure out the exact nature of the message.  Do you think you can get a debug set up and capture the debug output along with the message you are seeing (TM.T02 23 AcceptCall processed by IsdnTmState base)?  If I can look at a call in the debug and see exactly where this message pops up in the call flow, we should be able to answer your question.  Here are the debugs I would like to see running:

debug voice verbose

debug isdn l2-for

debug sip stack message

Make sure these debugs are both running on the same session to the NV 644.

Thanks,

Geoff

[Anonymous]

The problem is that I can't reproduce it.

I see this message every few hours.

What is the generic definition of this alert?

I will be putting a lot more traffic through this device in the near future, perhaps it will happen more often so I can run the debug statements.

[Anonymous]

Perhaps there is something wrong in my trunk configs:

voice codec-list DefaultCodec

  codec g711ulaw

  codec g711alaw

  codec g729

voice trunk-list OrigPRIs

  trunk T02

  trunk T03

voice trunk T01 type sip

  description "SBC"

  sip-server primary x.x.x.x

  codec-group DefaultCodec

voice trunk T02 type isdn

  description "InboundPRI1"

  resource-selection circular descending

  connect isdn-group 1

  modem-passthrough

  t38

  rtp delay-mode adaptive

  codec-group DefaultCodec

voice trunk T03 type isdn

  description "InboundPRI2"

  resource-selection circular descending

  connect isdn-group 2

  modem-passthrough

  t38

  rtp delay-mode adaptive

  codec-group DefaultCodec

voice grouped-trunk SBCTG

  trunk T01

  accept $ cost 0

  permit list OrigPRIs

[Anonymous]

Hello again,

I do not think this message is config related.  This message means that the isdn wire unexpectedly tries to establish a call WHILE we are already processing it.  In order for this condition to occur, the far end of the PRI has to send 2 identical SETUP messages (if these messages are not identical, then they would be treated as 2 separate calls).

At Layer 2, for ISDN PRI, call control messages are carried in INFO frames.  These INFO frames are acknowledged by the receiving end.  If an INFO frame goes unacknowledged, the INFO message is resent.  After 3 attempts, it will not send another INFO message and assumed the link is down.

I am speculating that the far end did not receive the ACK we sent for the first SETUP message and sent the SETUP message again. 

My suggestion would be to check the T1 for errors and monitor for the isdn console message.  You can also ask the provider to check things on their end of the circuit (best time to do this would be right when you see the console message).  If you start to have problems with calls completing, you may need to set up a persistent debug, but as of right now the message is simply a warning.

Let me know if you have further questions.

Regards,

Geoff

[Anonymous]

Currently I am not seeing any other errors.

I will contact the provider and see if they see anything on their end.

Thanks

[Anonymous]

Hello,

I went ahead and flagged this post as “Assumed Answered.” If any of the responses on this thread assisted you, please mark them as either Correct or Helpful answers with the applicable buttons. This will make them visible and help other members of the community find solutions more easily. If you still need assistance, I would be more than happy to continue working with you on this - just let me know in a reply.

Regards,

Geoff

[Anonymous]

I did a little more research and it looks like it was on the VoIP end of things.

If the VoIP gateway did not respond to the INVITE sent by the 644 in a timely manor this error was generated.