Etisalat sip trunk configuration Help Required


#1

Hi, I am new to UCM. I have to configure Etisalat SIP Trunk.

Here below is the Detail that my SIP provider has given me:

Userid: 45266XXX
Password: dXXX
Domain Name: 45266XXX.isp
Public IP: 192.168.1.X
SBC IP: 192.168.1.X
Pilot No.: 5266XXX
DID: 5266XXX - 5266XXX (200 DIDs , 30 Channels)

Now how do i configure this SIP trunk on UCM 6208, i tried using Route mode on Network Setting as Below:

WAN Interface:
IP V4: 192.168.1 .x
Subnet: 255.255.X.X
Default Gateway: (SBC IP)
DNS 1: (SBC IP)

LAN interface:
Static
IP: 192.168.100.X
Subnet: 255.255.255.0

Now the SIP trunk is getting registered.

When i create outbound route im able to make out bound calls.

But when i create inbound call im not bale to get inbound.

in inbound route in using _5266XXX. as my pattern

and have set the destination to Extention 1034

when i dial call on the pilot number i get busy tone, but teh call shows up in CDR as missied

Can any one help me in configuring it .


#2

This is what im getting when i trace packet on WAN:

Request-Line: INVITE sip:526XXXX@4526XXX.isp:5060;maddr=192.168.1.X (Public IP);user=phone SIP/2.0
Message Header
Via: SIP/2.0/UDP 192.168.1.X(SBC IP):5060;branch=z9hG4bKsjaoeh30bc7a1.1
Call-ID: 469c3h4chn566h3znm576z@UAC
From: sip:0425XXXXX@isp.com;user=phone;tag=hnmx7-CC-1000
SIP from address: sip:0425XXXXX@isp.com;user=phone
SIP from address User Part: 0425XXXXX
SIP from address Host Part: isp.com
SIP From URI parameter: user=phone
SIP from tag: hnmx7-CC-1000
To: sip:526XXXX@4526XXXX.isp;user=phone
SIP to address: sip:526XXXX@4526XXXX.isp;user=phone
SIP to address User Part: 526XXXX
SIP to address Host Part: 4526XXXX.isp
SIP To URI parameter: user=phone


#3

The Scenario that i want to configure is :slight_smile:

I have Extensions : 1001 to 1034

I want to Allocate each extension a separate DID .

i want to give each extension their own DID to make outbound call and can receive inbound for their DID.


#4

Hi any guidance will be appreciable.


#5

is the DID and should be in the inbound rule that points to the desired extension. You will need to add the other DID for the other extension by creating another rule that points to the other extension.

On the trunk settings, there is DOD and you can assign each extension to use the desired DID such that when calling out each with use its specific DID as CID.


#6

Hi can you explain in more detail if you want ican attach my configuration screenshots


#7

Please attach


#8

here are the setting i have right now



#9

When UCM recieves INVITE it sends 401 Unauthorized


#10

The first frame is an outbound rule and governs what the device must see in the dialing pattern before it will allow the call to pass to the trunk.

The privilege level is a relative setting that you can use to establish various tiers of allowed extensions to use the rule. While they are labled as local, national, etc., the names have nothing to do with the actual calling area, but rather they form a hierarchical chain such that those with the highest level (international) can access and make use of any outbound rule and those with lower authority (local for example) can access local and internal, but will not be able to use the national and international rules.

The frame with network settings is more of a personal preference…along with your environment. As your provider apparently has an SBC on site, I am assuming that you also have an internet facing firewall/router apart from the UCM given that the UCM is set to route mode and both the LAN and WAN are using private IPs. If it were me, I would get the provider to change the SBC IP to be within the same LAN segment as the other devices so I could treat it as any other device connected to the LAN. I would then change the UCM to be in switch mode as the route function adds no value and only complicates things. If the provider will or won’t change, then perhaps you can change the environment to his LAN segment.

I will assume the provider settings for the trunk are OK as you indicated outbound is fine. I do encourage you to examine the codec settings in the trunk as well as the extensions and only select those that are needed by the provider. There is no value in sending extraneous codec offerings when many will never see the light of day in use. It is merely added traffic that could be hampered by MTU settings. Fundamentally, it’s extra baggage with no benefit.

On the inbound rule, we need to understand how the provider is delivering the DID. The UCM is very specific with regard to the format and which header is used and while the trace shows 526XXXX, it also shows the it in the TO header and the trunk settings are set for the request line. Please change this to reflect the TO header.

As you were able to get a capture, you should make the suggested changes and make a test call while doing a capture and once complete download the capture, open wireshark and go to the Telephony tab at the top and then VoIP Calls and highloght the test call and then select flow. This will provide a graphical representation of the message flow between the UCM and the SBC and will show if there was some error provided by the UCM that will reveal why the call did not progress. Hopefully, the call will be successful, but if not we can see why with the trace.

Also, I am making the assumption that -

  1. The phones in question are registered to the UCM
  2. Calls have been successfully made between the various extensions so that we know that they work.

While testing I suggest that you change the alert-tone back to the default instead of Alert 4. The intent is to start slow and easy and once it functions correctly,…then you can go back and change to your desire.


#11

Hi, we cannot switch to SBC ip range and the provider will not change the SBC ip range have to manage with the same :neutral_face:

Now i have limited the Codecs on the trunk setting and phones,

I have changed header to To Header.

Here is the new packet trace.

UCM is sending 401 Unauthorized to SBC on INVITE.


#12

For inbound i have solved the issue i did the steps u mentioned above and also i removed tick from Auth Trunk. and it worked like a charm. Now im facing issue is using DOD, i did setup for DOD but still when im dialing out it is using the Pilot number.


#13

Then the settings in the VoIP trunk are likely lacking. At this point, it is somewhat of a guessing game as to what, a couple of areas to consider -

  1. The auth trunk setting, uncheck and try again. Do this one first.
  2. Try putting the username in the from user as well.
  3. I am also not used to seeing the authID being the same as the from domain, but perhaps so.

I assumed the provider gave you the needed settings and of course, many have some subtle differences in what they require and many, many are a little less than forthcoming in all the details.


#14

tried the above but no luck

i need to send call from DID@45266999.etisalat

Should i use PPI header or PAI Header as per the trace u see


#15

Frame 2: 1128 bytes on wire (9024 bits), 1128 bytes captured (9024 bits)
Ethernet II, Src: Grandstr_d7:f0:50 (00:0b:82:d7:f0:50), Dst: AcmePack_a1:c4:78 (00:08:25:a1:c4:78)
Internet Protocol Version 4, Src: 192.168.1.25, Dst: 192.168.1.6
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:0509107467@192.168.1.6 SIP/2.0
Message Header
Via: SIP/2.0/UDP 192.168.1.25:5060;rport;branch=z9hG4bKPj1e75b7b3-5353-4f55-a97a-834603bcf73c
From: sip:045266999@45266999.etisalat;tag=3e50a47b-267f-4576-a9e0-d64d32565523
To: sip:0509107467@192.168.1.6
Contact: sip:5266934@192.168.1.25:5060
Call-ID: fcdbc2e1-72b6-4978-8777-40143c8ae9f4
CSeq: 28066 INVITE
Route: sip:192.168.1.6;lr
Allow: OPTIONS, INFO, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, MESSAGE, REGISTER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
X-Grandstream-Transport: trunk
P-Preferred-Identity: sip:5266934@45266999.etisalat
Max-Forwards: 70
User-Agent: Grandstream UCM6208V1.4A 1.0.18.12
Content-Type: application/sdp
Content-Length: 285
Message Body


#16

Sorry, am now confused. You earlier indicated you could call out, but it was the inbound that was the issue-
When i create outbound route im able to make out bound calls.

But when i create inbound call im not bale to get inbound.

The settings you mention are outbound.


#17

now inbound is working , outbound is also working but DID setup is not wokring, it is using the same pilot numbe rinstead of DID


#18

For Outbound


#19

OK to be clear - in and out are now working, it is only the CID out that is showing the pilot that is the issue?


#20

yes its the CID now