Remote Extensions Dropping Calls


#21

Unfortunately I don’t understand what you mean. Can you help those who opened the post?

p.s. My name is Damiano, and not Damino :slight_smile:


#22

Ok very well Damiano … I will make it very simple so you may understand.

can you post an example of an appropriate ACL rule when using a softphone application on a mobile device.

A sort of best practice this with be of great help and much appriciated especially if a vpn is not possible.

Thank you in advance


#23

in fact, I was talking about remote interiors in a generic way, let’s say the same thing. The ACL rules should ALWAYS be applied.
Of course, on mobile interiors (with dynamic ip of the mobile operator) is always an adventure to do so. But the general rule is that.
It seems to me that we are more or less saying the same thing :slight_smile:


#24

And Grandstream is saying the exact opposite - always enable NAT on the extension

If you disagree, that is your right. As a Forum Moderator, in this instance, I am expressing their official position as taught in the Grandstream Academy in their Grandstream Certified Professional certification course.

Enough said.


#25

I don’t contradict anyone, on the contrary I like learning.
They’ve always taught me the opposite, now I’ll check and let you know.
No one “is born learned”. It always takes humility in life.


#26

Lets all agree to disagree here Damiano you seem like a very nice guy very knowledge but you sometime come across a bit harsh but I think you mean well. A lot of us here are professionals we do this for a living and unfortuanly with the good pricing of Grandstream prodcuts every second person attempts to do it themselves we try to help a lot of DIY attempts casue simply put these people give GS a bad name and make it harder to sell these solution to business well at least that is true where We practice so it easy to see why you get frustrated or give very brief pointers casue any profession shoul dbe able to pick up fromt the point and you not about to give a full tutorial I think that is also fair and actually correct.


#27

@Telecomsolutions, I struggle to understand what you want to tell me but it is not a problem, I repeat, I like learning and I am very humble.
As I said above I want to verify that thing that interests me, once I get the answers I will know how to behave.


#28

While all this has been entertaining, I am not sure if there is a consensus on what are appropriate settings that would end the call drop of remote extensions. NAT on or off on the remote devices? NAT on as STUN or Keep Alive? UCM setting of the SIP ToS RTP Keep Alive set to 1, do we not need to port forward the RTP and/or BFCP ports?


#29

on remote extensions it is necessary to activate NAT on the extension and do NAT on the Firewall of the SIP and RTP ports. Also, make sure there is no ACTIVE SIP ALG.
on the remote extensions that are registered on VPN it is not necessary as they are seen as local extensions.

My doubt that you read above is only if you activate or not the NAT on UCM in the extension settings in case of local extension.But it is a doubt that does not concern your problem if you do not use the extension via VPN.


#30

The issue with using the NAT setting in the extension settings in the UCM -
If the system is set up correctly and the local network is added to the SIP Settings, NAT…

Then you can leave NAT checked on all extensions as the UCM will formulate the messages correctly to either external or internal devices based upon what the UCM sees as the source IP for the devices in question.

This is the preferred method when the UCM is behind a NAPT router (which IMO it should always be) and possibly why GS suggests that it should always be set as it eliminates the issues associated with remote devices that might be installed in the future. If you have no need for remote devices, then you can leave the setting off, but you still need to have the local network made known to the UCM. As it will never see a non-local IP, the NAT setting in the UCM has no bearing at that point. I typically leave it on as there is no harm, no foul in doing so.

If you use a VPN for remote devices, the remote network LAN should also be entered into the SIP Settings, NAT section in the UCM.

The notion that SIP ALG should always be off is incorrect. While many or most manufacturers seemingly break SIP when the function is enabled, not all do. But I do admit that that these are few and far between and I always start with it off and then wireshark it to see if the messaging is correct. Ubiquiti was reportedly one such router who handles it correctly, but I have no personal experience with it.


#31

I think this give one of the best understanding for the use of the word NAt on asterisk its gets confusing simply becasue we know NAT rewrites an adress so when you click nat on the ucm are we to understand that by the very definition of nat the the UCM/Asterisk is going to rewrite a local IP and perform a mapping the same way a nat device does.

NO… enabling the NAT option on the extnesion is not going to do any type of nat it is a way for the extension to let the Asterisk server know that is is behind a Nat device and so please ignore any Ip address that you see in any messages and send audio to me form where you receive it.


#32

Telecom -

Was the response defining NAT meant for me?


#33

No in addition to what you said


#34

Not a problem. Your post got me to thinking about it.

I seem to recall that when the UCM first came out, the setting did alter the messaging with regard to contact and connect, but then as this was back when the UCM was on version 1.X or whatever of Asterisk and many firmware changes since, I could very easily be wrong.


#35

ouliwei -

To your point, the number of settings is rather vast, but this is due to the various conditions that the devices have to overcome in order to communicate effectively with one another. In many cases a given setting may not add any value, but it may not harm the effort either. When you consider that there are two ends and the amount of control that you may have over either end and even the in=-between may vary, there may be more than one way or different settings to get the job done (connected and communicating).

Is one method more correct than others, yes. But over time and as things change and more people get on board with the SIP train, there is a lot of anecdotal info that comes into being about how this person or that person was able to succeed where others had failed. Once that method is revealed, then somehow it becomes an accepted solution, even though there may be a more efficient and reliable way if done correctly.

No one will dispute that a VPN is best for a remote connection. It offers security and extends the local network to the remote device. As all appears local, there is no need for STUN, no router settings to adjust and, keep-alives are not needed. It is no different than setting an extension on the same LAN as the UCM, only you do need to enter in the remote LAN private LAN segment into the SIP Settings, NAT, Local network so that the UCM will know that the device is local (via the VPN) rather then truly external.

If you were external and not on a LAN, then STUN might be used, but again it depends on the scenario. If you have static IP at both ends, have control of the routers and know the IPs related to both ends, then STUN is not needed. STUN is (in simple terms) used when you may not be able to control the routers and need help in determining and overcoming NAT issues that you can’t do on your own. Would STUN hurt? Perhaps not, but this then goes back to the most efficient part of the solution, If it is not needed, then why invoke it? The same thing with keep-alives. This sends packets as specific intervals to a) keep router ports open and b) see if the other end is alive. On a VPN, they should not be needed, but again there is no harm in doing so provided that the amount of traffic generated by all the devices set this way is not such that it floods the PBX or causes congestion. It is unlikely that they would as they packets are small, so not too much risk really.

NAT on the extension can be ON or OFF. as Telecom and I indicated in our discussion. If you have the local (including VPN) networks defined, then NAT can be enabled with no issue. Keep in mind that it is possible to have two phones with the same extension number with one being local, the other remote which does not have a VPN. So, what a conundrum, one side says yes, the other no, what to do? (YES)

IN any event, have fun and good luck.