Using FreePBX 13 with a Mock Cellular Network

pjsip
configuration
freepbx
Tags: #<Tag:0x00007f70324db968> #<Tag:0x00007f70324db198> #<Tag:0x00007f70324da810>

(Sean Caldwell) #12

Could a potential issue be that the UE is looking to use the legacy setup (aka CHAN_SIP) instead of PJSIP over the port 5060?


(Dave Burgess) #13

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.


(Sean Caldwell) #14

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:001010123456789@ims.mnc01.mcc001.3gppnetwork.org
SIP to address: sip:001010123456789@ims.mnc01.mcc001.3gppnetwork.org
SIP to address User Part: 001010123456789
SIP to address Host Part: ims.mnc01.mcc001.3gppnetwork.org
From: sip:001010123456789@ims.mnc01.mcc001.3gppnetwork.org;tag=poW1v0IapZ
SIP from address: sip:001010123456789@ims.mnc01.mcc001.3gppnetwork.org
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="001010123456789@ims.mnc01.mcc001.3gppnetwork.org",response=""
Authentication Scheme: Digest
Nonce Value: “”
Authentication URI: “sip:ims.mnc01.mcc001.3gppnetwork.org”
Realm: “ims.mnc01.mcc001.3gppnetwork.org
Username: "001010123456789@ims.mnc01.mcc001.3gppnetwork.org"
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.


(Ast Box) #15

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.


(Sean Caldwell) #16

Yes, If you are referring to the UDP and TCP ports being set to 5060 for PJSIP, otherwise I don’t understand the question here.

Below this line is the ZoiPer Registration, my previous post is the VoLTE (UE) registration:


No.: 194
Time: 1175.715363000
Source: 192.168.1.230
Destination: 192.168.1.12
Protocol: SIP
Length: 927
Info: Request: REGISTER sip:ims.mnc01.mcc001.3gppnetwork.org;transport=UDP |
Frame 194: 927 bytes on wire (7416 bits), 927 bytes captured (7416 bits) on interface 0
Interface id: 0
Encapsulation type: Ethernet (1)
Arrival Time: Jun 8, 2017 13:06:55.718186000 Eastern Daylight Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1496941615.718186000 seconds
[Time delta from previous captured frame: 0.004716000 seconds]
[Time delta from previous displayed frame: 0.004716000 seconds]
[Time since reference or first frame: 1175.715363000 seconds]
Frame Number: 194
Frame Length: 927 bytes (7416 bits)
Capture Length: 927 bytes (7416 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: HewlettP_12:54:99 (6c:3b:e5:12:54:99), Dst: DellEsgP_5c:52:19 (00:18:8b:5c:52:19)
Destination: DellEsgP_5c:52:19 (00:18:8b:5c:52:19)
Address: DellEsgP_5c:52:19 (00:18:8b:5c:52:19)
… …0. … … … … = LG bit: Globally unique address (factory default)
… …0 … … … … = IG bit: Individual address (unicast)
Source: HewlettP_12:54:99 (6c:3b:e5:12:54:99)
Address: HewlettP_12:54:99 (6c:3b:e5:12:54:99)
… …0. … … … … = LG bit: Globally unique address (factory default)
… …0 … … … … = IG bit: Individual address (unicast)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 192.168.1.230 (192.168.1.230), 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: 913
Identification: 0x57c1 (22465)
Flags: 0x00
0… … = Reserved bit: Not set
.0… … = Don’t fragment: Not set
…0. … = More fragments: Not set
Fragment offset: 0 Time to live: 128
Protocol: UDP (17)
Header checksum: 0x5b58 [correct]
[Good: True]
[Bad: False]
Source: 192.168.1.230 (192.168.1.230)
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 137.148.142.230:36980;branch=z9hG4bK-524287-1—61edde72e1538681
Transport: UDP
Sent-by Address: 137.148.142.230
Sent-by port: 36980
Branch: z9hG4bK-524287-1—61edde72e1538681
Max-Forwards: 70
Contact: sip:1234@137.148.142.230:36980;rinstance=4f6d67cb2fe04348;transport=UDP
Contact URI: sip:1234@137.148.142.230:36980;rinstance=4f6d67cb2fe04348;transport=UDP
Contact URI User Part: 1234
Contact URI Host Part: 137.148.142.230
Contact URI Host Port: 36980
Contact URI parameter: rinstance=4f6d67cb2fe04348
Contact URI parameter: transport=UDP
To: "Sniffer"sip:1234@ims.mnc01.mcc001.3gppnetwork.org;transport=UDP
SIP Display info: “Sniffer”
SIP to address: sip:1234@ims.mnc01.mcc001.3gppnetwork.org;transport=UDP
SIP to address User Part: 1234
SIP to address Host Part: ims.mnc01.mcc001.3gppnetwork.org
SIP To URI parameter: transport=UDP
From: "Sniffer"sip:1234@ims.mnc01.mcc001.3gppnetwork.org;transport=UDP;tag=d172a264
SIP Display info: “Sniffer”
SIP from address: sip:1234@ims.mnc01.mcc001.3gppnetwork.org;transport=UDP
SIP from address User Part: 1234
SIP from address Host Part: ims.mnc01.mcc001.3gppnetwork.org
SIP From URI parameter: transport=UDP
SIP from tag: d172a264
Call-ID: zw9xNMKebxqGKl_SezcLqg…
CSeq: 6 REGISTER
Sequence Number: 6
Method: REGISTER
Expires: 3600
User-Agent: Z 3.15.40006 rv2.8.20
[truncated] Authorization: Digest username=“1234”,realm=“asterisk”,nonce=“1496941610/3f843dbf9603c50d64f392810fdac64d”,uri=“sip:ims.mnc01.mcc001.3gppnetwork.org;transport=UDP”,response=“b3a66d551b7c15b60618aee6b4e60adc”,cnonce="98bf28e656e Authentication Scheme: Digest
Username: “1234”
Realm: “asterisk”
Nonce Value: “1496941610/3f843dbf9603c50d64f392810fdac64d”
Authentication URI: “sip:ims.mnc01.mcc001.3gppnetwork.org;transport=UDP”
Digest Authentication Response: “b3a66d551b7c15b60618aee6b4e60adc”
CNonce Value: “98bf28e656efd1c066cf148c9190bd2b”
Nonce Count: 00000001
QOP: auth
Algorithm: md5
Opaque Value: “417be2d97f44281b”
Allow-Events: presence, kpml, talk
Content-Length: 0


I will post the actual configurations made on FreePBX in my next post as it is on a different computer than the one I am using now.

Edit Sidenote: The Display name of the ZoiPer should actually be "Server"


(Sean Caldwell) #17

Here is the configuration I found out that was required for ZoiPer, this is the computer that has IP address 192.168.1.230:



And here is FreePBX itself:
General SIP (using default codecs):

CHAN-SIP:


PJSIP:


Extensions App:

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.


(Ast Box) #18

From the UE can you ping freepbx, if yes then ping the hostname. Post what you get.


(Sean Caldwell) #19

Here’s what I found by preforming numerous Ping Tests in both directions while also capturing what was happening using Wireshark and a hub:

  1. If I Ping from the UE to the FreePBX computer, I get no reply from the FreePBX computer.
  2. 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.
  3. 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.
  4. 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.


(Sean Caldwell) #20

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.


(Ast Box) #21

Try to register to freepbx and post new tcpdump from both units.


(Sean Caldwell) #22

Would you like a link to the pcap, or the packets?


(Sean Caldwell) #23

Here is the iPhone registration Attempt:

And here is the LG G3 VS985 registration Attempt:

Let me know if you have any issues accessing these files.


Edit: Any Ideas yet?

Edit 2: Is there any way to disable authentication instead or modify the authentication for this particular extension using the custom_*.config files?


(Kevin T) #24

Turn the firewall on and configure it. You won’t be able to get around it.


(Sean Caldwell) #25

The firewall was never the issue (I’ve even tried several configurations both with and without the firewall and found that enabling/disabling the firewall changes nothing [if you’re talking about responsive SIP accept, it doesn’t work in this case apparently]).

Instead, what seems to be the issue between the UEs and FreePBX is an authentication header mismatch. Since the UE’s are cellphones which use SIM cards, the authentication header is meant to be static from the phone, which means it can’t adjust to FreePBX’s md5 response like a softclient (software based client) can. This means I either need to find a way to change the SIM card’s authentication parameters (which I don’t think is possible), or change/disable the authentication parameters of FreePBX for the UE extension in which the UE is trying to register on. This is why I was questioning on whether or not it was possible to modify the custom_*.config files to accomodate the static nature of the UE’s authentication header.


(Kevin T) #26

My experience with Asterisk over LTE has been very good.

The mobile client is to install Grandstream Wave (with Video) and enter in settings sent to the mobile over text or email. Once setup is done we test audio AND video calls. During the audio tests we measure for any lag, make sure TLS is activated and working plus measure the actual audio quality. During video, we test for lag as well plus make sure the video actually connects. LTE has given us trivial problems that were taken care of by tuning the codecs and bit rates, but nothing major. The biggest problem with regard to LTE on my end has been the constantly changing IP addresses, so I had to tune my intrusion detection.

The next project will be using the OpenVPN over LTE and passing calls (and data) thru that.


(Sean Caldwell) #27

I would expect your experience with Asterisk/FreePBX to be very good with that setup. But that is where my setup differs. I am not using a soft client like you are. You are simply using an internet connection over LTE, which relies on a softclient to make internet calls instead of calls from the primary phone app. Instead, I am attempting to using the phones’ default built in VoLTE (and thus SIP) capabilities, which allow you to make calls and browse the internet simultaneously instead of using the usual CS-Fallback setup. Your setup seems to use the CS-fallback method, which is not what we are looking to test. We are looking to test an actual VoLTE connection, so that’s where our setups differ. Thanks for the pointers though.

Our Agilent PXT E6621A takes care of that issue.


(Sean Caldwell) #28

I’ve found out that the issue is that our setup & phone(s) only supports AKA or Early IMS registrations, and not standard MD5 (thus no reply). Is it possible to configure Asterisk to use AKA or Early IMS with that user?


(Tom Ray) #29

No. That’s not a thing Asterisk does. You’re going to need a softswitch or proxy that supports it.


#30

Probably you’ve already been to the site, and maybe it doesn’t help you, but take a look at openbts.org, which is a site that explains how to create a GSM network with a software defined radio that uses asterisk as the call processor, maybe you find useful info regarding the authenticacion process.


(Tom Ray) #31

May want to prefix this with “It only runs on 32-bit OS systems unless you want to try the new release which really hasn’t been fully tested”.

So in order to make this work, it requires an additional server running an out-of-date, unsupported OS