SIP Setup Question 1

[cg11]

I am somewhat new to SIP and have basic questions.

System is IP500v2 R9.0.3.16 with VCM64, 32 SIP trunk licenses. System is part of 2 site SCN. We intend to program LAN2 for SIP traffic. LAN2 is currently setup for 3 remote phones that work perfectly. Customer wants to use SIP trunks as failover when main PRIs are down (carrier will do this automatically).

The SIP provider is Level 3 and has given me 4 IP Addresses:

CPE IP 108.x.x.x.
Signaling IP 4.x.x.x
RTP IP 4.y.y.y
Pingable 4.z.z.z


Questions:

1) Which one of the above IP addresses do I use for the ITSP Domain Name entry?
2) I do not see a place in Manager to enter the other IP adresses (i.e. RTP IP address and Signaling address).

I did acquire and followed the Application notes for configuring Level3 SIP trunking with IPO R8.1. I was told that Level3 uses SBCs in their network.

 

[holdmusic34]

1) Try Signaling IP 4.x.x.x. Make sure you have an ip route

2) use an ip route to your signalling gateway as the default gateway.
rtp 4.x.x.x. destination/ 255.255.255.0/ signalling ip gateway

Punjab Power. Lighting up your life.

 

[rdoubrava]

Level 3 will walk you through the setup process.
There's also a guide on the avaya support site.

 

[cg11]

Thank you guys.

holdmusic34: I have tried using the SIP signaling IP address with no luck.

rdoubrave: I also have a 37 page Application Notes doc for configuring SIP on IPO R8.1. This doc is not accurate as I found that Level has 3 different implementations of SIP (dependent on which company they purchased in the past).

I will try again this Wednesday and Thursday evening to get SIP working and will post results.

 

[derfloh]

https://www.devconnectprogram.com/fileMedia/download/ce63cf69-6980-4419-83c4-354e98ef631d

 

[cg11]

Guys,

I was able to make some progress on setting up IPO SIP with Level 3.

My Line 19 (SIP Trunks) is now showing "In Service" but still can't make inbound/outbound calls. I am now seeing some SIP info in Monitor (see below 403 and 405 errors). I do not get secondary dialtone and can't even dial 7 plus 10 digits (I have Secondary Dialtone checked in the ARS 54 entry). I did set a short code in the form of:

Code - 7N;
Featute - Dial
Telephone Number N"@4.55.x.y" (I blocked out last two octets with x & y)
Line Group ID - 54: SIPTrunks ARS Table

I am seeing these 2 errors in Monitor "SIP/2.0 403 Forbidden" and "SIP/2.0 405 Method Not Allowed".

Any ideas what these mean?




Just a heads up......

The Application Notes (Level 3 IPO R8.1 Setup) contradicts Level 3's "Key Considerations" in many areas.....see below.

Key Considerations - Level 3 SIP Trunking Interconnect:
1. Level 3 will only send E.164 formatted numbers in INVITEs sent to your equipment. Ex: +13035551212
2. Your equipment must send 10, 11 or E.164 formatted digits to Level 3. 7 digit dial plans are unsupported.
3. Level 3 requires that your equipment be provisioned to always use the RTP IP Address provided in the SDP messages for each call. NATs are unsupported.
4. Level 3 uses the IP Port range 5000-28998 for RTP (even numbers) and RTCP (odd numbers) when public access, 6000-38000 when VPN access. If you use a firewall you will need to allow these ranges as appropriate. Non-SIP aware NATs are unsupported.
5. Level 3 will always send RTP to the address indicated in SDP we receive. RFC 1918 private IPs are only supported when using VPN transport. NATs are unsupported.
6. Private IPs in SIP headers are only supported with IP-VPN transport.
7. Level 3 recommends a Diversion Header on all forwarded calls that includes the original called number in compliance with rfc5806. Various problems may occur if Diversion is not included when forwarding calls.
8. The SIP REFER method is unsupported.
9. Level 3 does not send SIP OPTIONS. If SIP OPTIONS is sent to Level 3 we will respond with a 405 Method Not Allowed.
10. Registration is unsupported.
11. Digest authentication is unsupported.
12. A maximum of six sockets are supported with SIP/TCP. Socket reuse is required.

 

[derfloh]

Take a look into considerations 2 and 9

Do read or just copy to here?

 

[cg11]

derfloh - Yes, I read all 5 times and did make note of 2 and 9 (above). I will address 9 (405 Not Allowed) tonight and also look at 2....I am fairly certain we are sending 10 digits.

Will keep all updated on this post as we progress.

 

[cg11]

Update:

For Outbound:

I was successful in getting SIP outbound calls to work. I initially used the 5070 Send port as listed in the Application Notes. I changed the send port back to 5060 but the listen port stayed at 5070 and I could not change it. I ended up creating new new SIP line and deleting the old. Outbound calls work but outplused caller ID does not. I played with the nouser and user's SIP tab with no result. Caller ID just says External E when calling another IP Office. I am using a virtual extension (and ICR) that is unconditionally forwarded to make test calls.....I am working remote and will test later today with a physical phone at customer site.

For Inbound:

Per Item 9 in above "Key Considerations" reply - LEVEL 3 does not send SIP Options

I am still seeing 405 Method not Allowed in monitor. I can't seem to figure out how to turn off SIP Options. The docs just say how to change the Binding Refresh Time for LAN2 and change the SIP_OPTIONS_PERIOD.

Any thoughts?

 

[derfloh]

Usually creating another URI inside your SIP line with all * instead of internal data and with different line group number should let you route inbound call only based on ICR.

If that works create a dummy user with mobile twinning and call control enabled. Set your number as twinning target and create ICR with FNE 00 as target. So you can dial in to FNE 00 and get dial tone as dummy user and you can test all outbound possibilities.

 

[cg11]

Guys,

Finally got this working. The R8.1 Application Notes were helpful but not exact. Main issue was that I had to enter USER NAME, Authentication NAME and PASSWORD on the SIP Line "Credentials" tab while leaving the "Registration" box unchecked.

The "Signaling IP Address" was the correct one (my initial question). You got it right Mr. holdmusic43.

derflo: your suggestion using * allowed for ICR worked perfect. The dummy (remote)dialtone also worked perfectly except that I had to create the following short code to make it work (and use *95 in the ICR "Destinatioin").......nice!!
*95
N
FNE Service
71

Being that we are using SIP trunks as a failover I had to create duplicate incoming call routes for the main numbers and all DID numbers (on both IP500s in the SCN) using the new SIP Group ID.


I am now showing duplicate entries in the Directory for certain users across both IP500s. The duplicate directory listings are only the "users" that are located at site B (the smaller remote location). Duplicate directory users show up on both the main site and remote site phones.

Any thoughts on this?

One more thing that may affect the duplicate "user" entries"......I also created a second H.323 SCN Line for fail over to a VPN (internet). SCN is/was currently running over a single MPLS point-point link prior to me adding the second H323 line.

 

[cg11]

Guys, One more detail: I am now showing the following 2 Alarms, one on each IP500 in the SCN.

There is a conflict with Small Community network dial plan numbers received from 192.168.1.5

There is a conflict with Small Community network dial plan numbers received from 192.168.9.5


Perhaps this dial plan "conflict" is causing the duplicate directory entries? I am not sure why these alarms are showing up as we basically have 2 IP500s with 2 SCN Lines between them.

Could the 2 SCN Lines be confusing the SCN logic?

 

[cg11]

More......

In System Status, under Resources, Directory, there is a "conflict" button at the bottom. I am showing all users and hunt groups as conflicts on both IP500s. I am guessing that adding the second H323 line is causing this OR that I did not set it up correctly.

Perhaps, you can not have 2 H.323 SCN lines defined for 2 IP500s? However,this is a (basic) meshed network design.

Thoughts?

 

[derfloh]

You routers should do the failover routing from one IPO to the other. No need to create a second line. You can also create the same IP routes in IPO but with different gateways and different metric to have a primary and a secondary route between the IPOs.

 

[cg11]

Got it.

I removed the second SCN line and all duplicate directory entries were gone.

More on duplicate directory entries...issue is with dual SCN Lines...can't be done. SCN support star and mesh designs. Dual SCN lines were tried in the early days without success and Avaya dropped it and went with SCN Fallback (for IP Phones). It should be done handled by the IP routers as derfloh says.

I removed the second SCN line and all duplicate directory entries were gone on both Ip500s.

 

[madwok]

cg11,

Thank you for sharing your Level3 experiences here with all of us,
specially under SCN consideration.

I love this board !

 

[IPGuru]

Glad you are working
one tip

keep the incoming group ID as 0 on your sip trunks as well as the ISDN that way you only require the one ICR for each DDI.

as long as you are receiving the DDI digits do you really care what circuit they are arriving on?



Do things on the cheap & it will cost you dear

 

[cg11]

IPGuru,

Excellent point. I did not think it was wise practice to use the same group number for 2 different kinds of trunks but why not? It should work just fine per your suggestion.....Thank you.

I did still create a different group number for the SIP trunks as these two IP500s are SCN'd and have different failover/coverage requirements as both site are in hurricane prone cities. By doing this I was able to have very "fine" control over the ICRs, DIDs, etc. Next time I will do as you suggest....I had to duplicate about 50 ICRs on each system....not a big deal but worth the trouble in our design.