SIP trunk CM6.2 to PSTN

[SYSUSER2015]

I have CM Aura 6.2.

Calls can only be placed from the Avaya side to external over the SIP trunk. When calls from the externale attempt to ingress via the SIP trunk, the originating caller receives fast-busy. While tracing activity over the SIP trunk I see no indication that the trunk even sees activity during this ingress call.

outgoing call from avaya aura to PSTNk
incoming calls:No

Please help.

Waht is the requirement to establish a SIP trunk with provider.

 

[ZeroZeroOne]

Is this a new or existing SIP trunk implementation? I'm assuming new, but I could be wrong.
Really obvious question: Is the incoming DID actually on the SIP trunk? There could be a provider issue if you are trying to migrate numbers to a new service.

If outbound calls are routing from CM to ASM and to your provider then I'll assume the basic connectivity is correct.

For incoming calls you need to know how many digits are being sent and convert those to your dial plan or otherwise tell ASM how to route the calls.

In Session Manager an Adaptation can convert 10-digits to you extension lengths. Use the Dial Plan to route to CM. You may also have to check your Adaptation for the correct module is used. AT&T, Verizon, and others have unique requirements for how different SIP headers are used.
Or, send all 10-digits to Communication Manager and use the incoming-call-handling on the TIE trunk to convert to extensions.

You said you traced the SIP trunk. Was that in Communication Manager on the TIE trunk to ASM?

Do you have a Session Boarder Controller (SBC)? You can log into the command line and use the command traceSBC to watch the live SIP traffic.
On Session Manager you can use the SIP trace viewer via the System Manager web interface or traceSM at the command line.

These are just a few starting questions to point you in the right direction. I hope it helps.

 

[SYSUSER2015]

Thank you ZeroZeroOne,

outbound calls are routing from CM to provider directly

Is Session manager needed for standard connection SIP trunk with the provider ?
SIP trunk traced beteween CM and Router of the Provider

No I don't have SBC.

Outgoin call through this SIP trunk is ok.
Incoming Call : nothing view when I do list Trace TAC xxx

Please can you provide the SIP trunk confguratio with provider
What is required?

 

[ZeroZeroOne]

Session Manager and SBCs are not required but they sure make things easier.

If an incoming call is not showing up on the trace then I would think there is an issue with the provider or the phone number. You should be able to test with the provider and confirm the incoming phone numbers.

Sorry, but I don't have any experience with SIP trunk direct from CM to a provider. Perhaps someone else can jump in here.

 

[SYSUSER2015]

ZeroZeroOne
If I have Session Manager, how I can use it to setup the trunk SIP with provider?

 

[ZeroZeroOne]

I certainly recommend learning how it all works but it isn't something that can be completed in a short time. Since you have the CM to provider SIP trunk working at least 50%, I would recommend working with the provider to figure out what's going on with your inbound calls. If the List trace tac ### shows no incoming traffic then it is very possible your provider isn't sending you anything.

Once that is up and running you'll have time to sit down and learn Session Manager.

In System Manager you need to follow the instructions under Home / Elements / Routing. There's a lot of planning involved so look at the different forms and think it through.
You'll also need SIP TIE trunks between Session Manager and Communication Manager. I recommend multiple trunks to split traffic based on the type of call. For example:

Trunk Group 990 for calls to Aura Messaging
Trunk Group 991 for calls to Lync
Trunk Group 801 for calls to SIP Provider A
Trunk Group 802 for calls to SIP Provider B
...​

Each type of call typically needs different parameters, such as private numbering for Messaging and Lync and public-unknown-numbering for the SIP Providers.

Introduction to Network Routing Policy
Network Routing Policy consists of several routing applications like "Domains", "Locations", "SIP Entities", etc.
The recommended order to use the routing applications (that means the overall routing workflow) to configure your network configuration is as follows:

Step 1: Create "Domains" of type SIP (other routing applications are referring domains of type SIP).
Step 2: Create "Locations"
Step 3: Create "Adaptations"
Step 4: Create "SIP Entities"
[ul]
[li]SIP Entities that are used as "Outbound Proxies" e.g. a certain "Gateway" or "SIP Trunk"[/li]
[li]Create all "other SIP Entities" (Session Manager, CM, SIP/PSTN Gateways, SIP Trunks)[/li]
[li]Assign the appropriate "Locations", "Adaptations" and "Outbound Proxies"[/li]
[/ul]
Step 5: Create the "Entity Links"
[ul]
[li]Between Session Managers[/li]
[li]Between Session Managers and "other SIP Entities"[/li]
[/ul]
Step 6: Create "Time Ranges"
[ul]
[li]Align with the tariff information received from the Service Providers[/li]
[/ul]

Step 7: Create "Routing Policies"
[ul]
[li]Assign the appropriate "Routing Destination" and "Time Of Day"[/li]
[/ul]

(Time Of Day = assign the appropriate "Time Range" and define the "Ranking")​

Step 8: Create "Dial Patterns"
[ul]
[li]Assign the appropriate "Locations" and "Routing Policies" to the "Dial Patterns"[/li]
[/ul]
Step 9: Create "Regular Expressions"
[ul]
[li]Assign the appropriate "Routing Policies" to the "Regular Expressions"[/li]
[/ul]

Each "Routing Policy" defines the "Routing Destination" (which is a "SIP Entity") as well as the "Time of Day" and its associated "Ranking".
IMPORTANT: the appropriate dial patterns are defined and assigned afterwards with the help of the routing application "Dial patterns". That's why this overall routing workflow can be interpreted as
"Dial Pattern driven approach to define Routing Policies"
That means (with regard to steps listed above):

Step 7: "Routing Polices" are defined
Step 8: "Dial Patterns" are defined and assigned to "Routing Policies" and "Locations" (one step)
Step 9: "Regular Expressions" are defined and assigned to "Routing Policies" (one step)

 

[SYSUSER2015]

Thank ZeroZeroOne
But Today we have tested the same SIP link with Cisco PBX, and I receive the calls from provider without any problem. so the problem is not coming from provider.

 

[SYSUSER2015]

Here trace from router of the provider

 

[ZeroZeroOne]

OK so we know what works:

Cisco PBX --> Provider (outbound calls)
Cisco PBX <-- Provider (inbound calls)
Avaya PBX --> Provider (outbound calls)​

What does not work:

Avaya PBX <-- Provider (inbound calls)​

I would expect to see at least some information on the trunk group but you proved that the Avaya PBX sees no inbound traffic at all with your list trace tac, correct? That means something is blocking the SIP packets from reaching the Avaya PBX while allowing SIP packets from the PBX. That doesn't make much sense from the Avaya programming.

Now, I'm assuming there's a firewall of some sort on your network so we really have something like this:

Avaya PBX <-- Firewall <-- Provider​

Can you check to see if there are any firewall rules that allow incoming traffic from the provider to only certain IP addresses, such as the Cisco PBX, and possibly denying access to the Avaya PBX? One routing rule could be messing up incoming traffic.

 

[SYSUSER2015]

It is possible that the internal Firewall in CM can block traffic?

 

[ZeroZeroOne]

Hmmm.... I have no idea. Maybe, but you'd have to program it that way. It won't block that sort of thing by default.

 

[redphone]

I could be wrong, but it looks like from the trace that the cisco device is sending the SIP INVITE message to Avaya CM via UDP. It should be TCP. Also, it is changing the industry standard P-Asserted-Identity (PAI) header that it received from the PSTN into a non-standard Remote Party ID header (RPID). The cisco programmer need to verify the protocol used for SIP towards Avaya matches the Avaya SIP signaling group (TCP). Also, do not use RPID toward Avaya, use PAI. Lastly, since no real SIP domain structure is in place on the inside segment, verify your Avaya SIP signaling group Far-end Domain is blank, or populated with the cisco IP address; 10.130.151.1.

Avaya CM is not responding to the INVITE. Assuming the INVITE packet makes it to CM, it is not responding because either the wrong port/protocol is used, or it cannot parse the SIP message correctly, i.e., invalid SIP header.