Routing Avaya CM PSTN Calls through Session Manager to an Avaya CS1000MG 7.65 out over the PSTN:

[hardybacon]

We don't have any local resources for our Avaya Communicaiton Manager Server at our main site as all the branch offices are remote. All the Branch Offices have Local PSTN Resources and yes we can send calls out through them. I would like to route PSTN Calls for CM IP Phones at our main site out of our Medium Enterprise CM 6.x to Session Mgr 6.2 to our Avaya CS1000MG (Legacy 81C upgraded to 7.65) via an ISDN PRI. I know there is some setup for this. My only question is, is there any reason why it won't work? - Thank you

 

[bignose21]

No

 

[Johnthephoneguy]

We do that on a much larger scale and it works with no trouble. Lots of Clid table entries but that's the worst of it.

JohnThePhoneGuy

"If I can't fix it, it's not broke!

 

[hardybacon]

Thank you both.

 

[hardybacon]

I'm missing something once I hit the session manager to go to the CS1000. I can see the call hit SM via traceSM but it is rejected 480. I'm guessing I need an adaptation on Session Manager or translate the calltype with a new entry or route list index on the CS1000. Our current setup routes all extension calls via SIP between offices. - Thank you

 

[hardybacon]

It is reject 404 not found once it hits Session Manager.


shbmecm
SM100
----------------------------------------------------------------------------------------------------------------------------------------------------------------
10:07:47.729 |--INVITE-->| | | (139) T:8165590388 F:anonymous@anonymous U:8165590388 P:terminating
10:07:47.730 |<--Trying--| | | (139) 100 Trying
10:07:47,731 | Remote host is trusted | Trusted
10:07:47,731 | Applied ingress Adaptation |
10:07:47,731 | Originating Location found | Location: SHB KC EFLAN
10:07:47,731 | Try routing to determine if eme | Location: SHB KC EFLAN
10:07:47,731 | Request Dial Pattern route | for: sip:8165590388@shb.com Location: SHB KC EFLAN
10:07:47,731 | Dial Pattern route parameters | URI Domain: shb.com Location: SHB KC EFLAN
10:07:47,731 | Dial Pattern route parameters | URI Domain: null Location: SHB KC EFLAN
10:07:47,731 | Dial Pattern route parameters | URI Domain: shb.com Location: null
10:07:47,731 | Dial Pattern route parameters | URI Domain: null Location: null
10:07:47,732 | Request Regular Expression rout | for: sip:8165590388@shb.com
10:07:47,732 | Request Dial Pattern route | for: sip:8165590388@shb.com Location: SHB KC EFLAN
10:07:47,732 | Dial Pattern route parameters | URI Domain: shb.com Location: SHB KC EFLAN
10:07:47,732 | Dial Pattern route parameters | URI Domain: null Location: SHB KC EFLAN
10:07:47,732 | Dial Pattern route parameters | URI Domain: shb.com Location: null
10:07:47,732 | Dial Pattern route parameters | URI Domain: null Location: null
10:07:47,732 | Request Regular Expression rout | for: sip:8165590388@shb.com
10:07:47,732 | Route not found | for: sip:8165590388@shb.com
10:07:47.733 |<--Not Fou-| | | (139) 404 Not Found (No route available)
10:07:47.733 |----ACK--->| | | (139) sip:8165590388@shb.com

 

[fataldata]

Looks like your SM may need to be told what route to use when it receives calls destined for sip:8165590388@shb.com. Seems your session manager may not know what to do with the call.

 

[hardybacon]

I tried many variations of the Dial Pattern for 816, 1816, +816 to the Node IP of of the SIP Trunks on the Cs1000 along with changing the CM Route \ ars for the correct tenant\location.

I have even setup 816 as a unified dial plan\ars in CM & CDP in CS1000. I can dial out without a 9 (AC1 access code) on the CS1000 for 816-xxx-xxxx.

I think it a a setting on the SIP Trunks such as call type (can't change call type as we have our calls between offices on SIP) on the CS1000 or a Adaptation on the Session Manager.

Yes, trunk to trunk transfers are allowed.

Not sure what the issue is. - Thank you

 

[fataldata]

If you trace the signalling link on the CS1000 (receiving) side do you see the call trying to come through on the sip trunks?

You could also try to match the sip message. Something like ^sip:816

Been a while since I worked on an SM but the key for me was tracing from the receiving side of the routed call.

 

[hardybacon]

Thank you. I will give it a go. Here is what I found on Tek-Tips for the newer Sig Servers. Not sure if it is what I need exactly, but will give it a go.

That looked better beforei posted it here are the commands split

7.65 Sig Server Commands for tracing:

That looked better beforei posted it here are the commands split

To Enable
vxShell vtrk sipNpmAppDebugSet tSSG sipMsgPrint 1
vxShell vtrk sipNpmAppDebugSet tSSG acpDebug 1
vxShell vtrk sipNpmAppDebugSet tSSG sdptDebug 1
syslogLevelSet vtrk tSSG 7
syslogLevelSet vtrk tSIPNPM 7
SIPCallTrace tSSG on

To Disable
vxShell vtrk sipNpmAppDebugSet tSSG sipMsgPrint 0
vxShell vtrk sipNpmAppDebugSet tSSG acpDebug 0
vxShell vtrk sipNpmAppDebugSet tSSG sdptDebug 0
syslogLevelSet vtrk tSSG 6
syslogLevelSet vtrk tSIPNPM 6
SIPCallTrace tSSG off

$ pcap start --> before making the testing
$ pcap stop --> after completion of the testing

Collect the PACP files from /var/opt/nortel/dfoTools/pcap folder on the signaling server

 

[bignose21]

TBH if you just turn on DCH monitor it would be easier

 

[hardybacon]

Built some new SIP Trunks in CM as Public. Yep, I checked the Entity Links. At least I'm to where it is not trusted on SM. Trust no one. - Fox Mulder

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
17:03:04.261 |--INVITE-->| | | (7) T:8165320099 F:anonymous@anonymous U:816532xxxx P:terminating
17:03:04,263 | Remote host is not trusted | Host not trusted
17:03:04,263 | Originating Location found | Location: SHB-CM
17:03:04.263 |<--Trying--| | | (7) 100 Trying
17:03:04.264 |<--Server -| | | (7) 500 Server Internal Error (Cannot determine realm)
17:03:04.265 |----ACK--->| | | (7) sip:816532xxxx@10.10.16.11

 

[hardybacon]

I'm guessing I need to try to setup TLS or somehow make numbers as trusted SIP Entities? If anyone has a hint, please let me know. - Thank you


10:52:55.659 |--INVITE-->| | | (205) T:8165590388 F:anonymous@anonymous U:8165590388 P:terminating
10:52:55.661 |<--Trying--| | | (205) 100 Trying
10:52:55.663 |<--Not Fou-| | | (205) 404 Not Found (cannot determine routing domain, check SM ports)
10:52:55.701 |----ACK--->| | | (205) sip:8165590388@10.10.16.11

|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
|INVITE sip:8165590388@10.10.16.11 SIP/2.0 |
|From: "Chicago Template Phone" <sip:anonymous@anonymous.invalid>;tag=805ac2cbe95e51191756596d5400 |
|To: <sip:8165590388@10.10.16.11> |
|Call-ID: 805ac2cbe95e511a1756596d5400 |
|CSeq: 1 INVITE |
|Max-Forwards: 71 |
|Via: SIP/2.0/TCP 10.10.16.34:5062;branch=z9hG4bK805ac2cbe95e511b1756596d5400 |
|Via: SIP/2.0/TCP 10.8.100.103;branch=z9hG4bK805ac2cbe95e511b1756596d5400 |
|Supported: 100rel,histinfo,join,replaces,sdp-anat,timer |
|Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,INFO,PRACK,PUBLISH,UPDATE |
|User-Agent: Avaya CM/R016x.02.0.823.0 |
|Contact: "Chicago Template Phone" <sip:10.10.16.34:5062;transport=tcp> |
|Route: <sip:10.10.16.11:5062;transport=tcp;lr;phase=terminating> |
|Accept-Language: en |
|Alert-Info: <cid:internal@invalid.unknown.domain>;avaya-cm-alert-type=internal |
|History-Info: <sip:8165590388@10.10.16.11>;index=1 |
|History-Info: "8165590388" <sip:8165590388@10.10.16.11>;index=1.1 |
|Min-SE: 9600 |
|P-Asserted-Identity: "Chicago Template Phone" <sip:shb.com> |
|Record-Route: <sip:10.10.16.34:5062;transport=tcp;lr> |
|Session-Expires: 9600;refresher=uac |
|Privacy: id |
|P-Charging-Vector: icid-value="AAS:999-2c0c5a801e595be59561718546d" |
|Content-Type: application/sdp |
|Content-Length: 229 |
| |
|v=0 |
|o=- 1447779175 1 IN IP4 10.10.16.34 |
|s=- |
|c=IN IP4 10.10.16.19 |
|b=AS:64 |
|t=0 0 |
|a=avf:avc=n prio=n |
|a=csup:avf-v0 |
|m=audio 2050 RTP/AVP 0 8 127 |
|a=rtpmap:0 PCMU/8000 |
|a=rtpmap:8 PCMA/8000 |
|a=rtpmap:127 telephone-event/8000


|SIP/2.0 100 Trying |
|Call-ID: 805ac2cbe95e511a1756596d5400 |
|CSeq: 1 INVITE |
|From: "Chicago Template Phone" <sip:anonymous@anonymous.invalid>;tag=805ac2cbe95e51191756596d5400 |
|To: <sip:8165590388@10.10.16.11> |
|Via: SIP/2.0/TCP 10.10.16.34:5062;branch=z9hG4bK805ac2cbe95e511b1756596d5400 |
|Via: SIP/2.0/TCP 10.8.100.103;branch=z9hG4bK805ac2cbe95e511b1756596d5400 |
|Content-Length: 0

|SIP/2.0 404 Not Found (cannot determine routing domain, check SM ports) |
|Call-ID: 805ac2cbe95e511a1756596d5400 |
|CSeq: 1 INVITE |
|From: "Chicago Template Phone" <sip:anonymous@anonymous.invalid>;tag=805ac2cbe95e51191756596d5400 |
|To: <sip:8165590388@10.10.16.11>;tag=8896626489507493_local.1403020519624_40392345_40406137 |
|Via: SIP/2.0/TCP 10.10.16.34:5062;branch=z9hG4bK805ac2cbe95e511b1756596d5400 |
|Via: SIP/2.0/TCP 10.8.100.103;branch=z9hG4bK805ac2cbe95e511b1756596d5400 |
|Record-Route: <sip:rw-3f5b8e12@10.10.16.11:5062;lr;transport=TCP> |
|Record-Route: <sip:10.10.16.34:5062;transport=tcp;lr> |
|Av-Global-Session-ID: a64a29d0-8d4b-11e5-bdb0-f0921c1240a0 |
|Server: AVAYA-SM-6.3.7.0.637008 |
|Content-Length: 0

|ACK sip:8165590388@10.10.16.11 SIP/2.0 |
|From: "Chicago Template Phone" <sip:anonymous@anonymous.invalid>;tag=805ac2cbe95e51191756596d5400 |
|To: <sip:8165590388@10.10.16.11>;tag=8896626489507493_local.1403020519624_40392345_40406137 |
|Call-ID: 805ac2cbe95e511a1756596d5400 |
|CSeq: 1 ACK |
|Max-Forwards: 70 |
|Via: SIP/2.0/TCP 10.10.16.34:5062;branch=z9hG4bK805ac2cbe95e511b1756596d5400 |
|User-Agent: Avaya CM/R016x.02.0.823.0 |
|Route: <sip:10.10.16.11:5062;transport=tcp;lr;phase=terminating> |
|Content-Length: 0

 

[fataldata]

In my opinion TLS will only make things more complicated. I almost always used UDP unless there was a need for TLS. If you are routing any calls from the Aura system to the CS1k even for extensions then I wouldn't think you have an issue with the trunk between the two, so that would lead me to believe this is a routing issue. I'm still curious if the CS1K is receiving any of this traffic. This leads me to believe it is not.

10:52:55.663 |<--Not Fou-| | | (205) 404 Not Found (cannot determine routing domain, check SM ports)

To me that indicates SM is unable to determine the proper route for the call. It appears SM possibly may not know the domain of your "Chicago Template Phone" since it comes from Anonymous@anonymous.invalid Can this Chicago Template Phone call an extension on the CS1K? or possibly compare this trace with a successful extension call.

Sorry lots of ideas but without a better understanding of your system all I can do is guess.

 

[hardybacon]

Thank you fataldata. I did find an issue with a SIP name. The call is going to the CS1000 SIP Route & being rejected from there. I can see the call come in on DCH Messaging. I'm not sure if you can have both CDP & PSTN calls on the SIP route or what the correct config is for that. I'm researching it and looking at the TGAR & NCOS Settings.

DCH 252 IMSG SETUP REF 00008186 CH 252 0 0 5 TOD 10:21:03
CALLING #:42777 NUM PLAN: NUM UNKNOWN/UNKNOWN (UNKNOWN)
CALLED #:1018165590407 NUM PLAN: NUM UNKNOWN/UNKNOWN (UNKNOWN)

DCH 252 IMSG CALLPROC REF 000002A2 CH 252 0 9 1 TOD 10:21:07

DCH 252 IMSG CONNECT REF 000002A2 CH 252 0 9 1 TOD 10:21:07

-
10:21:11.277 |--INVITE-->| | | (12) T:8165590407 F:42777 U:8165590407 P:terminating
10:21:11.279 |<--Trying--| | | (12) 100 Trying
10:21:11,280 | Applied ingress Adaptation |
10:21:11,280 | Originating Location found | Location: KC IP Phone
10:21:11,280 | Try routing to determine if eme | Location: KC IP Phone
10:21:11,280 | Request Dial Pattern route | for: sip:8165590407@shb.com Location: KC IP Phone
10:21:11,280 | Dial Pattern route parameters | URI Domain: shb.com Location: KC IP Phone
10:21:11,281 | Dial Pattern route parameters | URI Domain: null Location: KC IP Phone
10:21:11,281 | Dial Pattern found | for: 8165590407 Pattern: 816
10:21:11,281 | Route Policy found | Pattern: 816 RoutePolicyList: Kansas City
10:21:11,281 | Dial Pattern route parameters | URI Domain: shb.com Location: null
10:21:11,281 | Dial Pattern route parameters | URI Domain: null Location: null
10:21:11,281 | Route found | for: sip:8165590407@shb.com SIPEntity: kccs1k
10:21:11,281 | Entity Link found | SIPEntity: kccs1k EntityLink: KCSM01->TCP, biDirId=null, deny=false:5
10:21:11,281 | Entity Link to another SM | To: KCDRSM01 MyInstance: KCSM01
10:21:11,281 | Entity Link found | SIPEntity: KCDRSM01 EntityLink: KCSM01->TCP, biDirId=null, deny=false
10:21:11,281 | Entity Link to another SM | To: KCDRSM01 MyInstance: KCSM01
10:21:11,281 | Entity Link found | SIPEntity: KCDRSM01 EntityLink: KCSM01->TCP, biDirId=null, deny=false
10:21:11,282 | Applied egress Adaptation | History-Info= "8165590407" <sip:8165590407@shb.com>;index=1
10:21:11,282 | Routing SIP request | SipEntity: kccs1k EntityLink: KCSM01->TCP:5060
10:21:11,284 | No hostname resolution required | Routing to: sip:10.10.16.101;transport=tcp;lr;phase=terminating
10:21:11.306 |<--Not Fou-| | | (12) 404 Not Found
10:21:11.307 |----ACK--->| | | (12) sip:8165590407@shb.com

 

[fataldata]

So when I would try these types or configs, I would have 2 routes in SM. One for extensions and one for outgoing pstn calls. The one for pstn calls would insert a 9 before the number so the far end switch would know to route the call to an external connection. I believe both trunks will need to have Trunk to Trunk Transfer enabled.

It looks like that may be all you are missing. Because your CS1K does not know what to do with 8165590407 since it does not have a 9 or a trunk access code in front of it. Unless to TAC is 101? CALLED #:1018165590407

 

[hardybacon]

Hi fataldata - First, thank you for your help. I appreciate it.

I've tried many thing like inserting a 9, digit manipulation, changing FRL\MFRL on local trunks. Thought I had it several times. I'm going to try a couple more thinks and call it quits. I already opened a time & materials inquiry with support. - Thank you

 

[fataldata]

Hope you get it figured out. Good Luck

 

[madwok]

Hi,

Also check on your adaptation rule under routing for cm and cs1k . Post yours here if you can

You should have something like this for cm with digitconverstionadapter ( module name )

digit conversion for incoming calls to SM

Matching pattern min max phone context del dig insert digit address to modify

1 / 11 / 11 / <blank> / 0 / + / destination



so digits from ars ( cm ) is being converted to e.164 format ( with +1xxxyyyzzzz)


for cs1k , use module name CS1000adapter with module parameter type name-value parameter

fromto is true
iodstd is whaterveryours.com
iosrcd is cs1k.whateveryours.com

digit conversion for outgoing calls from SM

Matching pattern min max phone context del dig insert digit address to modify

+1 / 2 / 36 /+1 / 1 / 9 / destination
x / 4 /4 /cdp-udp / 0 / blank / destination


This is a basic so at least you can send the calls out
of cm ---> SM ---> cs1k assuming that you are using the 9 to dial out on the cs1k and cs1k is using 4 digit for DN

Hope this help