[sip-comm-dev] Multiple accounts, unique contact headers


#1

Hi all,

Since the single stack patch has been applied, all incoming SIP requests
have to be dispatched between accounts. The only distinctive element we
can rely on appears to be the contact address in the Request-URI:

INVITE sip:user@192.168.0.2:5060;transport=udp SIP/2.0

When using a registrar account, the remote UA retrieves the contact
address related to our address-of-record (AOR) from the registrar.
Currently, SC uses the username part of the AOR as username part of the
contact address. This lead to ambiguities when several registrar
accounts share the same username in their AOR:

AOR: user@providerA, registered contact address: user@ip
AOR: user@providerB, registered contact address: user@ip
P2P account: user@, contact address: user@ip

To prevent such ambiguities, I propose to build unique contact addresses
for registrar accounts only, such as:

AOR: user@providerA, registered contact address: user_providerA@ip
AOR: user@providerB, registered contact address: user_providerB@ip
P2P account: user@, contact address: user@ip

Of course, we would then have to prevent the creation of a P2P account
with username "user_providerA". Such a behaviour is already implemented
by Ekiga, but can be turned off. I've attached the error window which is
shown when it it disabled and an ambiguity exist.

I remember there were arguments against this solution, but I don't
remember which. What do you all think?

Cheers,

···

--
Sébastien Mazy


#2

Hey Seb,

We did discuss this already on the phone but for the record:

Yes that sounds reasonable.

The one argument against this solution was the fact that some providers
(reportedly vonage) would not let you register if the user part in the
contact header does not match your authentication identifier. We should
therefore make sure that this behavior can be easily turned off.

We also discussed the fact that we should only modify the user part of
the contact URI if there is a conflict in the existing accounts. This
would indeed cause a problem if a P2P account is created right after the
registration of a registrar account but we can live with that.

Cheers
Emil

Sébastien Mazy wrote:

···

Hi all,

Since the single stack patch has been applied, all incoming SIP requests
have to be dispatched between accounts. The only distinctive element we
can rely on appears to be the contact address in the Request-URI:

INVITE sip:user@192.168.0.2:5060;transport=udp SIP/2.0

When using a registrar account, the remote UA retrieves the contact
address related to our address-of-record (AOR) from the registrar.
Currently, SC uses the username part of the AOR as username part of the
contact address. This lead to ambiguities when several registrar
accounts share the same username in their AOR:

AOR: user@providerA, registered contact address: user@ip
AOR: user@providerB, registered contact address: user@ip
P2P account: user@, contact address: user@ip

To prevent such ambiguities, I propose to build unique contact addresses
for registrar accounts only, such as:

AOR: user@providerA, registered contact address: user_providerA@ip
AOR: user@providerB, registered contact address: user_providerB@ip
P2P account: user@, contact address: user@ip

Of course, we would then have to prevent the creation of a P2P account
with username "user_providerA". Such a behaviour is already implemented
by Ekiga, but can be turned off. I've attached the error window which is
shown when it it disabled and an ambiguity exist.

I remember there were arguments against this solution, but I don't
remember which. What do you all think?

Cheers,

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

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

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

The one argument against this solution was the fact that some providers
(reportedly vonage) would not let you register if the user part in the
contact header does not match your authentication identifier. We should
therefore make sure that this behavior can be easily turned off.

That's the big problem indeed: a few broken registrars/proxies (I don't
know to what extent).

We also discussed the fact that we should only modify the user part of
the contact URI if there is a conflict in the existing accounts. This
would indeed cause a problem if a P2P account is created right after the
registration of a registrar account but we can live with that.

This turns to be tricky to implement and would be a temporary solution
since it doesn't fix everything. I'm rather lazy so I've looked for
another solution that could do the trick: instead of using the username
in the contact address, adding a new parameter to it. This has worked so
far with all providers I've tested.

As it's always easier to explain with an example, here is it:

AOR: user@providerA.com
-> registered contact address: userA@ip;registering_acc=providerA_com
AOR: user@providerB.com
-> registered contact address: user@ip;registering_acc=providerB_com
P2P account: user@, contact address: user@ip

The dots in the parameter value are replaced with '_' because some
stupid registrars will think we replaced the ip by their hostname and
throw an error.

I've commited it in svn r4884 so please report any regressions. Of
course, it is still not sure whether this will work in all cases so I
would be happy to replace it with a better solution. In particular, I
don't know if it works better than the previous solution with Vonage
(couln't test as it doesn't seem possible to get a free account with
them).

By the way, it's quite easy to test if it broke your SIP account:
- can you still register your registrar account?
- can you still receive a call on your registrar account? (using your
   address-of-record me@myprovider.com, not a direct P2P call)
- if you have time, check the INVITE received with an incoming call
   contains "registering_acc=provider_com" on its first line

Cheers,

···

On Wed, Jan 07, 2009 at 12:00:41PM +0100, 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