I am trying to set up a mock cellular network that simulates VoLTE by utilizing FreePBX as the SIP server.
Here is my current setup:
I am using an Agilent E6621A PXT Wireless Communications Test Set, which supports wireless LTE connections to any smartphone with the right configuration. This allows me to create a mock cellular network. This test set has an IP address of 192.168.1.60, and gives the smartphone an IP address of 192.168.1.51 and/or 192.168.1.52 depending on the setup.
By setting the P-CSCF of one of the bearers of the network setup on the instrument to the address of a SIP server, I can have the UE, or cellphone, connect to that server to provide a given set of services, such as SIP.
I am using an LG G3 VS985 and a iPhone 6S+, both of which support SIP when in VoLTE mode.
I am using FreePBX 13.0.191.11 which utilizes Asterisk 13.12.1 and I have been able to get multiple desktop clients connected and calling successfully.
The problem I am having, however, is that although the UEs that I am testing send a “REGISTER” request to 192.168.1.12, the local IP of our Asterisk/FreePBX Server, we get no response to the REGISTER message. I have also tested pinging between the two destinations and found that the pings and their responses are timing out.
Does anyone have any idea as to what the problem is? It seems to possibly be a network problem possibly caused by our router (which is a Cisco ASA5505 running the most recent version of its firmware). Note that the Server and PXT are connected to the same hub, which means all packets can be seen by all computers on that hub. Any and all recommendations are greatly appreciated. I can also provide a Wireshark capture of this issue should anyone need more details on the issue. Also let me know if you need more details on what I am using or what I am doing.
The firewall module has been completely disabled for this very reason. It was the first thing I did when I set FreePBX up. In other words, it allows all connections regardless because there is no firewall to block connections.
I’d have steered the other way, since the firewall is so tightly integrated into the system, but you know what you’re doing.
Your next step is probably to watch the CLI as the connections are logged or review the …/full logs to see what the response to the INVITE is. You could also try turning on SIP DEBUG and see if that shines any additional light on your problem.
I have been keeping an eye out for messages there. And what actually need to be looking for is a REGISTER message, which I don’t seen in the logs or CLI. All I see according to a Wireshark capture on the same hub is that the UE calls for the server, and based on the CLI and logs, the server never receives the REGISTER message to respond. This is why I am thinking it may be related to our Cisco ASA5505 Router (which is already a nightmare to set up/handle).
I could try the limited firewall, though I doubt that is the issue here based on the packet behavior of the REGISTER message.
I’ll upload the wireshark capture next so that you know what is happening.
I can’t see your dropbox account (untrusted network).
From experience, when people tell me that they see packets getting sent to the server in tcpdump or wireshark but no responses are sent, it is almost always the integrated firewall. Either that, or you’re sending the traffic to a port that isn’t listening (5060 is assumed to be one of the SIP Channel Drivers, but you might want to double check that the port is active on the server).
The interface (e.g., eth0) IS seeing the traffic, but the application is blocking it. This screams firewall.
I recommend turning the firewall on and setting up the trust zones for the local network. You have nothing to lose (it can’t ‘not work’ any more than it is now) and might be part of the problem.
I applied that and tried it with no difference. In the meantime, I analyzed the register messages.
Here are the list of differences as compared to a ZoiPer REGISTER message: Agilent Client (a software that came with the instrument; it can register and receive calls, but not make calls):
Via header specifies an Rport as rport.
Always has a checksum errors.
Includes an Allow Header UEs:
Ethernet II, Dst is set to the Cisco router. This means that its expecting the router to forward the SIP message to 192.168.1.12 properly which it seems it fails to do. Unfortunately, I don’t know enough about the ASA5505 to get around this without messing it up.
The Time To Live is half of that of the computer clients
Contact Header has no “User” part
Authorization Header uses “ims…3gppnetwork.org” as realm (instead of “asterisk” and the username includes @ims…3gppnetwork.org, when the computer clients don’t include that.
Branch is different and Rport set to rport in Via Header.
Includes an Allow header
I see a few potential problems here:
We are using a SIP server, when in actuality, we need to be using an IMS server. I don’t think this is the case, but it could be. Based on research, technically this shouldn’t be an issue unless both the Client and UEs are looking for a service that FreePBX doesn’t provide, which isn’t likely.
What is Rport really do? I don’t see it in FreePBX, and based on the quick lookup I did on it, it’s not likely to be our issue.
Why are the UEs trying to go to the router when all they need to go to is 192.168.1.12?
a. The username issue with the UEs may be an issue if we are able to get around the current routing issue.
Why does the UE send only the same message constantly, whereas the clients adjust their REGISTER messages?
Maybe this will clear up one of the issues. My guess is that its actually the router failing to forward the messages properly when it comes to the UE registration message.
As for the pcapng, what network can I drop it to that you would be able to access it (Google, Github, etc)?
I also noticed that any computer running a windows SIP serverrespond to the SIP request of the UE. FreePBX doesn’t respond at all to the SIP request, whether the firewall is up or not.
As for putting up a SIP trunk, would that possibly help? The register message from the UE seems to arrive at its destination, but the computer does nothing about it.
I think part of the problem I am having is that the UE is trying to register to a realm that is not the same as FreePBX’s. Is there any way to set up FreePBX so that it accepts REGISTER request for any realms? And that being said, I know one of the registration issues will be that the username does not align with the extension (the UE adds the domain name). Does anyone know how to change the incoming messages or FreePBX so that the UEs get accepted?
I did a tcpdump on the server and the server is in-fact receiving the UE’s requests, it just doesn’t do anything with it.
As for uploading the pcap elsewhere, I have not gotten a response and the site is refusing to let me upload a *.tgz of it.
The reason you’re not getting any answers is because there is literally no way for any of us to know the answers to your questions.
You have a mish-mash of equipment that I’m guessing is literally unique in the world and it sounds like you’re trying to solve a whole bunch of different problems at the same time.
I can’t even conceptualize what you’re trying to do nor can I figure out what part of this is supposed to rely on Asterisk. I’m almost certain that none of your problems are FreePBX issues, because I’m not convinced your system is close enough to working for it to be part of problem set… I’m just not smart enough to help you remotely with this much unfamiliar equipment and technology.
From an Asterisk position, you will need to set up the standard interfaces (a trunk, an inbound route, an outbound route, and extension definitions) for the PBX to function as the telephony controller. It won’t do anything else, though, since that’s all it’s designed to do. If you are trying to get the phones to register to the PBX, you need to make sure the network connectivity is there. If you are trying to get POTS telephony to work, you’ll need POTS trunks and routes. The Asterisk part of this should be the simplest components. Note that if you send requests for ports in FreePBX that don’t exist, you will not get responses back (unlike Windows) so relying on the system to fail and report is a non-starter.
I wish you luck. I’m really at my wit’s end on what else we can do to help you.
I understand your struggle with helping me with such limited information, but I hope we can at least get somewhere with this issue, whether it means 1. concluding that the two systems are incompatible or 2. finding a new setup that has never been attempted before through systematic debugging.
Would the following Register Message Packet sent by one of our UEs captured by Wireshark and dissected be able to help identify problems?
No.: 216
Time: 1308.240861000
Source: 192.168.1.51
Destination: 192.168.1.12
Protocol: SIP
Length: 1262
Info: Request: REGISTER sip:ims.mnc01.mcc001.3gppnetwork.org |
Frame 216: 1262 bytes on wire (10096 bits), 1262 bytes captured (10096 bits) on interface 0
Interface id: 0
Encapsulation type: Ethernet (1)
Arrival Time: Jun 8, 2017 13:09:08.243684000 Eastern Daylight Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1496941748.243684000 seconds
[Time delta from previous captured frame: 3.997744000 seconds]
[Time delta from previous displayed frame: 3.997744000 seconds]
[Time since reference or first frame: 1308.240861000 seconds]
Frame Number: 216
Frame Length: 1262 bytes (10096 bits)
Capture Length: 1262 bytes (10096 bits)
[Frame is marked: False] [Frame is ignored: False]
[Protocols in frame: eth:ip:udp:sip]
[Number of per-protocol-data: 1]
[Session Initiation Protocol, key 0]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: MS-NLB-PhysServer-02_50:15:e9:ce (02:02:50:15:e9:ce), Dst: Cisco_82:0b:5d (40:55:39:82:0b:5d)
Destination: Cisco_82:0b:5d (40:55:39:82:0b:5d)
Address: Cisco_82:0b:5d (40:55:39:82:0b:5d)
… …0. … … … … = LG bit: Globally unique address (factory default)
… …0 … … … … = IG bit: Individual address (unicast)
Source: MS-NLB-PhysServer-02_50:15:e9:ce (02:02:50:15:e9:ce)
Address: MS-NLB-PhysServer-02_50:15:e9:ce (02:02:50:15:e9:ce)
… …1. … … … … = LG bit: Locally administered address (this is NOT the factory default)
… …0 … … … … = IG bit: Individual address (unicast)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 192.168.1.51 (192.168.1.51), Dst: 192.168.1.12 (192.168.1.12)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00… = Differentiated Services Codepoint: Default (0x00)
… …00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 1248
Identification: 0xfea7 (65191)
Flags: 0x00
0… … = Reserved bit: Not set
.0… … = Don’t fragment: Not set
…0. … = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xf3d5 [correct]
[Good: True]
[Bad: False]
Source: 192.168.1.51 (192.168.1.51)
[Resent Packet: False]
Message Header
To: sip:[email protected]
SIP to address: sip:[email protected]
SIP to address User Part: 001010123456789
SIP to address Host Part: ims.mnc01.mcc001.3gppnetwork.org
From: sip:[email protected];tag=poW1v0IapZ
SIP from address: sip:[email protected]
SIP from address User Part: 001010123456789
SIP from address Host Part: ims.mnc01.mcc001.3gppnetwork.org
SIP from tag: poW1v0IapZ
Expires: 600000
Require: sec-agree
Proxy-Require: sec-agree
[truncated] Security-Client: ipsec-3gpp;alg=hmac-md5-96;ealg=null;mod=trans;port-c=52720;port-s=65244;prot=esp;spi-c=141515936;spi-s=159291877,ipsec-3gpp;alg=hmac-sha-1-96;ealg=null;mod=trans;port-c=52720;port-s=65244;prot=esp;spi-c=141515
Call-ID: CstQfBKYCMwAEn5D3URjEWOe
Contact: sip:192.168.1.51:5060;+g.3gpp.mid-call;+g.3gpp.smsip;+g.3gpp.srvcc-alerting;+sip.instance=“urn:gsma:imei:35699906-132434-0”
Contact URI: sip:192.168.1.51:5060
Contact URI Host Part: 192.168.1.51
Contact URI Host Port: 5060
Contact parameter: +g.3gpp.mid-call
Contact parameter: +g.3gpp.smsip
Contact parameter: +g.3gpp.srvcc-alerting
Contact parameter: +sip.instance=“urn:gsma:imei:35699906-132434-0”\r\n
Authorization: Digest nonce="",uri=“sip:ims.mnc01.mcc001.3gppnetwork.org”,realm=“ims.mnc01.mcc001.3gppnetwork.org”,username="[email protected]",response=""
Authentication Scheme: Digest
Nonce Value: “”
Authentication URI: “sip:ims.mnc01.mcc001.3gppnetwork.org”
Realm: “ims.mnc01.mcc001.3gppnetwork.org”
Username: “[email protected]”
Digest Authentication Response: “”
CSeq: 8 REGISTER
Sequence Number: 8
Method: REGISTER
Via: SIP/2.0/UDP 192.168.1.51:5060;branch=z9hG4bKGnaGQUEokv7DJrR;rport
Transport: UDP
Sent-by Address: 192.168.1.51
Sent-by port: 5060
Branch: z9hG4bKGnaGQUEokv7DJrR
RPort: rport
Allow: ACK,BYE,CANCEL,INFO,INVITE,MESSAGE,NOTIFY,OPTIONS,PRACK,REFER,UPDATE
Supported: 100rel,path,replaces
Max-Forwards: 70
User-Agent: iOS/10.3.1 (14E304) iPhone
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=001010102000ff0b
Content-Length: 0
And attached here is a picture equivalent of the above packet content.
Would you or anyone else be able to, at minimum, identify problems with the register message to see if we can work from there? If not, this might be a lost cause unless I can modify the SIM card for the UE.
You are trying to register to port 5060 , this is the port that pjsip uses.
Are pjsip extensions the numbers that you are trying to register?
Post your freepbx configuration, one from a zoiper extension and one that you are trying to use through volte.
Note that for all extensions, I am using the same dummy password and default settings, except for adding the SIP alias accordingly; this includes the UE extension.
As mentioned before, is it possible that the UE is looking to use the legacy CHAN-SIP on port 5060 instead? The only issue I have in believing this is the issue is that it doesn’t make sense since VoLTE is so new compared to SIP, so it would more likely be using PJSIP. That being said, I won’t rule it out as a potential issue.
Here’s what I found by preforming numerous Ping Tests in both directions while also capturing what was happening using Wireshark and a hub:
If I Ping from the UE to the FreePBX computer, I get no reply from the FreePBX computer.
If I Ping from the FreePBX computer to the UE, I get a late reply, which causes the UE to throw a ping request timeout.
By Observing the packets sent by the UE, the UE is unnecessarily trying to route itself through our Cisco router first (as seen in the Eth II section of a packet) before arriving at its final destination, should it even get there.
Alternatively, the packets sent by FreePBX are directed straigtht to the UE (as seen in the Eth II section of a packet).
By the looks of it, it seems to either be an issue of our instrument (aka the Agilent PXT E6621A Wireless Communication Test Set, which runs Windows XP), or the UE itself wanting to route all of the UE’s packets unnecessarily to the router, regardless of there final destination, even if on the same LAN.
Because of this, I will look into seeing if I can correct this matter to see if it changes anything in terms of getting a response from FreePBX. If you would like, I can post either the icmp packet info or a link to the pcap should you want it.
Edit: I found out that the packet is being stopped from doing anything within the LAN by the router because its violating the router’s access list rules.
Edit 2: I looked into it even deeper by using tcpdump on FreePBX computer and it looks like the FreePBX computer is not responding to it, despite receiving the packet. Oddly enough, the only devices accepting and responding to the pings are the Sniffer I have been using alongside FreePBX (which I also use as its GUI interface, which is always up for monitoring purposes), and the router; all other computers either never receive it or simply don’t respond.
Good news! I found out that it was the E-EPCE setting that controls the gateway and address(es) of the phones connected to the PXT. Instead of having the gateway set as our router, I needed to set the gateway as the FreePBX server. The annoying part about that is that I need to re-type it in each time I connect the UE.
Now comes the fun part. Even though I am now getting a successful request and reply between the two entities, the UE is not changing its Authorization Header to match that of the 401 message it supposedly receives, unlike all of the clients I’ve used (including Agilent’s Client). With that in mind what can I do? I know that FreePBX doesn’t have the ability to change the realm name (at least not yet), and that the password/username fields of the authorization can’t be left blank by the Client. Any recommendations? I would hate to do this and I am not even sure if I have the resources to do it, but I may need to reprogram the Gemalto LTE Advanced UICC SIM card that the UE is using because of this authorization issue, if that’s even the problem. Any recommendations are greatly appreciated.
