Avaya CM Ending SIP Call?

[num025]

We've been trying to work out a SIP trunk configuration between a CM 5.2.1 server and an SBC using only TCP which means there are no Session Managers involved as far as I understand it. However, everytime we try to make calls after a few seconds it just drops for no apparent reason. We tried tracing a sample call and here's what we got:

                                LIST TRACE

time            data

15:49:42     dial 9xxxxxxx route:ARS
15:49:42     route-pattern  99 preference 1  cid 0x9
15:49:42     seize trunk-group 99 member 7  cid 0x9
15:49:42     Calling Number & Name zzzz Caller
15:49:42 SIP>INVITE sip:xxxxxxx@yyy.yyy.yyy.yyy SIP/2.0
15:49:42     Setup digits xxxxxxx
15:49:42     Calling Number & Name 917zzzz Caller
15:49:42 SIP<SIP/2.0 100 Trying
15:49:42     Proceed trunk-group 99 member 7  cid 0x9
15:49:49 SIP<SIP/2.0 180 Ringing
15:49:49 SIP>CANCEL sip:xxxxxxx@yyy.yyy.yyy.yyy SIP/2.0
15:49:49 SIP<SIP/2.0 200 OK
15:49:49 SIP<SIP/2.0 487 Request Terminated
15:49:49 SIP>ACK sip:xxxxxxx@yyy.yyy.yyy.yyy SIP/2.0
15:49:49     denial event 1178: Normal call clearing D1=0x9 D2=0x210
15:49:49     idle trunk-group 99 member 7  cid 0x9

Where:
xxxxxxx - Called number
yyy.yyy.yyy.yyy - SBC IP Address
zzzz - Extension

The trace showed that at the exact moment of ringing it seems the CM sends a cancel SIP message thus ending the call. The call was proven to reach the called number as it was registered on our cellphone when we attempted to call its number. We tried looking the denial event up however it just states that it was only a normal event. Could this be really caused by the CM itself or could it be from the SBC or from the provider itself?

 

[num025]

It seems the problem lies on a codec mismatch, we were able to fix the outgoing call issue after using G.711a as a codec (which should've been set at G.729, might ask to change in the SBC later). Now our problem is with incoming calls, particularly having a "403 Forbidden" response from the CM. Tracing external calls got nothing, however when we tried dialing out an extension's DID itself we got this:

                                LIST TRACE

time            data

16:03:26     dial 9xxxxxxx route:ARS
16:03:26     route-pattern  99 preference 1  cid 0x110
16:03:26     seize trunk-group 99 member 4  cid 0x110
16:03:26     Calling Number & Name zzzz Caller
16:03:26 SIP>INVITE sip:xxxxxxx@yyy.yyy.yyy.yyy SIP/2.0
16:03:26     Setup digits xxxxxxx
16:03:26     Calling Number & Name xxxxxxx Caller
16:03:26 SIP<SIP/2.0 100 Trying
16:03:26     Proceed trunk-group 99 member 4  cid 0x110
16:03:26 SIP<SIP/2.0 403 Forbidden
16:03:26 SIP>ACK sip:xxxxxxx@yyy.yyy.yyy.yyy SIP/2.0
16:03:26     denial event 1183: Call rejected D1=0x9 D2=0x215
16:03:26     idle trunk-group 99 member 4  cid 0x110
16:03:27     idle station    zzzz cid 0x110
16:03:31 TRACE COMPLETE trunk-group  99 cid 0x0


Where:
xxxxxxx - Called number
yyy.yyy.yyy.yyy - SBC IP Address
zzzz - Extension

We've looked up a potential cause of the problem being mismatched authoritative domains, however we already verified those in our configurations to be correct (CM ip-network-region domain = procr IP address, SBC ip-network-region domain/signaling group far-end domain = SBC IP address). Other than the ip-network-regions and signaling group forms, are there any other forms that we should take into account when dealing with these domain names?

 

[mattKnight]

>CM ip-network-region domain = procr IP address, SBC ip-network-region domain/signaling group far-end domain = SBC IP address)


I *thought* the authorative domains needed to match,


Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[num025]

Well, what we thought was that you should match the domains of the SBC's network region and the far-end domain signaling group, while having a different one for the CM itself (in which we may be wrong at this point). Anyway, thanks for the suggestion! We'll try tweaking those domain settings the next time we get a hand on those equipments.

 

[num025]

By the way if this would help, we patterned our configuration on this app note.

 

[num025]

After much trial and error, we finally fixed the incoming call issue by removing all authoritative domains entries in all forms in which it can be seen (i.e. signaling groups). Now our problem is with a separate SBC that no matter what we do we can't get its signaling group to come up using TCP as a transport method. We asked them to check if they are capable of TCP though, and still are waiting for their response.