[sip-comm-dev] Adding a SIP p2p mode without registrar


#1

Hi all!

Here's another followup to an e-mail discussion with Emil, where I told him
about a feature which I have added to my private branch of SIP Communicator.
We thought that would be of general interest.

I wrote:
* I've added a ProtocolProviderServiceSipNoRegistrarImpl, which allows

you

to make P2P SIP calls without having to register with a SIP registrar

first

(it just fakes the REGISTERED state of the

ProtocolProviderServiceSipImpl).

Emil wrote:
This is also very nice, but I wonder what would be the best way to add
it to SIP Communicator. A separate provider would virtually mean
branching the sip protocol implementation and then making sure that all
bug fixes to one of the branches, are also copied to the other.

Couldn't we somehow add this as an option in the wizard?

Alternately, if you don't have the time to work on it any more, we could
create an optional downloadable plugin and make it available as soon as
we have our online repository.

My change to the existing code isn't really big. I've refactored the
ProtocolProviderServiceSipImpl into an
AbstractProtocolProviderServiceSipImpl with implementations
ProtocolProviderServiceSipImpl and
ProtocolProviderServiceSipNoRegistrarImpl. The
ProtocolProviderFactorySipImpl chooses the implementation to use when
loading the account based on a new account property NO_REGISTRAR. This
property could be set by the account wizard. The
ProtocolProviderServiceSipNoRegistrarImpl simply doesn't contain the
registering code of the ProtocolProviderServiceSipImpl and say it is
registered at once when the register method is called. It also does only
support the OperationSetBasicTelephony and OperationSetDTMF, since I don't
know if the others will work without a registrar and didn't need them.

If you are interested in this functionality, I could prepare a patch.
Someone else would have to do the work of adapting the account wizard to
support the option of not using a wizard, since unfortunately I don't have
the time to do this.

Regards
Michael Koch


#2

This is a great idea! Other phones like SJ Phone operate in this mode
too.
One should not be forced to use a registrar especially when operating in
a LAN environment with several phones whose addresses are known.

···

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

From: Koch Michael [mailto:MKoch@rowa.de]

Sent: Friday, 9 November 2007 5:08 PM
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Adding a SIP p2p mode without registrar

Hi all!

Here's another followup to an e-mail discussion with Emil, where I told
him
about a feature which I have added to my private branch of SIP
Communicator.
We thought that would be of general interest.

I wrote:
* I've added a ProtocolProviderServiceSipNoRegistrarImpl, which

allows
you

to make P2P SIP calls without having to register with a SIP registrar

first

(it just fakes the REGISTERED state of the

ProtocolProviderServiceSipImpl).

Emil wrote:
This is also very nice, but I wonder what would be the best way to add
it to SIP Communicator. A separate provider would virtually mean
branching the sip protocol implementation and then making sure that all
bug fixes to one of the branches, are also copied to the other.

Couldn't we somehow add this as an option in the wizard?

Alternately, if you don't have the time to work on it any more, we

could

create an optional downloadable plugin and make it available as soon as
we have our online repository.

My change to the existing code isn't really big. I've refactored the
ProtocolProviderServiceSipImpl into an
AbstractProtocolProviderServiceSipImpl with implementations
ProtocolProviderServiceSipImpl and
ProtocolProviderServiceSipNoRegistrarImpl. The
ProtocolProviderFactorySipImpl chooses the implementation to use when
loading the account based on a new account property NO_REGISTRAR. This
property could be set by the account wizard. The
ProtocolProviderServiceSipNoRegistrarImpl simply doesn't contain the
registering code of the ProtocolProviderServiceSipImpl and say it is
registered at once when the register method is called. It also does only
support the OperationSetBasicTelephony and OperationSetDTMF, since I
don't
know if the others will work without a registrar and didn't need them.

If you are interested in this functionality, I could prepare a patch.
Someone else would have to do the work of adapting the account wizard to
support the option of not using a wizard, since unfortunately I don't
have
the time to do this.

Regards
Michael Koch

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


#3

Hi Michael,

Yes we'd be interested to have that. I believe it would be best to
integrate it in the existing provider so that we don't have to maintain
two forks of the same code.

If you don't have the time to do this you could post a patch as you
suggest. Personally I won't have the time to work on it either ... at
least not during the following two or three months, but once it's on
the list someone else might want to play with it.

Thanks!
Emil

Koch Michael wrote:

···

Hi all!

Here's another followup to an e-mail discussion with Emil, where I told him
about a feature which I have added to my private branch of SIP Communicator.
We thought that would be of general interest.

I wrote:
* I've added a ProtocolProviderServiceSipNoRegistrarImpl, which allows

you

to make P2P SIP calls without having to register with a SIP registrar

first

(it just fakes the REGISTERED state of the

ProtocolProviderServiceSipImpl).

Emil wrote:
This is also very nice, but I wonder what would be the best way to add
it to SIP Communicator. A separate provider would virtually mean
branching the sip protocol implementation and then making sure that all
bug fixes to one of the branches, are also copied to the other.

Couldn't we somehow add this as an option in the wizard?

Alternately, if you don't have the time to work on it any more, we could
create an optional downloadable plugin and make it available as soon as
we have our online repository.

My change to the existing code isn't really big. I've refactored the
ProtocolProviderServiceSipImpl into an
AbstractProtocolProviderServiceSipImpl with implementations
ProtocolProviderServiceSipImpl and
ProtocolProviderServiceSipNoRegistrarImpl. The
ProtocolProviderFactorySipImpl chooses the implementation to use when
loading the account based on a new account property NO_REGISTRAR. This
property could be set by the account wizard. The
ProtocolProviderServiceSipNoRegistrarImpl simply doesn't contain the
registering code of the ProtocolProviderServiceSipImpl and say it is
registered at once when the register method is called. It also does only
support the OperationSetBasicTelephony and OperationSetDTMF, since I don't
know if the others will work without a registrar and didn't need them.

If you are interested in this functionality, I could prepare a patch.
Someone else would have to do the work of adapting the account wizard to
support the option of not using a wizard, since unfortunately I don't have
the time to do this.

Regards
Michael Koch

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


#4

Yes we'd be interested to have that. I believe it would be best to
integrate it in the existing provider so that we don't have
to maintain
two forks of the same code.

If you don't have the time to do this you could post a patch as you
suggest. Personally I won't have the time to work on it either ... at
least not during the following two or three months, but once it's on
the list someone else might want to play with it.

I'll prepare a patch to the protocol.sip backend and post it soon. The patch
shouldn't change the current behaviour, so when you've inspected it and
think my approach is ok, I could add it in the trunk. Then it would be up to
someone else to modify the account registration wizard to let you create a
registrar-less account.

Cheers
Michael Koch

···

Thanks!
Emil

Koch Michael wrote:
> Hi all!
>
> Here's another followup to an e-mail discussion with Emil,
where I told him
> about a feature which I have added to my private branch of
SIP Communicator.
> We thought that would be of general interest.
>
>>> I wrote:
>>> * I've added a ProtocolProviderServiceSipNoRegistrarImpl,
which allows
> you
>>> to make P2P SIP calls without having to register with a
SIP registrar
> first
>>> (it just fakes the REGISTERED state of the
> ProtocolProviderServiceSipImpl).
>> Emil wrote:
>> This is also very nice, but I wonder what would be the
best way to add
>> it to SIP Communicator. A separate provider would virtually mean
>> branching the sip protocol implementation and then making
sure that all
>> bug fixes to one of the branches, are also copied to the other.
>>
>> Couldn't we somehow add this as an option in the wizard?
>>
>> Alternately, if you don't have the time to work on it any
more, we could
>> create an optional downloadable plugin and make it
available as soon as
>> we have our online repository.
>
> My change to the existing code isn't really big. I've refactored the
> ProtocolProviderServiceSipImpl into an
> AbstractProtocolProviderServiceSipImpl with implementations
> ProtocolProviderServiceSipImpl and
> ProtocolProviderServiceSipNoRegistrarImpl. The
> ProtocolProviderFactorySipImpl chooses the implementation
to use when
> loading the account based on a new account property
NO_REGISTRAR. This
> property could be set by the account wizard. The
> ProtocolProviderServiceSipNoRegistrarImpl simply doesn't contain the
> registering code of the ProtocolProviderServiceSipImpl and say it is
> registered at once when the register method is called. It
also does only
> support the OperationSetBasicTelephony and
OperationSetDTMF, since I don't
> know if the others will work without a registrar and didn't
need them.
>
> If you are interested in this functionality, I could
prepare a patch.
> Someone else would have to do the work of adapting the
account wizard to
> support the option of not using a wizard, since
unfortunately I don't have
> the time to do this.
>
> Regards
> Michael Koch

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

I've created an issue for this feature:
https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=412

Attached is a patch which changes the SIP implementation of the
ProtocolProviderServiceSipImpl to support both modes. It works, just as I
outlined previously, by splitting the ProtocolProviderServiceSipImpl into an
abstract base class and two implementations for accounts with and without
registrar. Most of the code from ProtocolProviderServiceSipImpl has been
moved to the AbstractProtocolProviderServiceSipImpl, with only the
registrar-specific code (and some OperationSet-specific stuff) remaining in
the ProtocolProviderServiceSipImpl. The
ProtocolProviderServiceSipNoRegistrarImpl is trivial. The
ProtocolProviderFactorySipImpl chooses the implementation to use for an
account based on a new account property NO_REGISTRAR.

I think that this split is the most maintainable approach. The
implementations share most of the code, and the parts in which they differ
are clearly separated and documented. While I think that the code could be
committed to the trunk without breaking any existing behaviour, I'd like you
to examine the patch and look if you like the approach first. Note that
while the diff touches many files, most of the changes are only due to the
renaming of ProtocolProviderServiceSipImpl ->
AbstractProtocolProviderServiceSipImpl.

I've also thought that since with subversion branching is cheap and easy I
could create a development branch for this issue and commit the change there
so that others can preview the changes and perhaps work on the frontend
(account creation wizard) in the branch before the changes are moved into
the trunk.

Cheers
Michael Koch

sip-comm-issue412.diff (121 KB)

···

Hi Michael,

Yes we'd be interested to have that. I believe it would be best to
integrate it in the existing provider so that we don't have
to maintain
two forks of the same code.

If you don't have the time to do this you could post a patch as you
suggest. Personally I won't have the time to work on it either ... at
least not during the following two or three months, but once it's on
the list someone else might want to play with it.

Thanks!
Emil

Koch Michael wrote:
> Hi all!
>
> Here's another followup to an e-mail discussion with Emil,
where I told him
> about a feature which I have added to my private branch of
SIP Communicator.
> We thought that would be of general interest.
>
>>> I wrote:
>>> * I've added a ProtocolProviderServiceSipNoRegistrarImpl,
which allows
> you
>>> to make P2P SIP calls without having to register with a
SIP registrar
> first
>>> (it just fakes the REGISTERED state of the
> ProtocolProviderServiceSipImpl).
>> Emil wrote:
>> This is also very nice, but I wonder what would be the
best way to add
>> it to SIP Communicator. A separate provider would virtually mean
>> branching the sip protocol implementation and then making
sure that all
>> bug fixes to one of the branches, are also copied to the other.
>>
>> Couldn't we somehow add this as an option in the wizard?
>>
>> Alternately, if you don't have the time to work on it any
more, we could
>> create an optional downloadable plugin and make it
available as soon as
>> we have our online repository.
>
> My change to the existing code isn't really big. I've refactored the
> ProtocolProviderServiceSipImpl into an
> AbstractProtocolProviderServiceSipImpl with implementations
> ProtocolProviderServiceSipImpl and
> ProtocolProviderServiceSipNoRegistrarImpl. The
> ProtocolProviderFactorySipImpl chooses the implementation
to use when
> loading the account based on a new account property
NO_REGISTRAR. This
> property could be set by the account wizard. The
> ProtocolProviderServiceSipNoRegistrarImpl simply doesn't contain the
> registering code of the ProtocolProviderServiceSipImpl and say it is
> registered at once when the register method is called. It
also does only
> support the OperationSetBasicTelephony and
OperationSetDTMF, since I don't
> know if the others will work without a registrar and didn't
need them.
>
> If you are interested in this functionality, I could
prepare a patch.
> Someone else would have to do the work of adapting the
account wizard to
> support the option of not using a wizard, since
unfortunately I don't have
> the time to do this.
>
> Regards
> Michael Koch