IMO every SIP client (not servers) should use a random port as default. This is also a security feature - nobody except the registrar need to know the port used by the SIP client.
Nevertheless, having an "advanced option" to configure a static port may be useful, e.g. for testing purposes. regards klaus Chris Maciejewski schrieb: > Hi, > > Just checked the following softphones: Twinkle, Ekiga, Xlite, Kphone > and ALL of them by default listen on port 5060. Also all (but Kphone) > allows to manually adjust port number via "System/Settings" kind of > dialog. > > However I can't think of any practical reason why the phone should not > use any other port number? > > Regards, > Chris > > 2008/8/7 Darshaka Pathirana <[EMAIL PROTECTED]>: >> Hi! >> >> On 07.08.2008 14:05, Vadim Lebedev wrote: >>> If i remember correctly SIP RFC reccomends this behaviour, >> I just checked the RFC (again) and found no sign of this >> recommandation. In fact I only found Chapter 18 (Transport) in the >> RFC3261[1] which is quoted like this: >> >> "Note that, because the source port is often ephemeral, but it >> cannot be known whether it is ephemeral or selected through >> procedures in [4], connections accepted by the transport layer will >> frequently not be reused." >> >> which makes sense because SIP is on top of TCP/UDP and should not >> interfere in transport layer matters... >> >> [1] http://www.faqs.org/rfcs/rfc3261.html >> [4] http://www.faqs.org/rfcs/rfc3263.html >> >> After some research I also found [2] which encourage me to (really) >> think that always opening the same (source) port on client side can >> not be right way to do it! What do you think? >> >> [2] >> http://www.gont.com.ar/drafts/port-randomization/draft-larsen-tsvwg-port-randomization-01.html >> >>> Anyway, it think that in advanced config options we can set a SIP port nr >> Yes, thanks, I know. FTR: "network.sip.local" is the setting in question >> but I would prefer a random source port selection over a fixed >> one... >> >> Any pros and cons, anybody? >> >> Greetings, >> - Darsha >> >> _______________________________________________ >> QuteCom-dev mailing list >> [email protected] >> http://lists.qutecom.org/mailman/listinfo/qutecom-dev >> > _______________________________________________ > QuteCom-dev mailing list > [email protected] > http://lists.qutecom.org/mailman/listinfo/qutecom-dev _______________________________________________ QuteCom-dev mailing list [email protected] http://lists.qutecom.org/mailman/listinfo/qutecom-dev
