Menu
▾
▴
Re: [Iaxclient-devel] re: iaxclient source ports
|
From: Frik S. <fr...@ga...> - 2006-03-27 14:02:21
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> This logic can be implemented at the application level or in the library. Implementing this logic in the library has some challenges and leaves room for bugs. <br> <br> I have a patch to the library that allows developers to add it to the application level, because today it is impossible without a patch to the library. I am happy to contribute my patch as is or leave it to someone else to come up with an elaborate solution. :)<br> <br> Andrew Pollack wrote: <blockquote cite="mid...@th..." type="cite"><br> <font face="sans-serif" size="2">Looking at typical use case --</font> <br> <font face="sans-serif" size="2"> </font> <br> <font face="sans-serif" size="2"> The default behavior should be to do the following:</font> <br> <br> <font face="sans-serif" size="2"> 1. Client attempts to listen on port 4569 fo requests as long as it is configured in a way which allows it to receive calls.</font> <br> <font face="sans-serif" size="2"> 2. Client should ALSO listen on the port it dialed out from, as this is the port the remote side should respond back to when at all possible.</font> <br> <br> <font face="sans-serif" size="2">There are three use cases for the client which dominate, the first is the overwhelming majority:</font> <br> <br> <font face="sans-serif" size="2">A. Use of the client in connection to a specific and predetermined switch service which establishes the connection -- usually an Asterisk box.</font> <br> <font face="sans-serif" size="2">B. Use of the client in connection to a public registry which provides the address and connection information to potential callers.</font> <br> <font face="sans-serif" size="2">C. Use of the client in a semi-random peer-to-peer manner.</font> <br> <br> <font face="sans-serif" size="2">In the case of A above, routing back to the source port is fully supported. In the case of B & C above, user sophistication tends to be considerably higher than in an end user product rollout and a level of firewall knowledge is not considered unacceptable. The user is in fact running as a server.</font> <br> <br> <br> <font face="sans-serif" size="2">---<br> Andrew Pollack<br> Northern Collaborative Technologies<br> 207-221-2547<br> </font> <br> <br> <tt><font size="2">Frik Strecker <a class="moz-txt-link-rfc2396E" href="mailto:fr...@ga..."><fr...@ga...></a> wrote on 03/27/2006 08:42:29 AM:<br> <br> > Andrew, Agree, but browsers are not both a client and a server. <br> > And if the client wants to listen for incoming point to point calls <br> > from other clients and not the server, even though registered to the<br> > server as described by Adrian, then you need to allow for a UDP <br> > stream to the server and another incoming from the client. I am <br> > not sure that this is a typical use case or not. This can be <br> > implemented, but my patch does not include that (because I believe <br> > in simplicity) and the simplest way to do it is to leave the default<br> > port at 4569. In the end, the developer will have the choice. So <br> > there is no issue per se. The only question is what to make the <br> > default behavior. Random source port or static 4569?<br> > <br> > Andrew Pollack wrote: </font></tt> <br> <tt><font size="2">> <br> > I fail to see why the behavior of iaxclient's source ports should be<br> > any different from any other udp based network application. The <br> > behavior is described in the TCP/IP standards documents and should <br> > not stray from that by default. Any changes to the default <br> > behavior of the operating system network stack configuration should <br> > at most be a configurable item and not a default. <br> > <br> > ---<br> > Andrew Pollack<br> > Northern Collaborative Technologies<br> > 207-221-2547<br> > <br> > <br> > <a class="moz-txt-link-abbreviated" href="mailto:iax...@li...">iax...@li...</a> wrote on 03/27/2006 08:20:42 AM:<br> > <br> > > Adrian,<br> > > <br> > > I believe you also made a good argument to make the default behavior be <br> > > the default 4569 port number instead of using random source ports.<br> > > <br> > > Kind regards,<br> > > Frik<br> > > <br> > > Frik Strecker wrote:<br> > > > Adrian,<br> > > ><br> > > > To be registered to a server (using a random source port) _and_ to <br> > > > listen for point-to-point incoming calls on port 4569, you are right <br> > > > you will need to listen on two ports. In this case you should simply <br> > > > use a fixed source port and things will work as they work today. The <br> > > > important thing is that the decision is up to the developer to decide <br> > > > what to do. Listening on both ports should not be a problem (even <br> > > > though this is not part of my patch), but will cause issues for <br> > > > running multiple copies of the software on the same PC (we do that for <br> > > > testing).<br> > > ><br> > > > Adrian Sietsma wrote:<br> > > >> Frik Strecker wrote:<br> > > >>> Adrian,<br> > > >>><br> > > >>> I am not suggesting changing the source port the client listen on <br> > > >>> for receiving incoming calls. I am only suggesting changing the <br> > > >>> source port for outgoing calls. This means that when one IaxClient <br> > > >>> calls another, it will use a random source port for outgoing and the <br> > > >>> remote client will receive a call on port 4569, but the destination <br> > > >>> port number in that case will be random. <br> > > >><br> > > >> But since the current client can only listen on one port, which one <br> > > >> does it listen on ? The new call packets will be coming in on your <br> > > >> (random) source port; any other incoming calls would be on 4569.<br> > > >><br> > > >> I agree with the theory, but the client would need to be listening on <br> > > >> more than one port to still see incoming calls.<br> > > >> I actually investigated this option : allow a per-connection port, <br> > > >> and listen on all of them, but it was too big a mod to be worth it.<br> > > >><br> > > >> note : this is not the case if the client only recieves calls from <br> > > >> servers it has registered with, as _all_ the server traffic will be <br> > > >> on the new (random) port. This is how I have one office setup : I <br> > > >> have an asterisk server that gets all incoming calls (on 4569) and <br> > > >> farms them out to registered clients inside the network.<br> > > >><br> > > >>> This will allow you to have more than 1 client behind the same NAT <br> > > >>> device receive incoming calls. Without this change, you will only <br> > > >>> be able to have a single client behind the NAT device receive a call <br> > > >>> at any time. So, this is actually good for the case you are promoting.<br> > > >><br> > > >> Without some form of registration, only one client can ever recieve <br> > > >> calls on a fixed port(4569) from behind a NAT, because the nat has to <br> > > >> map that port to a single machine.<br> > > >><br> > > >> A server (ie asterisk) changes the scene completely, because it in <br> > > >> effect maps the public port 4569 to the clients' registration port, <br> > > >> which could be anything.<br> > > >><br> > > >> I have seen the following (with one particular router which does PAT);<br> > > >><br> > > >> client A registers from private1:4569 via router(a.b.c) to asterisk <br> > > >> @ x.y.z<br> > > >> client B registers from private2:4569 via router(a.b.c) to asterisk <br> > > >> @ x.y.z<br> > > >><br> > > >> asterisk sees client A as a.b.c:4569, and the router maps that back <br> > > >> to private1:4569.<br> > > >> asterisk sees client B as a.b.c:another_port, and the router maps <br> > > >> that back to private2:4569.<br> > > >><br> > > >> In this scenario, both clients can accept calls from the asterisk <br> > > >> server, because the router handles the PAT. This is the same as <br> > > >> setting the 2 clients to use different ports.<br> > > >><br> > > >><br> > > >> Regards,<br> > > >> Adrian<br> > > >><br> > > >><br> > > >> -------------------------------------------------------<br> > > >> This SF.Net email is sponsored by xPML, a groundbreaking scripting <br> > > >> language<br> > > >> that extends applications into web and mobile media. Attend the live <br> > > >> webcast<br> > > >> and join the prime developer group breaking into this new coding <br> > > >> territory!<br> > > >> <a class="moz-txt-link-freetext" href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642</a><br> > > >> _______________________________________________<br> > > >> Iaxclient-devel mailing list<br> > > >> <a class="moz-txt-link-abbreviated" href="mailto:Iax...@li...">Iax...@li...</a><br> > > >> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/iaxclient-devel">https://lists.sourceforge.net/lists/listinfo/iaxclient-devel</a><br> > > ><br> > > ><br> > > ><br> > > ><br> > > > -------------------------------------------------------<br> > > > This SF.Net email is sponsored by xPML, a groundbreaking scripting <br> > > > language<br> > > > that extends applications into web and mobile media. Attend the live <br> > > > webcast<br> > > > and join the prime developer group breaking into this new coding <br> > > > territory!<br> > > > <a class="moz-txt-link-freetext" href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642</a><br> > > > _______________________________________________<br> > > > Iaxclient-devel mailing list<br> > > > <a class="moz-txt-link-abbreviated" href="mailto:Iax...@li...">Iax...@li...</a><br> > > > <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/iaxclient-devel">https://lists.sourceforge.net/lists/listinfo/iaxclient-devel</a><br> > > <br> > > <br> > > <br> > > <br> > > -------------------------------------------------------<br> > > This SF.Net email is sponsored by xPML, a groundbreaking scripting language<br> > > that extends applications into web and mobile media. Attend the live webcast<br> > > and join the prime developer group breaking into this new coding territory!<br> > > <a class="moz-txt-link-freetext" href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642</a><br> > > _______________________________________________<br> > > Iaxclient-devel mailing list<br> > > <a class="moz-txt-link-abbreviated" href="mailto:Iax...@li...">Iax...@li...</a><br> > > <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/iaxclient-devel">https://lists.sourceforge.net/lists/listinfo/iaxclient-devel</a></font></tt> </blockquote> <br> </body> </html> |