Sip Port For Rtp Media

[Christian]

Hi Guys,

I'm struggeling since wednesday with one of our SIP trunks - the Node4 one.

So far, neither me nor Node4 seems to have done any change. However since Wednesday, we can't hear the external person.

I figured out, that during connection (SIP status packet 200 OK), the LinkMgr requests to receive the RDP Mediastream on a specific port: 

 

SIP/SDF Status: 200 OK:

[...]

Media Description, name and address (m): audio 17267 RTP/AVP 8 101

[...]

 

in result to this message, node4 tries to send the RTP stream to 17267 - but unfortunately the LinkMgr isn't listening on that port.

 

Does anyone has an idea of what causes this issue and how it could be solved?

 

many thanks in advance!

[Virikas]

LinkMgr uses UDP 55.000-56.000 per default (can be configured via Reg Keys)

If not that ports may be blocked on your machine.

That might happen if e.g. a DNS Service is running on the same machine, which uses these ports by default too. It won't happen everytime and in fact is based mostly on a "first come, first serve" behaviour.

 

To check which dynamic udp ports will be used by windows and windows services itself:

netsh int ipv4 show dynamicport ucp

To change that to start from port 20025 (reserving +3975 ports fom there on):

netsh int ipv4 set dynamicport udp start=20025 num=3975 store=persistent

After that a restart of all services that might use these ports AND the linkmgr afterwards is required (in practice a fresh reboot is the cleanest way to do both of that)

[Christian]

Hi Virikas,

many thanks for your prompt response!

I've discoverd that is seems to be caused by the STUN server / external IP discovery.

 

09 13:26:10.494 00291c Inf3 STUN       005FE2C8 00000000 SSTUNSocket::DiscoverExternalAddress    () New external IP/Port discovered: Old=127.127.127.127:29808 New=62.154.242.220:31206

09 13:26:10.494 00291c Inf3 STUN       005FE2C8 00000000 SSTUNSocket::DiscoverExternalAddress    () external IP:Port=62.154.242.220:31206

09 13:26:10.505 00291c Info LinkMgrCtl 059C19A8 0002001a SLinkMgrCall::AllocateOwnMediaPar       () Use STUN external IP/ports=62.154.242.220:31206/41545

09 13:26:10.505 00291c Info LinkMgrCtl 059C19A8 0002001a SLinkMgrCall::AllocateOwnMediaPar       () bStun=1  IP: 62.154.242.220|31206|55302|undefined|20|101

09 13:26:10.506 00291c Inf3 SwTCL      059C19A8 0002001a STclCall::SignalConnect                 (connd trunk 0, connd user 0, connected: '03300081005','C. Goebel 314', [0: IP: 62.154.242.220|31206|55302|G711a|20|101][no SDP, params modified], redirected: no) 05A9D0A0

09 13:26:10.506 00291c Info SwSIP      05A9D0A0 0002001a SwSIPCall::SignalConnect                () RECV SwTCL SignalConnect([0: IP: 62.154.242.220|31206|55302|G711a|20|101][no SDP, params modified], connected: '03300081005','C. Goebel 314', redirected=no<empty>, (UserID: 27 Site: {955C07B9-8C3D-4287-8868-AF79689BC7FF} SessionID:  ))

~m=audio 31206 RTP/AVP 8 101

09 13:26:10.540 00291c Info LinkMgrCtl 05AC6B20 0002001a SLinkMgrFSM::ActionConnect              <-> [A] 83.166.160.241  10808  G711a - 31206 |R| 62.154.242.220 - 192.168.100.18 |L| 55300 - G711a S  50328  192.168.101.80

~m=audio 31206 RTP/AVP 8 101

The Port suggested in the SIP package by the LinkMgr is always the same as the port behind "Use STUN external IP/ports=62.154.242.220:31206"

If I disable STUN, the LinkMgr uses again ports between 55000 and 56000. However in this case, the wrong ip is signaled to the trunk provider.

 

Any suggestions on how to solve that?

[Virikas]

Sorry, as we don't use NAT traversal I'm not deep enough into STUN to provide an answer

[Christian]

So, problem has been sorted.

The problem was an update within the firewall, which removed the "static port" rule for our netphone server. static port means, that the firewall uses the same port for forwarding traffic to the internet, as the netphone server did.

Without that option, the STUN Server discovered the the port used by the firewall, which is completely random. this caused to problems:

1. it's almost impossible to setup a proper port forwarding in the firewall

2. the linkmgr stucks listening on port 5500x, so the RTP stream couldn't be received even if the firewall would forward the packets.

After telling the firwall to use the same port as the netphone server, everything is works fine again.