In src/h460/upnpcp.cxx (line 62)

#define UPnPUDPBasePort 55000

 

The separate allocation of ports for UPnP was done for a reason. The allocation of ports in UPnP is hit and miss. You ask for a port the router will tell you yes or no. In high use existing port ranges such as 1000 -1100 it may take several seconds to iterate through the range and find 2 unmapped sequential port pair . There is no known way to prompt a router to give you all the port mappings or even get the router to give you the port on the outside that is the same as you sent from the inside. STUN has this issue so even if you originate from port 1000 the router may map some other port like 4000 on the outside. UPnP does report to the endpoint ALL the UPnP mappings (including any new ones created while the endpoint is running) so you know with a bit of certainty that in a low use, high port range like 55000 that when you open, what you thing is a free port, that you will be able to get that 1-1 mapping from inside port to outside port on the first UPnP mapping request. This is very important as you don’t want to be waiting during call establishment (maybe seconds) for UPnP to find an available mapping.

 

In the first iteration of UPnP some years back I had to create a thread to create the port mappings in the background before you even made the call as it would take up to 5 sec to find a suitable free UPnP mapping. Remember it’s not just 1 or 2 mappings it has to do but 8  (Audio,Video,FECC, H.239) . Knowing with some certainty that the map request will work the first time honestly is the only way UPnP can be useable in Video Conferencing.  

 

If you are concerned about ports you should look at H.460.19 Multiplexing with GnuGk then you only need 2 port. H323plus uses 1776-7 and GnuGk uses 3000-1 by default.

 

Simon

 

 

From: J.C Mercier [mailto:jcmerc5@gmail.com]
Sent: 06 February 2012 05:13
To: Simon Horne
Cc: h323plus@lists.packetizer.com
Subject: Re: [h323plus] Minor issues with upnp

 

Thanks Simon and all,

I've tested the simpleplus app and it seems to function well except for one thing. When I have my RTP ports set to 10000 - 11000, when I make a call, the upnp only maps to 55000 - 55003 both internal and external ports. Therefore i'm not able to receive any audio or video because 55000 - 55003 are not the ports that i configured.  In h323rtp.cxx i noticed a call;

WORD firstPort = endpoint.GetRtpIpPortPair();  etc.. then a call to open the ports;

  while (!rtp.Open(localAddress,
                   nextPort, nextPort,
                   endpoint.GetRtpIpTypeofService(),
                   conn,
#ifdef P_STUN
                   meth,
#else
                   NULL,
#endif
                   rtpQos))

which should retrieve the ports that i had set (between 10000 - 11000) but this doesn't seem to work accordingly and uses different local ports (55000 +).

Any ideas why this could be the case?

Thanks for all your help.

Josh

On Sun, Feb 5, 2012 at 10:42 AM, Simon Horne <s.horne@packetizer.com> wrote:

Josh

 

I have checked in fixes to ensure both UPnP test Mapping are deleted and also removed a double delete that was causing a segfault at shutdown.  I also added UPnP support to simple.

 

You should see this in the tracelog when UPnP creates the maps for RTP/RTCP ports

2012/02/06 01:34:43.080               4                    upnpcp.cxx(480)        UPnP     Created map UDP 192.168.1.3:55000 to a.b.c.d:55000

2012/02/06 01:34:43.122               4                    upnpcp.cxx(480)        UPnP     Created map UDP 192.168.1.3:55001 to a.b.c.d:55001

2012/02/06 01:34:43.122               3                    upnpcp.cxx(1186)      UPnP     UDP mapped ports 192.168.1.3 55000-55001 to a.b.c.d 55000-55001

2012/02/06 01:34:43.122               4                      h323.cxx(2579)          H323      RTP NAT Connection Callback! Session: 1

2012/02/06 01:34:43.122               4                       rtp.cxx(1482)            RTP        NAT Method UPnP created NAT ports 55000 55001

 

Simon

 

From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of J.C Mercier
Sent: 05 February 2012 08:47
To: h323plus@lists.packetizer.com
Subject: [h323plus] Minor issues with upnp

 

Hi all,

If i may first note, I've compiled the latest h323plus with no problem, but when i go to compile the simpleplus program, it gives an unresolved error for H46019UDPSocket::GetPeerAddress(...).   This happens because H323_H46024A and H323_H46024B are disabled and GetPeerAddress is defined within H323_H46024A but declared within H323_H46019M. I did a minor work around and it now compiles fine.

Another issue I came upon, when I initialize UPNP during the h323 initialization, during the UPnPThread::TestMapping()  function call, it manages to map both ports (11000 and 11001) but after calling         RemoveMap(extPort,true);  and  RemoveMap(extPort+1,true), only 11001 is removed and not 11000. I tested this with different port range and it produces the same results (one unmapped and not the other). Is this supposed to be the case or is something wrong somewhere?

Although, after closing the program, both ports are unmapped successfully. But another problem that happens every time I close the program is a memory access violation at;

    ~IxNATNumberOfEntriesCallback() { delete m_pointer; } from

interface IxNATNumberOfEntriesCallback : public INATNumberOfEntriesCallback

Any reason why this could be the case?

Lastly, when upnp is initialized, making a call doesn't seem to open and map the ports at all. What else should be done aside from initializing upnp?

Your help and suggestions will be greatly appreciated.

Thanks

Josh