[sip-comm-dev] bonjour statuses


#1

Hi Christian Vincenot,

I'm integrating the project sc-bonjour into sip-communicator.
But I have found some bug in the protocol provider. Its related with statuses. When a status change is received
it isn't processed properly. I found some problem in updateRecord method in BonjourService. Where an incoming record is checked whether its unique or not which stops further processing.
And if this check is removed the record processing continues but again its not working.
I'm tring to figure this out but can you help solving the problem so I can commit the zeroconf protocol provider.

damencho

···

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


#2

Hi Damian,

This probably comes from the last modifications I've done. I'll check this immediatly.

Thanks.

Chris.

···

----- Original Message -----

From: "Damian Minkov" <damencho@damencho.com>

To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 04, 2007 12:48 PM
Subject: [sip-comm-dev] bonjour statuses

Hi Christian Vincenot,

I'm integrating the project sc-bonjour into sip-communicator.
But I have found some bug in the protocol provider. Its related with statuses. When a status change is received
it isn't processed properly. I found some problem in updateRecord method in BonjourService. Where an incoming record is checked whether its unique or not which stops further processing.
And if this check is removed the record processing continues but again its not working.
I'm tring to figure this out but can you help solving the problem so I can commit the zeroconf protocol provider.

damencho

---------------------------------------------------------------------
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


#3

I've installed SC on another computer and I could reproduce the bug.
This problem is only happening when two SC clients are communicating
together, that's why I couldn't reproduce it using SC <-> gaim or SC <->
iChat.

In fact the updateRecord method works and the status is really changed. The
problem is that the new status isn't retrieved correctly (it's not modified
in the cache). So in fact, the problem comes from the JmDNS part of the
project. Probably just modifying the updateInfos method should be enough,
but it would need a bit of testing. I've quickly tried to change the DNS
response we send so that the cache is made invalid in a nicer way (but it
doesn't solve the problem at the moment) : instead of just sending an
IN-unique message updating the cache, we first send the old record with TTL
= 0 and afterwards the IN-unique message to force the cache flush. That's
what other more advanced stacks seem to use (like avahi, the one from gaim),
so that's probably the difference that makes the status change work with
gaim/iChat and not with SC.

I'll check that ASAP, but I've got my first exams after tomorrow, so I'm
really short on time. Would it be possible to wait until the end of the
exams period to do bug corrections?

@Emil: do we need Bonjour to be integrated in the next days, or can it wait
until the 15th of June?

If it's really urgent, I'll try to find some free time to do it, but else I
would really prefer doing it after the exams.

Cheers,
Chris.

···

----- Original Message -----

From: "Damian Minkov" <damencho@damencho.com>

To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 04, 2007 12:48 PM
Subject: [sip-comm-dev] bonjour statuses

Hi Christian Vincenot,

I'm integrating the project sc-bonjour into sip-communicator.
But I have found some bug in the protocol provider. Its related with
statuses. When a status change is received
it isn't processed properly. I found some problem in updateRecord method
in BonjourService. Where an incoming record is checked whether its unique
or not which stops further processing.
And if this check is removed the record processing continues but again its
not working.
I'm tring to figure this out but can you help solving the problem so I can
commit the zeroconf protocol provider.

damencho

---------------------------------------------------------------------
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


#4

In fact, it seems to work now. The change is the one explained in my previous message :
to update the cache, we first send an answer with the old record and TTL=0 to force the remote stack to remove the TXT cache entry, and only after we send the new infos in an IN-UNIQUE DNS answer to flush the cache. This seems to work for me to solve the SC <-> SC problem, but I would need to test if this change impacts on the communication with iChat/Gaim.

As said, I'll check all this as soon as my exams are over if that's fine with you.

I've commited the change, but here's an overview of what was changed (JmDNS.java, updateInfos:2628) :

···

------------------------------
out = new DNSOutgoing(DNSConstants.FLAGS_RA | DNSConstants.FLAGS_AA);
out2 = new DNSOutgoing(DNSConstants.FLAGS_RA | DNSConstants.FLAGS_AA);

try
{
                out.addAnswer(new DNSRecord.Text(info.getQualifiedName(), DNSConstants.TYPE_TXT, DNSConstants.CLASS_IN , 0, old), 0);
                out.addAnswer(new DNSRecord.Text(info.getQualifiedName(), DNSConstants.TYPE_TXT, DNSConstants.CLASS_IN | DNSConstants.CLASS_UNIQUE, DNSConstants.DNS_TTL, info.text), 0);
                out2.addAnswer(new DNSRecord.Text(info.getQualifiedName(), DNSConstants.TYPE_TXT, DNSConstants.CLASS_IN | DNSConstants.CLASS_UNIQUE, DNSConstants.DNS_TTL, info.text), 0);

                logger.finer("updateInfos() JmDNS updated infos for "+info);

                send(out);
                Thread.sleep(1000);
                send(out2);
                Thread.sleep(2000);
                send(out2);

}

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

@Damencho: Please tell me if that works for you.
Thanks.

Cheers,
Chris.

----- Original Message -----

From: "Chris" <sipcom@cyberspace7.net>

To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 04, 2007 10:27 PM
Subject: Re: [sip-comm-dev] bonjour statuses

I've installed SC on another computer and I could reproduce the bug.
This problem is only happening when two SC clients are communicating
together, that's why I couldn't reproduce it using SC <-> gaim or SC <->
iChat.

In fact the updateRecord method works and the status is really changed. The
problem is that the new status isn't retrieved correctly (it's not modified
in the cache). So in fact, the problem comes from the JmDNS part of the
project. Probably just modifying the updateInfos method should be enough,
but it would need a bit of testing. I've quickly tried to change the DNS
response we send so that the cache is made invalid in a nicer way (but it
doesn't solve the problem at the moment) : instead of just sending an
IN-unique message updating the cache, we first send the old record with TTL
= 0 and afterwards the IN-unique message to force the cache flush. That's
what other more advanced stacks seem to use (like avahi, the one from gaim),
so that's probably the difference that makes the status change work with
gaim/iChat and not with SC.

I'll check that ASAP, but I've got my first exams after tomorrow, so I'm
really short on time. Would it be possible to wait until the end of the
exams period to do bug corrections?

@Emil: do we need Bonjour to be integrated in the next days, or can it wait
until the 15th of June?

If it's really urgent, I'll try to find some free time to do it, but else I
would really prefer doing it after the exams.

Cheers,
Chris.

----- Original Message ----- From: "Damian Minkov" <damencho@damencho.com>
To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 04, 2007 12:48 PM
Subject: [sip-comm-dev] bonjour statuses

Hi Christian Vincenot,

I'm integrating the project sc-bonjour into sip-communicator.
But I have found some bug in the protocol provider. Its related with
statuses. When a status change is received
it isn't processed properly. I found some problem in updateRecord method
in BonjourService. Where an incoming record is checked whether its unique
or not which stops further processing.
And if this check is removed the record processing continues but again its
not working.
I'm tring to figure this out but can you help solving the problem so I can
commit the zeroconf protocol provider.

damencho

---------------------------------------------------------------------
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

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


#5

Hello Chris

Chris wrote:

@Emil: do we need Bonjour to be integrated in the next days, or can it wait
until the 15th of June?

Sure, no problem. It can wait!

Cheers
Emil

···

If it's really urgent, I'll try to find some free time to do it, but else I
would really prefer doing it after the exams.

Cheers,
Chris.

----- Original Message ----- From: "Damian Minkov" <damencho@damencho.com>
To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 04, 2007 12:48 PM
Subject: [sip-comm-dev] bonjour statuses

Hi Christian Vincenot,

I'm integrating the project sc-bonjour into sip-communicator.
But I have found some bug in the protocol provider. Its related with
statuses. When a status change is received
it isn't processed properly. I found some problem in updateRecord method
in BonjourService. Where an incoming record is checked whether its unique
or not which stops further processing.
And if this check is removed the record processing continues but again its
not working.
I'm tring to figure this out but can you help solving the problem so I can
commit the zeroconf protocol provider.

damencho

---------------------------------------------------------------------
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

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


#6

Hi Chris,

I've just committed the bonjour service and here is the few changes I've made.

1. Formatting of code.
2. Added entry in ProtocolNames and use it in all impl classes. So the variable is removed
    ZEROCONF_PROTOCOL_NAME from ProtocolProviderServiceZeroconfImpl.
3. Disable of the option "Remember Bonjour contacts?" in the Account Registration Wizard as its not used.

After you are free - after the exams it seems that we must test the statuses to clean all issues, as there are still problems.

Great - one more entry in protocol list :wink:

damencho

Chris wrote:

···

I've installed SC on another computer and I could reproduce the bug.
This problem is only happening when two SC clients are communicating
together, that's why I couldn't reproduce it using SC <-> gaim or SC <->
iChat.

In fact the updateRecord method works and the status is really changed. The
problem is that the new status isn't retrieved correctly (it's not modified
in the cache). So in fact, the problem comes from the JmDNS part of the
project. Probably just modifying the updateInfos method should be enough,
but it would need a bit of testing. I've quickly tried to change the DNS
response we send so that the cache is made invalid in a nicer way (but it
doesn't solve the problem at the moment) : instead of just sending an
IN-unique message updating the cache, we first send the old record with TTL
= 0 and afterwards the IN-unique message to force the cache flush. That's
what other more advanced stacks seem to use (like avahi, the one from gaim),
so that's probably the difference that makes the status change work with
gaim/iChat and not with SC.

I'll check that ASAP, but I've got my first exams after tomorrow, so I'm
really short on time. Would it be possible to wait until the end of the
exams period to do bug corrections?

@Emil: do we need Bonjour to be integrated in the next days, or can it wait
until the 15th of June?

If it's really urgent, I'll try to find some free time to do it, but else I
would really prefer doing it after the exams.

Cheers,
Chris.

----- Original Message ----- From: "Damian Minkov" <damencho@damencho.com>
To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 04, 2007 12:48 PM
Subject: [sip-comm-dev] bonjour statuses

Hi Christian Vincenot,

I'm integrating the project sc-bonjour into sip-communicator.
But I have found some bug in the protocol provider. Its related with
statuses. When a status change is received
it isn't processed properly. I found some problem in updateRecord method
in BonjourService. Where an incoming record is checked whether its unique
or not which stops further processing.
And if this check is removed the record processing continues but again its
not working.
I'm tring to figure this out but can you help solving the problem so I can
commit the zeroconf protocol provider.

damencho

---------------------------------------------------------------------
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

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


#7

Hi Damian,

Great to hear that. Yeah, of course we'll check this as soon as I'm finished with the exams. Did the corrections from last time work for you? (I've done some testing here with SC clients running on both sides and it seemed to work, but I can't say at the moment if it's still compatible with iChat/gaim).

Best regards,
Chris.

···

----- Original Message -----

From: "Damian Minkov" <damencho@damencho.com>

To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 11, 2007 12:49 PM
Subject: Re: [sip-comm-dev] bonjour statuses

Hi Chris,

I've just committed the bonjour service and here is the few changes I've made.

1. Formatting of code.
2. Added entry in ProtocolNames and use it in all impl classes. So the variable is removed
   ZEROCONF_PROTOCOL_NAME from ProtocolProviderServiceZeroconfImpl.
3. Disable of the option "Remember Bonjour contacts?" in the Account Registration Wizard as its not used.

After you are free - after the exams it seems that we must test the statuses to clean all issues, as there are still problems.

Great - one more entry in protocol list :wink:

damencho

Chris wrote:

I've installed SC on another computer and I could reproduce the bug.
This problem is only happening when two SC clients are communicating
together, that's why I couldn't reproduce it using SC <-> gaim or SC <->
iChat.

In fact the updateRecord method works and the status is really changed. The
problem is that the new status isn't retrieved correctly (it's not modified
in the cache). So in fact, the problem comes from the JmDNS part of the
project. Probably just modifying the updateInfos method should be enough,
but it would need a bit of testing. I've quickly tried to change the DNS
response we send so that the cache is made invalid in a nicer way (but it
doesn't solve the problem at the moment) : instead of just sending an
IN-unique message updating the cache, we first send the old record with TTL
= 0 and afterwards the IN-unique message to force the cache flush. That's
what other more advanced stacks seem to use (like avahi, the one from gaim),
so that's probably the difference that makes the status change work with
gaim/iChat and not with SC.

I'll check that ASAP, but I've got my first exams after tomorrow, so I'm
really short on time. Would it be possible to wait until the end of the
exams period to do bug corrections?

@Emil: do we need Bonjour to be integrated in the next days, or can it wait
until the 15th of June?

If it's really urgent, I'll try to find some free time to do it, but else I
would really prefer doing it after the exams.

Cheers,
Chris.

----- Original Message ----- From: "Damian Minkov" <damencho@damencho.com>
To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 04, 2007 12:48 PM
Subject: [sip-comm-dev] bonjour statuses

Hi Christian Vincenot,

I'm integrating the project sc-bonjour into sip-communicator.
But I have found some bug in the protocol provider. Its related with
statuses. When a status change is received
it isn't processed properly. I found some problem in updateRecord method
in BonjourService. Where an incoming record is checked whether its unique
or not which stops further processing.
And if this check is removed the record processing continues but again its
not working.
I'm tring to figure this out but can you help solving the problem so I can
commit the zeroconf protocol provider.

damencho

---------------------------------------------------------------------
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

---------------------------------------------------------------------
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


#8

Hi Damian,

I'm finished with exams now so I'll have some free time to crush those little ugly bugs one by one ;).

Chris.

···

----- Original Message -----

From: "Damian Minkov" <damencho@damencho.com>

To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 11, 2007 12:49 PM
Subject: Re: [sip-comm-dev] bonjour statuses

Hi Chris,

I've just committed the bonjour service and here is the few changes I've made.

1. Formatting of code.
2. Added entry in ProtocolNames and use it in all impl classes. So the variable is removed
   ZEROCONF_PROTOCOL_NAME from ProtocolProviderServiceZeroconfImpl.
3. Disable of the option "Remember Bonjour contacts?" in the Account Registration Wizard as its not used.

After you are free - after the exams it seems that we must test the statuses to clean all issues, as there are still problems.

Great - one more entry in protocol list :wink:

damencho

Chris wrote:

I've installed SC on another computer and I could reproduce the bug.
This problem is only happening when two SC clients are communicating
together, that's why I couldn't reproduce it using SC <-> gaim or SC <->
iChat.

In fact the updateRecord method works and the status is really changed. The
problem is that the new status isn't retrieved correctly (it's not modified
in the cache). So in fact, the problem comes from the JmDNS part of the
project. Probably just modifying the updateInfos method should be enough,
but it would need a bit of testing. I've quickly tried to change the DNS
response we send so that the cache is made invalid in a nicer way (but it
doesn't solve the problem at the moment) : instead of just sending an
IN-unique message updating the cache, we first send the old record with TTL
= 0 and afterwards the IN-unique message to force the cache flush. That's
what other more advanced stacks seem to use (like avahi, the one from gaim),
so that's probably the difference that makes the status change work with
gaim/iChat and not with SC.

I'll check that ASAP, but I've got my first exams after tomorrow, so I'm
really short on time. Would it be possible to wait until the end of the
exams period to do bug corrections?

@Emil: do we need Bonjour to be integrated in the next days, or can it wait
until the 15th of June?

If it's really urgent, I'll try to find some free time to do it, but else I
would really prefer doing it after the exams.

Cheers,
Chris.

----- Original Message ----- From: "Damian Minkov" <damencho@damencho.com>
To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 04, 2007 12:48 PM
Subject: [sip-comm-dev] bonjour statuses

Hi Christian Vincenot,

I'm integrating the project sc-bonjour into sip-communicator.
But I have found some bug in the protocol provider. Its related with
statuses. When a status change is received
it isn't processed properly. I found some problem in updateRecord method
in BonjourService. Where an incoming record is checked whether its unique
or not which stops further processing.
And if this check is removed the record processing continues but again its
not working.
I'm tring to figure this out but can you help solving the problem so I can
commit the zeroconf protocol provider.

damencho

---------------------------------------------------------------------
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

---------------------------------------------------------------------
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


#9

Hi Chris,

I didn't get a chance to tell you this earlier so here I go now: You've done a very good job! This was really far from being trivial work and you've handled it very well! Congratulations!

We only need to stabilize it now. I've talked to you offline about a multiple interfaces problem. I've seen that JmDNS uses InetAddress.getLocalHost() and this causes trouble on multi homed machines.

There are two ways that we could handle this:

1. A single zeroconf account listens and broadcasts on all interfaces

2. We make the user select the interface an account should listen on, in the protocol wizard.

Personally I'd prefer one since most users would be perplexed when presented with the notion of a network interface.

Incidentally, I see now that users have the possibility to create multiple zeroconf accounts. Is there any reason for this? Perhaps it would be a good idea for the zeroconf account not to allow more than one such account (RSS does this).

That's all for now. Once again, thanks for contributing.

Cheers
Emil

Chris wrote:

···

Hi Damian,

I'm finished with exams now so I'll have some free time to crush those little ugly bugs one by one ;).

Chris.

----- Original Message ----- From: "Damian Minkov" <damencho@damencho.com>
To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 11, 2007 12:49 PM
Subject: Re: [sip-comm-dev] bonjour statuses

Hi Chris,

I've just committed the bonjour service and here is the few changes I've made.

1. Formatting of code.
2. Added entry in ProtocolNames and use it in all impl classes. So the variable is removed
   ZEROCONF_PROTOCOL_NAME from ProtocolProviderServiceZeroconfImpl.
3. Disable of the option "Remember Bonjour contacts?" in the Account Registration Wizard as its not used.

After you are free - after the exams it seems that we must test the statuses to clean all issues, as there are still problems.

Great - one more entry in protocol list :wink:

damencho

Chris wrote:

I've installed SC on another computer and I could reproduce the bug.
This problem is only happening when two SC clients are communicating
together, that's why I couldn't reproduce it using SC <-> gaim or SC <->
iChat.

In fact the updateRecord method works and the status is really changed. The
problem is that the new status isn't retrieved correctly (it's not modified
in the cache). So in fact, the problem comes from the JmDNS part of the
project. Probably just modifying the updateInfos method should be enough,
but it would need a bit of testing. I've quickly tried to change the DNS
response we send so that the cache is made invalid in a nicer way (but it
doesn't solve the problem at the moment) : instead of just sending an
IN-unique message updating the cache, we first send the old record with TTL
= 0 and afterwards the IN-unique message to force the cache flush. That's
what other more advanced stacks seem to use (like avahi, the one from gaim),
so that's probably the difference that makes the status change work with
gaim/iChat and not with SC.

I'll check that ASAP, but I've got my first exams after tomorrow, so I'm
really short on time. Would it be possible to wait until the end of the
exams period to do bug corrections?

@Emil: do we need Bonjour to be integrated in the next days, or can it wait
until the 15th of June?

If it's really urgent, I'll try to find some free time to do it, but else I
would really prefer doing it after the exams.

Cheers,
Chris.

----- Original Message ----- From: "Damian Minkov" <damencho@damencho.com>
To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 04, 2007 12:48 PM
Subject: [sip-comm-dev] bonjour statuses

Hi Christian Vincenot,

I'm integrating the project sc-bonjour into sip-communicator.
But I have found some bug in the protocol provider. Its related with
statuses. When a status change is received
it isn't processed properly. I found some problem in updateRecord method
in BonjourService. Where an incoming record is checked whether its unique
or not which stops further processing.
And if this check is removed the record processing continues but again its
not working.
I'm tring to figure this out but can you help solving the problem so I can
commit the zeroconf protocol provider.

damencho

---------------------------------------------------------------------
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

---------------------------------------------------------------------
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

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


#10

I want to chime in on how exciting it is to watch the last few
weeks/months new developments in SIP-Communicator. Emil's role in the
active community seems to be producing rapid jumps in quality and
features. A few months from now, S-C will be an even better landmark in
personal telecom.

  Is there a new revision of the roadmap, with featuresets and expected
timeframes, that takes the new developers and developments into account?

···

On Tue, 2007-06-19 at 17:45 +0200, Emil Ivov wrote:

Hi Chris,

I didn't get a chance to tell you this earlier so here I go now: You've
done a very good job! This was really far from being trivial work and
you've handled it very well! Congratulations!

We only need to stabilize it now. I've talked to you offline about a
multiple interfaces problem. I've seen that JmDNS uses
InetAddress.getLocalHost() and this causes trouble on multi homed machines.

There are two ways that we could handle this:

1. A single zeroconf account listens and broadcasts on all interfaces

2. We make the user select the interface an account should listen on, in
the protocol wizard.

Personally I'd prefer one since most users would be perplexed when
presented with the notion of a network interface.

Incidentally, I see now that users have the possibility to create
multiple zeroconf accounts. Is there any reason for this? Perhaps it
would be a good idea for the zeroconf account not to allow more than one
such account (RSS does this).

That's all for now. Once again, thanks for contributing.

Cheers
Emil

Chris wrote:
> Hi Damian,
>
> I'm finished with exams now so I'll have some free time to crush those
> little ugly bugs one by one ;).
>
> Chris.
>
> ----- Original Message -----
> From: "Damian Minkov" <damencho@damencho.com>
> To: <dev@sip-communicator.dev.java.net>
> Sent: Monday, June 11, 2007 12:49 PM
> Subject: Re: [sip-comm-dev] bonjour statuses
>
>
>> Hi Chris,
>>
>> I've just committed the bonjour service and here is the few changes I've
>> made.
>>
>> 1. Formatting of code.
>> 2. Added entry in ProtocolNames and use it in all impl classes. So the
>> variable is removed
>> ZEROCONF_PROTOCOL_NAME from ProtocolProviderServiceZeroconfImpl.
>> 3. Disable of the option "Remember Bonjour contacts?" in the Account
>> Registration Wizard as its not used.
>>
>> After you are free - after the exams it seems that we must test the
>> statuses to clean all issues, as there are still problems.
>>
>> Great - one more entry in protocol list :wink:
>>
>> damencho
>>
>>
>> Chris wrote:
>>> I've installed SC on another computer and I could reproduce the bug.
>>> This problem is only happening when two SC clients are communicating
>>> together, that's why I couldn't reproduce it using SC <-> gaim or SC <->
>>> iChat.
>>>
>>> In fact the updateRecord method works and the status is really changed.
>>> The
>>> problem is that the new status isn't retrieved correctly (it's not
>>> modified
>>> in the cache). So in fact, the problem comes from the JmDNS part of the
>>> project. Probably just modifying the updateInfos method should be enough,
>>> but it would need a bit of testing. I've quickly tried to change the DNS
>>> response we send so that the cache is made invalid in a nicer way (but it
>>> doesn't solve the problem at the moment) : instead of just sending an
>>> IN-unique message updating the cache, we first send the old record with
>>> TTL
>>> = 0 and afterwards the IN-unique message to force the cache flush. That's
>>> what other more advanced stacks seem to use (like avahi, the one from
>>> gaim),
>>> so that's probably the difference that makes the status change work with
>>> gaim/iChat and not with SC.
>>>
>>> I'll check that ASAP, but I've got my first exams after tomorrow, so I'm
>>> really short on time. Would it be possible to wait until the end of the
>>> exams period to do bug corrections?
>>>
>>> @Emil: do we need Bonjour to be integrated in the next days, or can it
>>> wait
>>> until the 15th of June?
>>>
>>> If it's really urgent, I'll try to find some free time to do it, but else
>>> I
>>> would really prefer doing it after the exams.
>>>
>>> Cheers,
>>> Chris.
>>>
>>> ----- Original Message ----- From: "Damian Minkov"
>>> <damencho@damencho.com>
>>> To: <dev@sip-communicator.dev.java.net>
>>> Sent: Monday, June 04, 2007 12:48 PM
>>> Subject: [sip-comm-dev] bonjour statuses
>>>
>>>
>>>> Hi Christian Vincenot,
>>>>
>>>> I'm integrating the project sc-bonjour into sip-communicator.
>>>> But I have found some bug in the protocol provider. Its related with
>>>> statuses. When a status change is received
>>>> it isn't processed properly. I found some problem in updateRecord method
>>>> in BonjourService. Where an incoming record is checked whether its
>>>> unique
>>>> or not which stops further processing.
>>>> And if this check is removed the record processing continues but again
>>>> its
>>>> not working.
>>>> I'm tring to figure this out but can you help solving the problem so I
>>>> can
>>>> commit the zeroconf protocol provider.
>>>>
>>>> damencho
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>> ---------------------------------------------------------------------
>> 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
>
>

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

--

(C) Matthew Rubenstein


#11

Hi Matt,

Thanks for the nice words!

We are trying to keep the roadmap relatively up to date
http://www.sip-communicator.org/index.php/Development/Roadmap#toc2

We'll try to bring out alpha2 at the end of the summer after work on GSoC projects has completed. There's no guarantee however that all features would make it in there, and some will most probably be postponed for alpha3.

Cheers
Emil

Matthew Rubenstein wrote:

···

  I want to chime in on how exciting it is to watch the last few
weeks/months new developments in SIP-Communicator. Emil's role in the
active community seems to be producing rapid jumps in quality and
features. A few months from now, S-C will be an even better landmark in
personal telecom.

  Is there a new revision of the roadmap, with featuresets and expected
timeframes, that takes the new developers and developments into account?

On Tue, 2007-06-19 at 17:45 +0200, Emil Ivov wrote:

Hi Chris,

I didn't get a chance to tell you this earlier so here I go now: You've done a very good job! This was really far from being trivial work and you've handled it very well! Congratulations!

We only need to stabilize it now. I've talked to you offline about a multiple interfaces problem. I've seen that JmDNS uses InetAddress.getLocalHost() and this causes trouble on multi homed machines.

There are two ways that we could handle this:

1. A single zeroconf account listens and broadcasts on all interfaces

2. We make the user select the interface an account should listen on, in the protocol wizard.

Personally I'd prefer one since most users would be perplexed when presented with the notion of a network interface.

Incidentally, I see now that users have the possibility to create multiple zeroconf accounts. Is there any reason for this? Perhaps it would be a good idea for the zeroconf account not to allow more than one such account (RSS does this).

That's all for now. Once again, thanks for contributing.

Cheers
Emil

Chris wrote:

Hi Damian,

I'm finished with exams now so I'll have some free time to crush those little ugly bugs one by one ;).

Chris.

----- Original Message ----- From: "Damian Minkov" <damencho@damencho.com>
To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 11, 2007 12:49 PM
Subject: Re: [sip-comm-dev] bonjour statuses

Hi Chris,

I've just committed the bonjour service and here is the few changes I've made.

1. Formatting of code.
2. Added entry in ProtocolNames and use it in all impl classes. So the variable is removed
   ZEROCONF_PROTOCOL_NAME from ProtocolProviderServiceZeroconfImpl.
3. Disable of the option "Remember Bonjour contacts?" in the Account Registration Wizard as its not used.

After you are free - after the exams it seems that we must test the statuses to clean all issues, as there are still problems.

Great - one more entry in protocol list :wink:

damencho

Chris wrote:

I've installed SC on another computer and I could reproduce the bug.
This problem is only happening when two SC clients are communicating
together, that's why I couldn't reproduce it using SC <-> gaim or SC <->
iChat.

In fact the updateRecord method works and the status is really changed. The
problem is that the new status isn't retrieved correctly (it's not modified
in the cache). So in fact, the problem comes from the JmDNS part of the
project. Probably just modifying the updateInfos method should be enough,
but it would need a bit of testing. I've quickly tried to change the DNS
response we send so that the cache is made invalid in a nicer way (but it
doesn't solve the problem at the moment) : instead of just sending an
IN-unique message updating the cache, we first send the old record with TTL
= 0 and afterwards the IN-unique message to force the cache flush. That's
what other more advanced stacks seem to use (like avahi, the one from gaim),
so that's probably the difference that makes the status change work with
gaim/iChat and not with SC.

I'll check that ASAP, but I've got my first exams after tomorrow, so I'm
really short on time. Would it be possible to wait until the end of the
exams period to do bug corrections?

@Emil: do we need Bonjour to be integrated in the next days, or can it wait
until the 15th of June?

If it's really urgent, I'll try to find some free time to do it, but else I
would really prefer doing it after the exams.

Cheers,
Chris.

----- Original Message ----- From: "Damian Minkov" <damencho@damencho.com>
To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 04, 2007 12:48 PM
Subject: [sip-comm-dev] bonjour statuses

Hi Christian Vincenot,

I'm integrating the project sc-bonjour into sip-communicator.
But I have found some bug in the protocol provider. Its related with
statuses. When a status change is received
it isn't processed properly. I found some problem in updateRecord method
in BonjourService. Where an incoming record is checked whether its unique
or not which stops further processing.
And if this check is removed the record processing continues but again its
not working.
I'm tring to figure this out but can you help solving the problem so I can
commit the zeroconf protocol provider.

damencho

---------------------------------------------------------------------
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

---------------------------------------------------------------------
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

---------------------------------------------------------------------
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


#12

Hi Emil,

Thanks for your kind words . I hope I'll be able to produce some good work in the future, especially during GSoC.

About handling multiple interfaces, I fully agree, asking users to choose an interface would be confusing. Shouldn't be too much of a problem to find a way to handle this within JmDNS. I'll do this ASAP.
As a consequence, having multiple accounts is totally useless (btw, iChat doesn't support multiple instances on the same computer AFAIK).

Cheers,
Chris.

···

----- Original Message -----

From: "Emil Ivov" <emcho@emcho.com>

To: <dev@sip-communicator.dev.java.net>
Sent: Tuesday, June 19, 2007 5:45 PM
Subject: Re: [sip-comm-dev] bonjour statuses

Hi Chris,

I didn't get a chance to tell you this earlier so here I go now: You've done a very good job! This was really far from being trivial work and you've handled it very well! Congratulations!

We only need to stabilize it now. I've talked to you offline about a multiple interfaces problem. I've seen that JmDNS uses InetAddress.getLocalHost() and this causes trouble on multi homed machines.

There are two ways that we could handle this:

1. A single zeroconf account listens and broadcasts on all interfaces

2. We make the user select the interface an account should listen on, in the protocol wizard.

Personally I'd prefer one since most users would be perplexed when presented with the notion of a network interface.

Incidentally, I see now that users have the possibility to create multiple zeroconf accounts. Is there any reason for this? Perhaps it would be a good idea for the zeroconf account not to allow more than one such account (RSS does this).

That's all for now. Once again, thanks for contributing.

Cheers
Emil

Chris wrote:

Hi Damian,

I'm finished with exams now so I'll have some free time to crush those little ugly bugs one by one ;).

Chris.

----- Original Message ----- From: "Damian Minkov" <damencho@damencho.com>
To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 11, 2007 12:49 PM
Subject: Re: [sip-comm-dev] bonjour statuses

Hi Chris,

I've just committed the bonjour service and here is the few changes I've made.

1. Formatting of code.
2. Added entry in ProtocolNames and use it in all impl classes. So the variable is removed
   ZEROCONF_PROTOCOL_NAME from ProtocolProviderServiceZeroconfImpl.
3. Disable of the option "Remember Bonjour contacts?" in the Account Registration Wizard as its not used.

After you are free - after the exams it seems that we must test the statuses to clean all issues, as there are still problems.

Great - one more entry in protocol list :wink:

damencho

Chris wrote:

I've installed SC on another computer and I could reproduce the bug.
This problem is only happening when two SC clients are communicating
together, that's why I couldn't reproduce it using SC <-> gaim or SC <->
iChat.

In fact the updateRecord method works and the status is really changed. The
problem is that the new status isn't retrieved correctly (it's not modified
in the cache). So in fact, the problem comes from the JmDNS part of the
project. Probably just modifying the updateInfos method should be enough,
but it would need a bit of testing. I've quickly tried to change the DNS
response we send so that the cache is made invalid in a nicer way (but it
doesn't solve the problem at the moment) : instead of just sending an
IN-unique message updating the cache, we first send the old record with TTL
= 0 and afterwards the IN-unique message to force the cache flush. That's
what other more advanced stacks seem to use (like avahi, the one from gaim),
so that's probably the difference that makes the status change work with
gaim/iChat and not with SC.

I'll check that ASAP, but I've got my first exams after tomorrow, so I'm
really short on time. Would it be possible to wait until the end of the
exams period to do bug corrections?

@Emil: do we need Bonjour to be integrated in the next days, or can it wait
until the 15th of June?

If it's really urgent, I'll try to find some free time to do it, but else I
would really prefer doing it after the exams.

Cheers,
Chris.

----- Original Message ----- From: "Damian Minkov" <damencho@damencho.com>
To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 04, 2007 12:48 PM
Subject: [sip-comm-dev] bonjour statuses

Hi Christian Vincenot,

I'm integrating the project sc-bonjour into sip-communicator.
But I have found some bug in the protocol provider. Its related with
statuses. When a status change is received
it isn't processed properly. I found some problem in updateRecord method
in BonjourService. Where an incoming record is checked whether its unique
or not which stops further processing.
And if this check is removed the record processing continues but again its
not working.
I'm tring to figure this out but can you help solving the problem so I can
commit the zeroconf protocol provider.

damencho

---------------------------------------------------------------------
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

---------------------------------------------------------------------
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

---------------------------------------------------------------------
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


#13

"Implement support for IAX":
https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=298

Is no one currently working on adding IAX protocol to S-C?

···

On Tue, 2007-06-19 at 19:26 +0200, Emil Ivov wrote:

Hi Matt,

Thanks for the nice words!

We are trying to keep the roadmap relatively up to date
http://www.sip-communicator.org/index.php/Development/Roadmap#toc2

We'll try to bring out alpha2 at the end of the summer after work on
GSoC projects has completed. There's no guarantee however that all
features would make it in there, and some will most probably be
postponed for alpha3.

Cheers
Emil

Matthew Rubenstein wrote:
> I want to chime in on how exciting it is to watch the last few
> weeks/months new developments in SIP-Communicator. Emil's role in the
> active community seems to be producing rapid jumps in quality and
> features. A few months from now, S-C will be an even better landmark in
> personal telecom.
>
> Is there a new revision of the roadmap, with featuresets and expected
> timeframes, that takes the new developers and developments into account?
>
>
> On Tue, 2007-06-19 at 17:45 +0200, Emil Ivov wrote:
>> Hi Chris,
>>
>> I didn't get a chance to tell you this earlier so here I go now: You've
>> done a very good job! This was really far from being trivial work and
>> you've handled it very well! Congratulations!
>>
>> We only need to stabilize it now. I've talked to you offline about a
>> multiple interfaces problem. I've seen that JmDNS uses
>> InetAddress.getLocalHost() and this causes trouble on multi homed machines.
>>
>> There are two ways that we could handle this:
>>
>> 1. A single zeroconf account listens and broadcasts on all interfaces
>>
>> 2. We make the user select the interface an account should listen on, in
>> the protocol wizard.
>>
>> Personally I'd prefer one since most users would be perplexed when
>> presented with the notion of a network interface.
>>
>> Incidentally, I see now that users have the possibility to create
>> multiple zeroconf accounts. Is there any reason for this? Perhaps it
>> would be a good idea for the zeroconf account not to allow more than one
>> such account (RSS does this).
>>
>> That's all for now. Once again, thanks for contributing.
>>
>> Cheers
>> Emil
>>
>>
>> Chris wrote:
>>> Hi Damian,
>>>
>>> I'm finished with exams now so I'll have some free time to crush those
>>> little ugly bugs one by one ;).
>>>
>>> Chris.
>>>
>>> ----- Original Message -----
>>> From: "Damian Minkov" <damencho@damencho.com>
>>> To: <dev@sip-communicator.dev.java.net>
>>> Sent: Monday, June 11, 2007 12:49 PM
>>> Subject: Re: [sip-comm-dev] bonjour statuses
>>>
>>>
>>>> Hi Chris,
>>>>
>>>> I've just committed the bonjour service and here is the few changes I've
>>>> made.
>>>>
>>>> 1. Formatting of code.
>>>> 2. Added entry in ProtocolNames and use it in all impl classes. So the
>>>> variable is removed
>>>> ZEROCONF_PROTOCOL_NAME from ProtocolProviderServiceZeroconfImpl.
>>>> 3. Disable of the option "Remember Bonjour contacts?" in the Account
>>>> Registration Wizard as its not used.
>>>>
>>>> After you are free - after the exams it seems that we must test the
>>>> statuses to clean all issues, as there are still problems.
>>>>
>>>> Great - one more entry in protocol list :wink:
>>>>
>>>> damencho
>>>>
>>>>
>>>> Chris wrote:
>>>>> I've installed SC on another computer and I could reproduce the bug.
>>>>> This problem is only happening when two SC clients are communicating
>>>>> together, that's why I couldn't reproduce it using SC <-> gaim or SC <->
>>>>> iChat.
>>>>>
>>>>> In fact the updateRecord method works and the status is really changed.
>>>>> The
>>>>> problem is that the new status isn't retrieved correctly (it's not
>>>>> modified
>>>>> in the cache). So in fact, the problem comes from the JmDNS part of the
>>>>> project. Probably just modifying the updateInfos method should be enough,
>>>>> but it would need a bit of testing. I've quickly tried to change the DNS
>>>>> response we send so that the cache is made invalid in a nicer way (but it
>>>>> doesn't solve the problem at the moment) : instead of just sending an
>>>>> IN-unique message updating the cache, we first send the old record with
>>>>> TTL
>>>>> = 0 and afterwards the IN-unique message to force the cache flush. That's
>>>>> what other more advanced stacks seem to use (like avahi, the one from
>>>>> gaim),
>>>>> so that's probably the difference that makes the status change work with
>>>>> gaim/iChat and not with SC.
>>>>>
>>>>> I'll check that ASAP, but I've got my first exams after tomorrow, so I'm
>>>>> really short on time. Would it be possible to wait until the end of the
>>>>> exams period to do bug corrections?
>>>>>
>>>>> @Emil: do we need Bonjour to be integrated in the next days, or can it
>>>>> wait
>>>>> until the 15th of June?
>>>>>
>>>>> If it's really urgent, I'll try to find some free time to do it, but else
>>>>> I
>>>>> would really prefer doing it after the exams.
>>>>>
>>>>> Cheers,
>>>>> Chris.
>>>>>
>>>>> ----- Original Message ----- From: "Damian Minkov"
>>>>> <damencho@damencho.com>
>>>>> To: <dev@sip-communicator.dev.java.net>
>>>>> Sent: Monday, June 04, 2007 12:48 PM
>>>>> Subject: [sip-comm-dev] bonjour statuses
>>>>>
>>>>>
>>>>>> Hi Christian Vincenot,
>>>>>>
>>>>>> I'm integrating the project sc-bonjour into sip-communicator.
>>>>>> But I have found some bug in the protocol provider. Its related with
>>>>>> statuses. When a status change is received
>>>>>> it isn't processed properly. I found some problem in updateRecord method
>>>>>> in BonjourService. Where an incoming record is checked whether its
>>>>>> unique
>>>>>> or not which stops further processing.
>>>>>> And if this check is removed the record processing continues but again
>>>>>> its
>>>>>> not working.
>>>>>> I'm tring to figure this out but can you help solving the problem so I
>>>>>> can
>>>>>> commit the zeroconf protocol provider.
>>>>>>
>>>>>> damencho
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>> ---------------------------------------------------------------------
>> 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

--

(C) Matthew Rubenstein

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


#14

Mea maxima culpa : I took a quick look and I think I've got it (BonjourService:109) :

···

-------------------
changeStatus(opSetPersPresence.getPresenceStatus());

sock = createSocket(port);
if (sock == null) return;
-------------------

This is completely stupid. I've must have added that while debugging. The socket creation method chooses a free port number on which the main socket (the one from BonjourService, dispatching incoming connections to ClientThreads' spawned sockets) should listen. The changeStatus() method registers the service with JmDNS. So here we've got a problem : in this order, the port number isn't always assigned before the registration, so changeStatus() registers the service without the port.p2pj field, causing the problem seen on emcho's side.

In fact, the changeStatus call in the BonjourService constructor is not relevant anymore. AFAIK, ChangeStatus is called automatically by SC.

Erasing the changeStatus call should make the problem disappear, but I'll add some checks in changeStatus to be sure that no other races happen.

I can't test if this now, but I'll have the opportunity to do it tomorrow. I'll see if this was the only problem.

Chris.

----- Original Message -----

From: "Chris" <sipcom@cyberspace7.net>

To: <dev@sip-communicator.dev.java.net>
Sent: Tuesday, June 19, 2007 9:38 PM
Subject: Re: [sip-comm-dev] bonjour statuses

Hi Emil,

Thanks for your kind words . I hope I'll be able to produce some good work in the future, especially during GSoC.

About handling multiple interfaces, I fully agree, asking users to choose an interface would be confusing. Shouldn't be too much of a problem to find a way to handle this within JmDNS. I'll do this ASAP.
As a consequence, having multiple accounts is totally useless (btw, iChat doesn't support multiple instances on the same computer AFAIK).

Cheers,
Chris.

----- Original Message ----- From: "Emil Ivov" <emcho@emcho.com>
To: <dev@sip-communicator.dev.java.net>
Sent: Tuesday, June 19, 2007 5:45 PM
Subject: Re: [sip-comm-dev] bonjour statuses

Hi Chris,

I didn't get a chance to tell you this earlier so here I go now: You've done a very good job! This was really far from being trivial work and you've handled it very well! Congratulations!

We only need to stabilize it now. I've talked to you offline about a multiple interfaces problem. I've seen that JmDNS uses InetAddress.getLocalHost() and this causes trouble on multi homed machines.

There are two ways that we could handle this:

1. A single zeroconf account listens and broadcasts on all interfaces

2. We make the user select the interface an account should listen on, in the protocol wizard.

Personally I'd prefer one since most users would be perplexed when presented with the notion of a network interface.

Incidentally, I see now that users have the possibility to create multiple zeroconf accounts. Is there any reason for this? Perhaps it would be a good idea for the zeroconf account not to allow more than one such account (RSS does this).

That's all for now. Once again, thanks for contributing.

Cheers
Emil

Chris wrote:

Hi Damian,

I'm finished with exams now so I'll have some free time to crush those little ugly bugs one by one ;).

Chris.

----- Original Message ----- From: "Damian Minkov" <damencho@damencho.com>
To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 11, 2007 12:49 PM
Subject: Re: [sip-comm-dev] bonjour statuses

Hi Chris,

I've just committed the bonjour service and here is the few changes I've made.

1. Formatting of code.
2. Added entry in ProtocolNames and use it in all impl classes. So the variable is removed
   ZEROCONF_PROTOCOL_NAME from ProtocolProviderServiceZeroconfImpl.
3. Disable of the option "Remember Bonjour contacts?" in the Account Registration Wizard as its not used.

After you are free - after the exams it seems that we must test the statuses to clean all issues, as there are still problems.

Great - one more entry in protocol list :wink:

damencho

Chris wrote:

I've installed SC on another computer and I could reproduce the bug.
This problem is only happening when two SC clients are communicating
together, that's why I couldn't reproduce it using SC <-> gaim or SC <->
iChat.

In fact the updateRecord method works and the status is really changed. The
problem is that the new status isn't retrieved correctly (it's not modified
in the cache). So in fact, the problem comes from the JmDNS part of the
project. Probably just modifying the updateInfos method should be enough,
but it would need a bit of testing. I've quickly tried to change the DNS
response we send so that the cache is made invalid in a nicer way (but it
doesn't solve the problem at the moment) : instead of just sending an
IN-unique message updating the cache, we first send the old record with TTL
= 0 and afterwards the IN-unique message to force the cache flush. That's
what other more advanced stacks seem to use (like avahi, the one from gaim),
so that's probably the difference that makes the status change work with
gaim/iChat and not with SC.

I'll check that ASAP, but I've got my first exams after tomorrow, so I'm
really short on time. Would it be possible to wait until the end of the
exams period to do bug corrections?

@Emil: do we need Bonjour to be integrated in the next days, or can it wait
until the 15th of June?

If it's really urgent, I'll try to find some free time to do it, but else I
would really prefer doing it after the exams.

Cheers,
Chris.

----- Original Message ----- From: "Damian Minkov" <damencho@damencho.com>
To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 04, 2007 12:48 PM
Subject: [sip-comm-dev] bonjour statuses

Hi Christian Vincenot,

I'm integrating the project sc-bonjour into sip-communicator.
But I have found some bug in the protocol provider. Its related with
statuses. When a status change is received
it isn't processed properly. I found some problem in updateRecord method
in BonjourService. Where an incoming record is checked whether its unique
or not which stops further processing.
And if this check is removed the record processing continues but again its
not working.
I'm tring to figure this out but can you help solving the problem so I can
commit the zeroconf protocol provider.

damencho

---------------------------------------------------------------------
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

---------------------------------------------------------------------
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

---------------------------------------------------------------------
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

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


#15

Matt,

Jean-Marie Heitz (CC-ed here) has implemented a first version, but we still needed to address some issues with media. It's been a while since I've last talked to him, however, so I don't know what the current status is.

Perhaps he'll give us an update if he has the time.

Cheers
Emil

Matthew Rubenstein wrote:

···

  "Implement support for IAX":
https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=298

Is no one currently working on adding IAX protocol to S-C?

On Tue, 2007-06-19 at 19:26 +0200, Emil Ivov wrote:

Hi Matt,

Thanks for the nice words!

We are trying to keep the roadmap relatively up to date
http://www.sip-communicator.org/index.php/Development/Roadmap#toc2

We'll try to bring out alpha2 at the end of the summer after work on GSoC projects has completed. There's no guarantee however that all features would make it in there, and some will most probably be postponed for alpha3.

Cheers
Emil

Matthew Rubenstein wrote:

  I want to chime in on how exciting it is to watch the last few
weeks/months new developments in SIP-Communicator. Emil's role in the
active community seems to be producing rapid jumps in quality and
features. A few months from now, S-C will be an even better landmark in
personal telecom.

  Is there a new revision of the roadmap, with featuresets and expected
timeframes, that takes the new developers and developments into account?

On Tue, 2007-06-19 at 17:45 +0200, Emil Ivov wrote:

Hi Chris,

I didn't get a chance to tell you this earlier so here I go now: You've done a very good job! This was really far from being trivial work and you've handled it very well! Congratulations!

We only need to stabilize it now. I've talked to you offline about a multiple interfaces problem. I've seen that JmDNS uses InetAddress.getLocalHost() and this causes trouble on multi homed machines.

There are two ways that we could handle this:

1. A single zeroconf account listens and broadcasts on all interfaces

2. We make the user select the interface an account should listen on, in the protocol wizard.

Personally I'd prefer one since most users would be perplexed when presented with the notion of a network interface.

Incidentally, I see now that users have the possibility to create multiple zeroconf accounts. Is there any reason for this? Perhaps it would be a good idea for the zeroconf account not to allow more than one such account (RSS does this).

That's all for now. Once again, thanks for contributing.

Cheers
Emil

Chris wrote:

Hi Damian,

I'm finished with exams now so I'll have some free time to crush those little ugly bugs one by one ;).

Chris.

----- Original Message ----- From: "Damian Minkov" <damencho@damencho.com>
To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 11, 2007 12:49 PM
Subject: Re: [sip-comm-dev] bonjour statuses

Hi Chris,

I've just committed the bonjour service and here is the few changes I've made.

1. Formatting of code.
2. Added entry in ProtocolNames and use it in all impl classes. So the variable is removed
   ZEROCONF_PROTOCOL_NAME from ProtocolProviderServiceZeroconfImpl.
3. Disable of the option "Remember Bonjour contacts?" in the Account Registration Wizard as its not used.

After you are free - after the exams it seems that we must test the statuses to clean all issues, as there are still problems.

Great - one more entry in protocol list :wink:

damencho

Chris wrote:

I've installed SC on another computer and I could reproduce the bug.
This problem is only happening when two SC clients are communicating
together, that's why I couldn't reproduce it using SC <-> gaim or SC <->
iChat.

In fact the updateRecord method works and the status is really changed. The
problem is that the new status isn't retrieved correctly (it's not modified
in the cache). So in fact, the problem comes from the JmDNS part of the
project. Probably just modifying the updateInfos method should be enough,
but it would need a bit of testing. I've quickly tried to change the DNS
response we send so that the cache is made invalid in a nicer way (but it
doesn't solve the problem at the moment) : instead of just sending an
IN-unique message updating the cache, we first send the old record with TTL
= 0 and afterwards the IN-unique message to force the cache flush. That's
what other more advanced stacks seem to use (like avahi, the one from gaim),
so that's probably the difference that makes the status change work with
gaim/iChat and not with SC.

I'll check that ASAP, but I've got my first exams after tomorrow, so I'm
really short on time. Would it be possible to wait until the end of the
exams period to do bug corrections?

@Emil: do we need Bonjour to be integrated in the next days, or can it wait
until the 15th of June?

If it's really urgent, I'll try to find some free time to do it, but else I
would really prefer doing it after the exams.

Cheers,
Chris.

----- Original Message ----- From: "Damian Minkov" <damencho@damencho.com>
To: <dev@sip-communicator.dev.java.net>
Sent: Monday, June 04, 2007 12:48 PM
Subject: [sip-comm-dev] bonjour statuses

Hi Christian Vincenot,

I'm integrating the project sc-bonjour into sip-communicator.
But I have found some bug in the protocol provider. Its related with
statuses. When a status change is received
it isn't processed properly. I found some problem in updateRecord method
in BonjourService. Where an incoming record is checked whether its unique
or not which stops further processing.
And if this check is removed the record processing continues but again its
not working.
I'm tring to figure this out but can you help solving the problem so I can
commit the zeroconf protocol provider.

damencho

---------------------------------------------------------------------
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

---------------------------------------------------------------------
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

---------------------------------------------------------------------
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

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