[sip-comm-dev] [patch] single SIP stack


#1

Hi all,

In other words if you have a super-duper patch that you would like to
absolutely see in the 1.0-rc1 release (and the subsequent 1.0) then
now's the time to submit.

OK, then ;). It's been cooking long, but here is a rewritten version of
the SIP single stack patch we discuted on this ML a few months ago. Ref:
https://sip-communicator.dev.java.net/servlets/BrowseList?list=dev&by=thread&from=1264012
https://sip-communicator.dev.java.net/servlets/BrowseList?list=dev&by=thread&from=1270563

What is it about?

- a lot of code has been removed from ProtocolProviderServiceSipImpl

- 3 new classes: ProxyRouter, SipStackProperties and PersistentService

- SipStackProperties takes away all those JAIN-SIP properties that
   cluttered ProtocolProviderServiceSipImpl (call that cosmetic)

- there is now 1 SipStack, 2 SipProvider-s, 3 ListeningPoint-s for
   *all* the ProtocolProviderServiceSipImpl instances. These are stored
   in the PersistentService

- the PersistentService is the SipListener for both SipProvider-s and
   is in charge of the dispatching of the received events between the
   ProtocolProviderServiceSipImpl in a registered state
   (PersistentListener.addSipListener() and .removeSipListener() are
   called respectively by ProtocolProviderServiceSipImpl when
   registering and unregistering)

- therefore, a non registered ProtocolProviderServiceSipImpl will never
   receiver any SIP event (I assumed it was OK so)

- why *2* SipProvider-s for *3* ListeningPoint-s? Because the "clear"
   communications SipProvider contains a UDP and a TCP listener (so that
   the SipProvider can choose the best transport)

- due to the previous point, clear UDP and TCP ListeningPoint-s have to
   bind to the same port

- ports for UDP/TCP and TLS are now customizable. Configuration keys:
   - net.java.sip.communicator.SIP_PREFERRED_CLEAR_PORT
   - net.java.sip.communicator.SIP_PREFERRED_SECURE_PORT
   I would have prefered to put them in
   net.java.sip.communicator.impl.protocol.sip but this place seems to
   be reserved for accounts storage

- all SIP account use common ports (that was the whole point)

- when all SIP accounts are unregistered, the ports are freed

- the patch needs a recent JAIN-SIP RI to work correctly:
   https://jain-sip.dev.java.net/servlets/ReadMsg?list=cvs&msgNo=1265

- I didn't test with ZRTP. As the previous bug was related to TLS, it
   might be worth a try

- there are still 2 minor bugs marked with "FIXME" in the patch (but
   they were already there anyway)

- ProxyRouter wraps the DefaultRouter from JAIN-SIP RI to provide
   dynamically set outbound proxies.

- I compiled with Java 1.6, but there shouldn't be anything 1.5
   specific

- tests and feedback welcome :slight_smile:

Cheers,

single_stack-081128.diff (70.8 KB)

···

On Thu, Nov 27, 2008 at 01:26:39PM +0100, Emil Ivov wrote:

--
Sébastien Mazy


#2

S�bastien,

REF.:

all SIP account use common ports (that was the whole point)

Does this means that it will be impossible for

* SIP provider 1 to be on port 5060
* SIP provider 2 to be on port 5066
* SIP provider 3 to be on port 5072 ??

Regards, Earl

S�bastien Mazy wrote:

···

Hi all,

On Thu, Nov 27, 2008 at 01:26:39PM +0100, Emil Ivov wrote:
  

In other words if you have a super-duper patch that you would like to
absolutely see in the 1.0-rc1 release (and the subsequent 1.0) then
now's the time to submit.
    
OK, then ;). It's been cooking long, but here is a rewritten version of
the SIP single stack patch we discuted on this ML a few months ago. Ref:
https://sip-communicator.dev.java.net/servlets/BrowseList?list=dev&by=thread&from=1264012
https://sip-communicator.dev.java.net/servlets/BrowseList?list=dev&by=thread&from=1270563

What is it about?

- a lot of code has been removed from ProtocolProviderServiceSipImpl

- 3 new classes: ProxyRouter, SipStackProperties and PersistentService

- SipStackProperties takes away all those JAIN-SIP properties that
   cluttered ProtocolProviderServiceSipImpl (call that cosmetic)

- there is now 1 SipStack, 2 SipProvider-s, 3 ListeningPoint-s for
   *all* the ProtocolProviderServiceSipImpl instances. These are stored
   in the PersistentService

- the PersistentService is the SipListener for both SipProvider-s and
   is in charge of the dispatching of the received events between the
   ProtocolProviderServiceSipImpl in a registered state
   (PersistentListener.addSipListener() and .removeSipListener() are
   called respectively by ProtocolProviderServiceSipImpl when
   registering and unregistering)

- therefore, a non registered ProtocolProviderServiceSipImpl will never
   receiver any SIP event (I assumed it was OK so)

- why *2* SipProvider-s for *3* ListeningPoint-s? Because the "clear"
   communications SipProvider contains a UDP and a TCP listener (so that
   the SipProvider can choose the best transport)

- due to the previous point, clear UDP and TCP ListeningPoint-s have to
   bind to the same port

- ports for UDP/TCP and TLS are now customizable. Configuration keys:
   - net.java.sip.communicator.SIP_PREFERRED_CLEAR_PORT
   - net.java.sip.communicator.SIP_PREFERRED_SECURE_PORT
   I would have prefered to put them in
   net.java.sip.communicator.impl.protocol.sip but this place seems to
   be reserved for accounts storage

- all SIP account use common ports (that was the whole point)

- when all SIP accounts are unregistered, the ports are freed

- the patch needs a recent JAIN-SIP RI to work correctly:
   https://jain-sip.dev.java.net/servlets/ReadMsg?list=cvs&msgNo=1265

- I didn't test with ZRTP. As the previous bug was related to TLS, it
   might be worth a try

- there are still 2 minor bugs marked with "FIXME" in the patch (but
   they were already there anyway)

- ProxyRouter wraps the DefaultRouter from JAIN-SIP RI to provide
   dynamically set outbound proxies.

- I compiled with Java 1.6, but there shouldn't be anything 1.5
   specific

- tests and feedback welcome :slight_smile:

Cheers,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Updated version attached:
- ensures tread-safe access to listeners Set
- cosmetic changes

single_stack-081205.diff (71.5 KB)

···

On Fri, Nov 28, 2008 at 01:19:04AM +0100, Sébastien Mazy wrote:

OK, then ;). It's been cooking long, but here is a rewritten version of
the SIP single stack patch we discuted on this ML a few months ago. Ref:
https://sip-communicator.dev.java.net/servlets/BrowseList?list=dev&by=thread&from=1264012
https://sip-communicator.dev.java.net/servlets/BrowseList?list=dev&by=thread&from=1270563

--
Sébastien Mazy


#4

Hey Earl,

Yes, that's the point of the patch. Do you see any problem with it ?

Cheers
Emil

···

On Fri, Nov 28, 2008 at 10:57 AM, Earl <Large.Files@gmx.net> wrote:

Sébastien,

REF.:

all SIP account use common ports (that was the whole point)

Does this means that it will be impossible for

* SIP provider 1 to be on port 5060
* SIP provider 2 to be on port 5066
* SIP provider 3 to be on port 5072 ??

Regards, Earl

Sébastien Mazy wrote:

Hi all,

On Thu, Nov 27, 2008 at 01:26:39PM +0100, Emil Ivov wrote:

In other words if you have a super-duper patch that you would like to
absolutely see in the 1.0-rc1 release (and the subsequent 1.0) then
now's the time to submit.

OK, then ;). It's been cooking long, but here is a rewritten version of
the SIP single stack patch we discuted on this ML a few months ago. Ref:

https://sip-communicator.dev.java.net/servlets/BrowseList?list=dev&by=thread&from=1264012

https://sip-communicator.dev.java.net/servlets/BrowseList?list=dev&by=thread&from=1270563

What is it about?

- a lot of code has been removed from ProtocolProviderServiceSipImpl

- 3 new classes: ProxyRouter, SipStackProperties and PersistentService

- SipStackProperties takes away all those JAIN-SIP properties that
  cluttered ProtocolProviderServiceSipImpl (call that cosmetic)

- there is now 1 SipStack, 2 SipProvider-s, 3 ListeningPoint-s for
  *all* the ProtocolProviderServiceSipImpl instances. These are stored
  in the PersistentService

- the PersistentService is the SipListener for both SipProvider-s and
  is in charge of the dispatching of the received events between the
  ProtocolProviderServiceSipImpl in a registered state
  (PersistentListener.addSipListener() and .removeSipListener() are
  called respectively by ProtocolProviderServiceSipImpl when
  registering and unregistering)

- therefore, a non registered ProtocolProviderServiceSipImpl will never
  receiver any SIP event (I assumed it was OK so)

- why *2* SipProvider-s for *3* ListeningPoint-s? Because the "clear"
  communications SipProvider contains a UDP and a TCP listener (so that
  the SipProvider can choose the best transport)

- due to the previous point, clear UDP and TCP ListeningPoint-s have to
  bind to the same port

- ports for UDP/TCP and TLS are now customizable. Configuration keys:
  - net.java.sip.communicator.SIP_PREFERRED_CLEAR_PORT
  - net.java.sip.communicator.SIP_PREFERRED_SECURE_PORT
  I would have prefered to put them in
  net.java.sip.communicator.impl.protocol.sip but this place seems to
  be reserved for accounts storage

- all SIP account use common ports (that was the whole point)

- when all SIP accounts are unregistered, the ports are freed

- the patch needs a recent JAIN-SIP RI to work correctly:
  https://jain-sip.dev.java.net/servlets/ReadMsg?list=cvs&msgNo=1265

- I didn't test with ZRTP. As the previous bug was related to TLS, it
  might be worth a try

- there are still 2 minor bugs marked with "FIXME" in the patch (but
  they were already there anyway)

- ProxyRouter wraps the DefaultRouter from JAIN-SIP RI to provide
  dynamically set outbound proxies.

- I compiled with Java 1.6, but there shouldn't be anything 1.5
  specific

- tests and feedback welcome :slight_smile:

Cheers,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi Earl,

Does this means that it will be impossible for

* SIP provider 1 to be on port 5060
* SIP provider 2 to be on port 5066
* SIP provider 3 to be on port 5072 ??

Short answer: yes, it will be impossible.

If you don't mind, I'll speak about ListeningPoint-s rather than
SipProvider-s, as one of the 2 SipProvider-s has 2 ListeningPoint-s
(the one for "clear" communications).

Longer one:

- within an account, it seems better to have clear TCP and UDP
   ListeningPoint-s bind the same port. See "Architecture" in the
   javadoc for SipProvider:
   http://snad.ncsl.nist.gov/proj/iptel/jain-sip-1.2/javadoc/javax/sip/SipProvider.html

- of course TLS ListeningPoint must bind on a different port than clear
   UDP/TCP.

- in my patch, all accounts share the same ListeningPoint-s. It would
   be easy to make a per-account configuration though, by creating a new
   PersistentService for accounts that do not want to use the common
   one. I didn't code it because I have seen no use for it, other than
   the case where the SIP messages dispatching process would be very
   unreliable (but then I would better fix that).

Cheers,

···

On Fri, Nov 28, 2008 at 10:57:55AM +0100, Earl wrote:

--
Sébastien Mazy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hey Seb,

I've just applied, committed and ack-ed your patch.

We've already exchanged comments on the implementation of the single
stack patch privately so I guess the only remaining points are the
missing @param and @return clauses in the javadoc. You could probably
get around resubmitting a new patch for these though ... I wonder how :wink:
... stay tuned!

Concerning the getOutboundProxy() method in the ProxyRouter.java. I had
a quick chat with Ranga today and his advice was that we could continue
returning null there. According to him the case where SIPDialog actually
uses this method is pretty broken so we don't really need to make sure
it works. Returning null would therefore rightfully cause an exception
to be thrown.

Other than that, this is nonetheless quite a substantial modification so
I guess we'll need to do some serious testing.

Thanks!
Emil

Sébastien Mazy wrote:

···

On Fri, Nov 28, 2008 at 01:19:04AM +0100, Sébastien Mazy wrote:

OK, then ;). It's been cooking long, but here is a rewritten version of
the SIP single stack patch we discuted on this ML a few months ago. Ref:
https://sip-communicator.dev.java.net/servlets/BrowseList?list=dev&by=thread&from=1264012
https://sip-communicator.dev.java.net/servlets/BrowseList?list=dev&by=thread&from=1270563

Updated version attached:
- ensures tread-safe access to listeners Set
- cosmetic changes

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Emil, S�bastien,

If it is not possible to set the ports independently for each SIP account,
it will cause terrible problems for me and eventually make SC unusable
for SIP.

The reason being that at one location I must use an ADSL modem that
includes triple-play: Internet, Telephone, and TV. This modem and
hundreds of thousand of others with triple-play have an embedded
SIP device on port 5060. This can not be turned off or changed.
The telephone service is included in the subscription and allows free
national and international calls to 40+ countries.

I need this account on port 5060 while simultaneously being registered
to other SIP accounts on different ports. In addition, I have my own
SIP server on the LAN, which I must put on a different port to avoid
interference with the embedded SIP machine.

Since there are so many triple-play ADSL modems on this planet, I
think it is a bad idea to make all SIP accounts use the same port.

Earl

Emil Ivov wrote:

···

Hey Earl,

Yes, that's the point of the patch. Do you see any problem with it ?

Cheers
Emil

On Fri, Nov 28, 2008 at 10:57 AM, Earl <Large.Files@gmx.net> wrote:
  

S�bastien,

REF.:

all SIP account use common ports (that was the whole point)
      

Does this means that it will be impossible for

* SIP provider 1 to be on port 5060
* SIP provider 2 to be on port 5066
* SIP provider 3 to be on port 5072 ??

Regards, Earl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hi all,

I've just applied, committed and ack-ed your patch.

Glad to see it in for rc1 :). Thanks.

We've already exchanged comments on the implementation of the single
stack patch privately so I guess the only remaining points are the
missing @param and @return clauses in the javadoc.

Actually these are not the only points. For the record:

- JAIN-SIP RI needs to be updated (or at least the patch concerning TLS
   be backported) for the TLS ListeningPoint to be properly deleted.

- I need to find out why calling getMessage() on an Exception in SC returns
   a localized message (it shouldn't, there is getLocalizedMessage() for
   that). ProtocolProviderServiceSipImpl used to read this message to
   determine whether a ListeningPoint failed to bind its port. There is
   a FIXME for this in SipStackSharing btw, as well as a (temporary I
   hope) workaround.

Concerning the getOutboundProxy() method in the ProxyRouter.java. I had
a quick chat with Ranga today and his advice was that we could continue
returning null there. According to him the case where SIPDialog actually
uses this method is pretty broken so we don't really need to make sure
it works. Returning null would therefore rightfully cause an exception
to be thrown.

OK. I see you added a big fat error message.

Other than that, this is nonetheless quite a substantial modification so
I guess we'll need to do some serious testing.

Given the last commits from Werner, I guess ZRTP still works. Really
needed is testing from people who use several SIP accounts with the same
username (eg user@ (no registrar), user@provider1, user@provider2).

Cheers,

···

On Tue, Dec 09, 2008 at 05:25:06PM +0200, Emil Ivov wrote:

--
Sébastien Mazy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Hi,

I just remembered when I was test driving ZRTP from Phil Zimmermann and
tried to watch a TV channel from the ADSL modem media server (set-top box)
that ZRTP activated thinking the the TV media stream sent via RTP was an
incoming SIP call. I asked Phil to add an ignore port in his configuration to
fix this problem.

I don't know how SC will react in such a case, but may be able to test this
in the next week.

Phil's generic ZRTP must intercept all RTP streams, but SC may have zrtp4j
tied to a SIP channel and never see and not be disturbed by TV RTP media
stream ?

Earl

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hi Earl,

If it is not possible to set the ports independently for each SIP account,
it will cause terrible problems for me and eventually make SC unusable
for SIP.

The reason being that at one location I must use an ADSL modem that
includes triple-play: Internet, Telephone, and TV. This modem and
hundreds of thousand of others with triple-play have an embedded
SIP device on port 5060. This can not be turned off or changed.
The telephone service is included in the subscription and allows free
national and international calls to 40+ countries.

That's interesting. I thought most ISPs put VoIP on another VC (at
least in France).

I need this account on port 5060 while simultaneously being registered
to other SIP accounts on different ports. In addition, I have my own
SIP server on the LAN, which I must put on a different port to avoid
interference with the embedded SIP machine.

Since there are so many triple-play ADSL modems on this planet, I
think it is a bad idea to make all SIP accounts use the same port.

Well, all SIP accounts will share the same ports, but these can be
configured:

···

On Fri, Nov 28, 2008 at 03:28:22PM +0100, Earl wrote:

On Fri, Nov 28, 2008 at 01:19:04AM +0100, Sébastien Mazy wrote:

- ports for UDP/TCP and TLS are now customizable. Configuration keys:
   - net.java.sip.communicator.SIP_PREFERRED_CLEAR_PORT
   - net.java.sip.communicator.SIP_PREFERRED_SECURE_PORT

Does it solve your problem? OK, I agree it would be better with a GUI
option. I may create one.

Cheers,

--
Sébastien Mazy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

Hi,

Actually these are not the only points. For the record:

One more :/. I just realized that a ConcurrentModificationException
occured when unregistering, due to the following chunk of code in
impl.protocol.sip.SipStackSharing:

Iterator<ListeningPoint> it = this.stack.getListeningPoints();
while(it.hasNext())
{
    this.stack.deleteListeningPoint(it.next());
}

deleteListeningPoint() will change the 'it' I'm iterating on, indeed.
I'd like to replace it by the following code:

// delete all ListeningPoint-s from the stack
try
{
    while(true)
    {
        this.stack.deleteListeningPoint((ListeningPoint) this.stack
                .getListeningPoints().next());
    }
}
catch(NoSuchElementException ex)
{
    // that's OK, it just means that the stack has no LP left
}

I'm aware that such construction might scare some, and that's why I post
it here.

If you're confident that JAIN-SIP RI will remove the LP, then it's no
problem (anyway the case where it doesn't is taken care of by another
catch). Otherwise, I can do it in a more conventional way (copy the
iterator's content in a new collection, then delete the LPs). What do
you think?

(Actually this question is more about good practices than anything)

Cheers,

···

On Wed, Dec 10, 2008 at 09:45:12PM +0100, Sébastien Mazy wrote:

--
Sébastien Mazy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#12

Sébastien,

yes, it would be very good if you would write a GUI option to configure ports
of a SIP account.
Usually a default of 5060 is OK, but it may be necessary to configure to a
different port and a GUI would help the normal user.

Thanks.

Earl

Sébastien Mazy wrote:

···

Hi Earl,

On Fri, Nov 28, 2008 at 03:28:22PM +0100, Earl wrote:
  

If it is not possible to set the ports independently for each SIP account,
it will cause terrible problems for me and eventually make SC unusable
for SIP.

The reason being that at one location I must use an ADSL modem that
includes triple-play: Internet, Telephone, and TV. This modem and
hundreds of thousand of others with triple-play have an embedded
SIP device on port 5060. This can not be turned off or changed.
The telephone service is included in the subscription and allows free
national and international calls to 40+ countries.
    
That's interesting. I thought most ISPs put VoIP on another VC (at
least in France).

I need this account on port 5060 while simultaneously being registered
to other SIP accounts on different ports. In addition, I have my own
SIP server on the LAN, which I must put on a different port to avoid
interference with the embedded SIP machine.

Since there are so many triple-play ADSL modems on this planet, I
think it is a bad idea to make all SIP accounts use the same port.
    
Well, all SIP accounts will share the same ports, but these can be
configured:

On Fri, Nov 28, 2008 at 01:19:04AM +0100, Sébastien Mazy wrote:
  

- ports for UDP/TCP and TLS are now customizable. Configuration keys:
   - net.java.sip.communicator.SIP_PREFERRED_CLEAR_PORT
   - net.java.sip.communicator.SIP_PREFERRED_SECURE_PORT
    
Does it solve your problem? OK, I agree it would be better with a GUI
option. I may create one.

Cheers,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#13

Earl,

your assumption is true. ZRTP4J is bound to the specific RTP channels
that SC uses for media sessions.

Regards,
Werner

Earl schrieb:

···

Hi,

I just remembered when I was test driving ZRTP from Phil Zimmermann and
tried to watch a TV channel from the ADSL modem media server (set-top box)
that ZRTP activated thinking the the TV media stream sent via RTP was an
incoming SIP call. I asked Phil to add an ignore port in his configuration to
fix this problem.

I don't know how SC will react in such a case, but may be able to test this
in the next week.

Phil's generic ZRTP must intercept all RTP streams, but SC may have zrtp4j
tied to a SIP channel and never see and not be disturbed by TV RTP media
stream ?

Earl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#14

// delete all ListeningPoint-s from the stack

> try
> {
> while(true)
> {
> this.stack.deleteListeningPoint((ListeningPoint) this.stack
> .getListeningPoints().next());
> }
> }
> catch(NoSuchElementException ex)
> {
> // that's OK, it just means that the stack has no LP left
> }

If you're going to call next() on an Iterator, why not first check it with hasNext() instead of intentionally causing a NoSuchElementException? I mean exceptions are for exceptional incidents. Besides, they're expensive wrt to performance.

···

On 12/11/2008 8:26 PM, Sébastien Mazy wrote:

Hi,

On Wed, Dec 10, 2008 at 09:45:12PM +0100, Sébastien Mazy wrote:

Actually these are not the only points. For the record:

One more :/. I just realized that a ConcurrentModificationException
occured when unregistering, due to the following chunk of code in
impl.protocol.sip.SipStackSharing:

Iterator<ListeningPoint> it = this.stack.getListeningPoints();
while(it.hasNext())
{
     this.stack.deleteListeningPoint(it.next());
}

deleteListeningPoint() will change the 'it' I'm iterating on, indeed.
I'd like to replace it by the following code:

// delete all ListeningPoint-s from the stack
try
{
     while(true)
     {
         this.stack.deleteListeningPoint((ListeningPoint) this.stack
                 .getListeningPoints().next());
     }
}
catch(NoSuchElementException ex)
{
     // that's OK, it just means that the stack has no LP left
}

I'm aware that such construction might scare some, and that's why I post
it here.

If you're confident that JAIN-SIP RI will remove the LP, then it's no
problem (anyway the case where it doesn't is taken care of by another
catch). Otherwise, I can do it in a more conventional way (copy the
iterator's content in a new collection, then delete the LPs). What do
you think?

(Actually this question is more about good practices than anything)

Cheers,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#15

Hey Earl,

Just as a side nore: we actually have this previewed for rc1 as issue 421:

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=421

Note however that all accounts would still be using the same local
port. I am not sure I understood if and why this would be a problem
for you though. In case it is could you please describe a specific
scenario where an incoming or an outgoing call would fail because of
the newly implemented behavior?

I completely agree this is important so I'd like us to make sure that
we are not breaking anything.

Cheers
Emil

···

On Fri, Nov 28, 2008 at 4:15 PM, Earl <Large.Files@gmx.net> wrote:

Sébastien,

yes, it would be very good if you would write a GUI option to configure
ports
of a SIP account.
Usually a default of 5060 is OK, but it may be necessary to configure to a
different port and a GUI would help the normal user.

Thanks.

Earl

Sébastien Mazy wrote:

Hi Earl,

On Fri, Nov 28, 2008 at 03:28:22PM +0100, Earl wrote:

If it is not possible to set the ports independently for each SIP
account,
it will cause terrible problems for me and eventually make SC unusable
for SIP.

The reason being that at one location I must use an ADSL modem that
includes triple-play: Internet, Telephone, and TV. This modem and
hundreds of thousand of others with triple-play have an embedded
SIP device on port 5060. This can not be turned off or changed.
The telephone service is included in the subscription and allows free
national and international calls to 40+ countries.

That's interesting. I thought most ISPs put VoIP on another VC (at
least in France).

I need this account on port 5060 while simultaneously being registered
to other SIP accounts on different ports. In addition, I have my own
SIP server on the LAN, which I must put on a different port to avoid
interference with the embedded SIP machine.

Since there are so many triple-play ADSL modems on this planet, I
think it is a bad idea to make all SIP accounts use the same port.

Well, all SIP accounts will share the same ports, but these can be
configured:

On Fri, Nov 28, 2008 at 01:19:04AM +0100, Sébastien Mazy wrote:

- ports for UDP/TCP and TLS are now customizable. Configuration keys:
  - net.java.sip.communicator.SIP_PREFERRED_CLEAR_PORT
  - net.java.sip.communicator.SIP_PREFERRED_SECURE_PORT

Does it solve your problem? OK, I agree it would be better with a GUI
option. I may create one.

Cheers,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#16

Hi Lubomir,

···

On Thu, Dec 11, 2008 at 10:28:33PM +0200, Lubomir Marinov wrote:

If you're going to call next() on an Iterator, why not first check
it with hasNext() instead of intentionally causing a
NoSuchElementException? I mean exceptions are for exceptional
incidents. Besides, they're expensive wrt to performance.

Thanks for the performance clue. I've commited a fix in r4839.

Cheers,

--
Sébastien Mazy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#17

Hi,

As working on issue #623 (https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=623).
I found that sip-communicator is forced to shutdown due to infinite loop in the code commited in r4839.
I also saw that there was a case with ConcurrentModificationException, so I fixed this with making a copy of the elements.
The fix is in r5208.

damencho

Sébastien Mazy wrote:

···

Hi Lubomir,

On Thu, Dec 11, 2008 at 10:28:33PM +0200, Lubomir Marinov wrote:
  

If you're going to call next() on an Iterator, why not first check it with hasNext() instead of intentionally causing a NoSuchElementException? I mean exceptions are for exceptional incidents. Besides, they're expensive wrt to performance.
    
Thanks for the performance clue. I've commited a fix in r4839.

Cheers,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#18

Hi Jana,

the first day you changed the GUI, I noticed that the photo shown
in the upper left corner was disturbed.

Today, I found out why. I made a screen shot where you can see
that the top half of the photo window has a translucent area.
If a photo appears instead of the icon, this translucent area remains
and disturbs the photo.

This translucent area should be removed so the photo, that may
appear, is not disturbed.

2) the latest build still has the shaded presence balls that are
difficult to see. Will these be replaced by bright, single-colored
presence balls before RC 1 ?

Thanks for your efforts.

Regards, Earl


#19

Emil,

One scenario might be that I wish to connect to the triple-play modem on port 5060
and simultaneously to my own SIP server on the same LAN on port 5070.
I would need to configure one account to port 5070.

If there are other people on the LAN that wish to use SIP they each need their own
port range:
Person A ports 5062-5063
Person B ports 5064-5065
Person C ports 5066-5067
so that the router can do port forwarding to each computer.

The next question is what port does SC use for media RTP stream ?
Does it take the signalling port and add some number to this ? What number ?
Is the media RTP stream done on a random port ? How does SC do this?
A network admin must know how SC determines this so ports can be open
in the firewall..

Regards, Earl

Emil Ivov wrote:

···

Hey Earl,

Just as a side nore: we actually have this previewed for rc1 as issue 421:

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=421

Note however that all accounts would still be using the same local
port. I am not sure I understood if and why this would be a problem
for you though. In case it is could you please describe a specific
scenario where an incoming or an outgoing call would fail because of
the newly implemented behavior?

I completely agree this is important so I'd like us to make sure that
we are not breaking anything.

Cheers
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#20

Hey Earl,

Earl wrote:

Emil,

One scenario might be that I wish to connect to the triple-play modem on
port 5060 and simultaneously to my own SIP server on the same LAN on port 5070.
I would need to configure one account to port 5070.

You would still be able to do this. The single port patch only has an
impact on the port that you are binding on locally. You could still add
accounts that connect to their corresponding proxies and registrars on
whatever port you wish, and the only change would be the fact that they
would all use the same port on the local machine when sending messages.

If there are other people on the LAN that wish to use SIP they each need
their own port range:
Person A ports 5062-5063
Person B ports 5064-5065
Person C ports 5066-5067
so that the router can do port forwarding to each computer.

I don't see how this would be a problem either. If you want to do port
mapping on your firewall you would simply need to make sure that Persons
A, B, and C configure their clients to bind on the respective ports. The
single-port patch would actually simplify your task here since you would
only need to map one port per Person.

The next question is what port does SC use for media RTP stream ?
Does it take the signalling port and add some number to this ? What
number ?

They are configurable with default values of 5000 and 5002 for audio and
video RTP and 5001 and 5003 for the respective RTCPs.

Hopes this clarifies the situation.

Cheers
Emil

···

Is the media RTP stream done on a random port ? How does SC do this?
A network admin must know how SC determines this so ports can be open
in the firewall..

Regards, Earl

Emil Ivov wrote:

Hey Earl,

Just as a side nore: we actually have this previewed for rc1 as issue 421:

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=421

Note however that all accounts would still be using the same local
port. I am not sure I understood if and why this would be a problem
for you though. In case it is could you please describe a specific
scenario where an incoming or an outgoing call would fail because of
the newly implemented behavior?

I completely agree this is important so I'd like us to make sure that
we are not breaking anything.

Cheers
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net