How to change sip signaling port to 5060 from 11000 or remove from invite

[Nigel Johnson]

Hello, I'm trying to connect to the carrier Thinq (formally sip routes) and they only accept on 5060. They also said i could remove the port from the invite. Is there a recommended way to either change the port to 5060 or remove it from the invite ? 

[arri...@gmail.com]

You need to update your sipinterface_1.xml config on your freeswitch server to switch this port.  Make sure you also update your kamailio load balancer to match the new port number.

The line in freeswitch config you are looking for is:

<param name="sip-port" value="11000"/>

Change it to:

<param name="sip-port" value="5060"/>

Then in your kamailio dispatcher file, change the port 11000 value to 5060.  The end result should look like this:

1 sip:<ip address>:5060 2

1 sip:<ip address>:5060 2

[Nigel Johnson]

That did it, you wouldn't happen to know why its 11000 instead of 5060 in the first place would you ? Is it going to interfere with something if i change it ?

[Darren Schreiber]

This is not about obscurity.

See:

https://groups.google.com/forum/#!searchin/2600hz-dev/$20darren$20port$2011000/2600hz-dev/pE0apd7cPhE/nONR2fNyq1gJ

Here’s a re-post of what I wrote:

"The default behavior is to route calls from the FreeSWITCH box when going outbound. This has a number of benefits:

1) You’re avoiding a silly extra hop via Kamailio for no reason, in terms of load

2) You’re simplifying debugging - your outbound calls and server to server traffic are also going to be on port 11000, your inbound traffic is always on 5060

3) You’re allowing restarts of Kamailio without impacting calls setup on the outbound side, and if phones are using UDP then all should go unnoticed

4) You can more simply setup your firewalls. You can have a standard rule to open 5060 on all boxes (it will be useless on the FreeSWITCH box which doesn’t listen on that port) and only open 11000 to carriers.

5) You end up with different IPs for Orig & Term, which some carriers require

6) Your media servers are masked from people who aren’t customers on your system, decreasing likelihood of a DoS attack directly on the media servers (they will still attack the Kamailio servers but that won’t break anything if your internet links are on different providers between media & Kamailio)

The downside, of course, is most people have more FS boxes than Kamailio boxes, which means more IPs to give to the carriers. And the config to the carrier might be more complicated, depending on the carrier."

One more thing I forgot in the previous post about this – you’re allowing an all-in-one installation to work on a single box without conflicting ports.

From: Garey Arrington <arri...@gmail.com>
Reply-To: "2600h...@googlegroups.com" <2600h...@googlegroups.com>
Date: Thursday, March 12, 2015 at 3:49 PM
To: "2600h...@googlegroups.com" <2600h...@googlegroups.com>
Subject: Re: How to change sip signaling port to 5060 from 11000 or remove from invite

I couldn't say for sure why it is 11000 by default. I'm guessing it is that way because 2600hz uses that for their own internal reasons. It could also be for security. Security through obscurity.

If you changed it in the two places I mentioned then you won't have any conflicts. 

On Mar 12, 2015, at 5:01 PM, Nigel Johnson <njohns...@gmail.com> wrote:

That did it, you wouldn't happen to know why its 11000 instead of 5060 in the first place would you ? Is it going to interfere with something if i change it ?

--
You received this message because you are subscribed to a topic in the Google Groups "2600hz-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-dev/h7qWnX7WR5Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 2600hz-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "2600hz-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Garey Arrington]

Darren,

In our original setup we noticed that due to this configuration we were advertising port 11000 to carriers on outbound traffic which did cause some carriers to be unable to route signaling back to us. 

Freeswitch wasn't listening on 5060 and therefore couldn't receive inbound calls from carriers that will not route calls on the non-standard port. From what you've posted here you're suggesting that shouldn't have been an issue. 

[Darren Schreiber]

Hi Garey,

Let me clarify further.

1) OUTBOUND calls from the platform come from FreeSWITCH on port 11000 to your carrier, by default. For some carriers, for extra security, you must tell them that you will be terminating traffic to them from port 11000 or they’ll reject it. (Load balancing has already occurred by the time you get to the B-leg or an originated leg via click-to-call so it’s no big deal that this doesn’t come from Kamailio, and you’ve simplified the routing per the reasons I listed earlier in this thread)

2) INBOUND calls from your carrier to the platform should come to Kamailio on port 5060 or port 7000, by default. This will allow the load-balancing of inbound calls to work properly.

3) For some carriers, they don’t like that your INBOUND and OUTBOUND IPs are different (and, ironically, for others, they require that they be different). This, to me, is a “stupid lazy carrier” issue in my opinion (and yes, it’s an opinion) because from what I’ve seen all carrier equipment actually will handle this, but many times the engineer in charge of configuration doesn’t know how to do it, or his processes don’t allow for it, thus they tell you it’s not possible. Usually you can make a stink and they’ll set you up a workaround (sometimes two “trunk configs”, one for inbound and one for outbound, and two separate bills)

4) There is a hack out there where you can route your outbound calls via Kamailio but I refuse to re-post it because it defeats redundancy and strikes me as silly. However, feel free to scan the list for people talking about fs_path because it does work, but it’s just so nasty I refuse to repeat it… We are working on more formal support for this (that’s not a hack) so that you can just give your carriers the same IP for inbound & outbound, simplifying setup, but frankly I still think separating out the inbound from outbound is better (per the reasons that I, again, listed earlier in this thread)

There is a lot of my opinion which is based on experience in this reply. I’m sorry if it’s not what people want, but I am actually trying to help ya’all ;-)  If you have suggestions on how we could do better without giving people too much rope to hang themselves with other problems down the line, feel free to comment.

[Nigel Johnson]

Thanks Darren that helps a lot