FreePBX | Register | Issues | Wiki | Portal | Support

PJSIP Port change doesn't work at hung up

configuration
freepbx
Tags: #<Tag:0x00007f74ac9ec9d8> #<Tag:0x00007f74ac9eeb48>

(Mike) #1

Hi,
I have change the PJSIP port of my freepbx to 5088. Now when I try make a call with a remote extension I’m not able to hung up the call (only when the call is ended with the remote extension). So I started to log the traffic with wireshark. I found out, that the “BYE” request is sent on port 5060 although I changed it to 5088.
Do you know why? Can I change it?
Thank you!


(Itzik) #2

Did you reboot (or at least restarted Asterisk) after you changed the port?


(Mike) #3

Thanks for your answer!
Yes, I did.
The extensions are able to conntect to Asterisk on port 5088. Only the “BYE” request uses port 5060…


(Dave Burgess) #4

What software versions are you using? The reason I ask is because there was a problem just like this reported about a year ago that I thought was fixed in newer versions.


(Mike) #5

I have tested it with MicroSIP for Windows, CSipSimple for Android and a Grandstream SIP-Phone. But nothing of these 3 SIP-clients are able to end a call correctly.


#6

At the Asterisk console, type
pjsip set logger on
and make a failing call.
Or, look at the traffic with Wireshark.

If the Contact header of the 200 OK sent from the PBX to the client doesn’t show port 5088, then the problem is at the PBX end and trying another client can’t possibly help.


(Mike) #7

Hi Stewart,

this are my logs:

Thank you!


#8

OK, so the PBX correctly put port 5088 in the Contact header. I suspect that the router/firewall on one end or the other has a SIP ALG that is corrupting the information.

Check the firewalls at both locations and try turning off anything related to SIP ALG.

If no luck, we need to capture traffic at the client to see where things are going wrong. That’s easiest with MicroSIP (you can just run Wireshark on the Windows PC), though I know nothing about that app. CSipSimple also has a logging feature you might try. Select Help -> Record logs …, make the failing call, then select Help -> Stop recording … and send the log to your own email (not the app developers).

Look at whether the 200 OK arrived intact and whether the BYE was correctly sent to port 5088.

If you can’t make sense of the log, post the relevant section here, as well as a description of the routers/firewalls at both locations.


(Mike) #9

Hi Stewart,
now (while testing) I found out that the problem doesn’t exists while it is “ring”. So if I end a call while ringing, everything is ok and the call will be end successfully. But once the opposite answered, I’m not able to end the call.
Unfortunately wireshark doens’t show the BYE… If I click “end call” on MicroSIP, nothing happens in wireshark.
SIP ALG is disabled on Server-side. The client-side has no NAT, so there is no ALG.

What’s wrong with my Asterisk…:roll_eyes:


(Avayax) #10

So you have a remote client outside of your network and if that remote party hangs up the call ends correctly?
What’s the second client, a device on your network or also remote?


(Mike) #11

I have device A, which is a remote client outside of my network - it is connected at port 5088 to my Asterisk. Device B is a simple mobile phone with GSM (for example).
Now if I hang up the call on device A, nothing happens and the call is still connected. If I hang up the call on device B, the call ends correctly.


(Mike) #12

Here is the BYE which doens’t work:


(Avayax) #13

So that’s the BYE that your remote client A is sending and which you captured at the remote end?
Yes, so the next step is to find that BYE on your firewall in front of your PBX, and see if it gets forwarded correctly.


(Mike) #14

Now (for testing) I have installed a MicroSIP-Client inside of the Asterisk-network. In iptables on Asterisk I set all traffic on port 5060 (input) to DROP and made a call from the local extension to a mobile phone. There is the same problem! So I think this couldn’t be a firewall/NAT problem, isn’t it?
Thank you!


#15

Do you really have a Windows PC on a public IP address? That seems both difficult to set up and dangerous. And, given that the Via header has 192.168.x.xxx, it seems pretty likely that the PC has a 192.168.x.xxx private address. At a Windows command prompt, type
ipconfig
to see the local IP address.

Please describe the networking at the remote site (modem make/model, separate router, if any).

The To: header has a 172.22.x.x address in it. Do you recognize what this might represent (at either end of the link)?

In MicroSIP account settings, try setting Public address to the 192.168.x.xxx local address of the PC, STUN server (blank), and ICE unchecked.

At this point, it would be useful to see captures taken at both the PC and the PBX for the same call.

The normal flow is:

  1. PC sends INVITE.
  2. PBX responds 401 UnAuthorized.
  3. PC sends ACK.
  4. PC sends INVITE with Authorization header.
  5. PBX responds with various status packets (Trying, Ringing, etc.).
  6. PBX responds with 200 OK.
  7. PC sends ACK.
  8. (conversation takes place.)
  9. PC sends BYE.
  10. Normal response to BYE would be 200 OK but we know that’s not happening.

Please make sure that your capture at both ends includes at least steps 4, 6, 7 and 9. If you can post the entire call, that would be great.

Also, note that most issues that would cause BYE to be misdirected would also affect the ACK in step 7, which would result in the call dropping after about 32 seconds. Please confirm that if neither party hangs up, conversation can proceed for at least one minute.


(system) closed #16

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.