[sip-comm-dev] SIP Details


#1

Hi
I tried to enter my username in sip
but that failed. I tried the menu
"Tools" -> "Settings" for the "Configuration" dialog, the "Accounts"
tab, which showed my account,
I clicked the "Settings" button, for the "Account Registration Wizard"
dialog, which showed my full <pstn-phone#>@sip.broadvoice.com (or
<pstn-phone#>@broadvoice.com when I used that server name) and the
obscured password (and "remember password" checked). I clicked the
"Advanced" tab. I clicked "Override server default options", and changed
the "Proxy" field, but all served in DNS round-robin as
sip.broadvoice.com . So I set the Proxy field to each of several
different proxy . It failed the same way as before, with the same
dialog. I tried to go to the main S-C window, its "Dial" tab, and dial a
phone#. It failed with "Could not access…".

       I don't see how to configure S-C to use my SIP account, and I don't see
how to get more diagnostic info. Please advise.

Thanks & Regards
V.Sowmya

      Download prohibited? No problem. CHAT from any browser, without download. Go to http://in.webmessenger.yahoo.com/


#2

Hi,

I don't see how to configure S-C to use my SIP account, and I don't
see
how to get more diagnostic info. Please advise.

First, make sure you use the latest SVN version. Does the same dialog
as attached show up?

Unfortunately I can't test this SIP provider as it doesn't seem
possible to sign up for a free account. The proper settings, according
to Broadvoice support should be:

username: 0123456789@sip.broadvoice.com
proxy: proxy.[preferred_location].broadvoice.com or
proxy-[preferred_location].broadvoice.com (try both, as far as I know
SIP Communicator has support for DNS SRV lookup)

If this still doesn't work (given your message, you seem to have
already tried the aforementioned settings), get debug info. Launch
'ant run' from the command line and after the connection failed, look
for a " Received an error while trying to register. Server returned
error: bla" line and post the 'bla' error text here.

Cheers,

···

On Sat, Aug 30, 2008 at 7:48 AM, sowmya vallam <vallam_sowmya@yahoo.co.in> wrote:

--
Sébastien Mazy


#3

Sébastien,

as far as I know
SIP Communicator has support for DNS SRV lookup)

That's correct, SIP Communicator supports SRV lookups for SIP registration, although it doesn't have support for SRV lookups for placing SIP calls yet. I've submitted a patch for that but it hasn't been accepted yet.

Alan


#4

Alan C Kelly написа:

I've submitted a patch for that but it hasn't been accepted yet.

It will be really soon, though. Appologies for the delay.

Cheers
Emil

···

Alan

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

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

It will be really soon, though. Appologies for the delay.

No problem Emil... I'm not in a hurry. :slight_smile:

I've been testing the code some more and I actually just found another bug in it. I left out an SDP invite. I will send you an update in a few minutes after I do some testing.

I also created a local copy of Sun's sun.net.java.IPAddressUtil class, which I had previously only imported. I'm not sure what the "proper" way to handle that class is. It's GPL open source, but it is a "proprietary" API that's subject to change so would it be better to maintain our own copy?

Alan

···

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


#6

Emil,

Attached is a new patch file which includes the following changes:

impl.OperationSetBasicTelephonySipImpl
Added an accidentally omitted SDP invite call to my previous SRV lookup code

util.NetworkUtils
Addition of isIPv4Address(), isIPv6Address(), and isValidIPAddress() methods (I think I sent a previous patch for this but I'm not sure.)

util.IPAddressUtil
Local copy of sun.net.util.IPAddressUtil (not sure if this belongs here or what to do with it).

It should be compatible with the current revision (4381).

Alan

srv-lookup-for-sip-calls5-with-network-utils.patch (24 KB)

···

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

From: Emil Ivov <emcho@sip-communicator.org>

Date: Tuesday, September 2, 2008 11:20 am
Subject: Re: [sip-comm-dev] SIP Details

Alan C Kelly написа:
> I've submitted a patch for that but it hasn't been accepted yet.

It will be really soon, though. Appologies for the delay.

Cheers
Emil

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

Hey Alan,

I have started integrating your patch. I have commtted the util parts
with minor modifications (mostly concerning unformatted code) so they
are already in the repository. Thanks! (Acked)

Concerning OperationSetBasicTelephony though (other than the formatting
:wink: ), I have committed the part that helps avoid the name resolution in
create call (acked again, thanks).

I am afraid however that the intendedDestination and
destinationInetAddress that you are doing the SRV queries for, have no
impact on message routing. They are only used as a hack to pick a
provider/socket for your request to leave through. Resolving them is
therefore somewhat unnecessary.

There was a post from Ranga (the author and current lead of JAIN SIP)
some time ago, advising that we should have a look on the sipxbridge
projet on sipfoundry.org (hist latest work) for examples on how to do
SRV resolving with jain-sip.

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

You might want to check that out.

A few more notes.

I am thinking that it would probably be better if we could make SRV
resolution look as much as possible as simple A/AAAA address resolving,
and push all query specific mumbo jumbo into NetworkUtils.

In other words code that would currently look like:

lookupStr = "_sips._tcp." + destinationURI;

InetSocketAddress hosts[] = NetworkUtils.getSRVRecords(lookupStr);

if(hosts != null && hosts.length > 0)
{
    .. do something with hosts[0] here.
}

Instead we could add a new method in NetworkUtils that could look
something like NetworkUtils.getSrvRecord(String service, String proto)
Cheers
Emil

Alan C Kelly написа:

···

Emil,

Attached is a new patch file which includes the following changes:

impl.OperationSetBasicTelephonySipImpl
Added an accidentally omitted SDP invite call to my previous SRV lookup code

util.NetworkUtils
Addition of isIPv4Address(), isIPv6Address(), and isValidIPAddress() methods (I think I sent a previous patch for this but I'm not sure.)

util.IPAddressUtil
Local copy of sun.net.util.IPAddressUtil (not sure if this belongs here or what to do with it).

It should be compatible with the current revision (4381).

Alan

----- Original Message -----
From: Emil Ivov <emcho@sip-communicator.org>
Date: Tuesday, September 2, 2008 11:20 am
Subject: Re: [sip-comm-dev] SIP Details

Alan C Kelly написа:

I've submitted a patch for that but it hasn't been accepted yet.

It will be really soon, though. Appologies for the delay.

Cheers
Emil

Alan

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

-------

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

----

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


#8

Hi Emil,

I have started integrating your patch. I have commtted the util parts with

minor

modifications (mostly concerning unformatted code) so they are already in

the

repository. Thanks! (Acked)

Sorry about the formatting, it appears that when I save a patch from
NetBeans, it has been wreaking havok on some of my formatting (mostly
indents) for some reason. I'll try to be more careful in the future.

Concerning OperationSetBasicTelephony though (other than the formatting
:wink: ), I have committed the part that helps avoid the name resolution in

create

call (acked again, thanks).

I'm not sure which part that was at this point :slight_smile: but thanks!

I am afraid however that the intendedDestination and

destinationInetAddress

that you are doing the SRV queries for, have no impact on message routing.
They are only used as a hack to pick a provider/socket for your request to
leave through. Resolving them is therefore somewhat unnecessary.

I'm not sure I follow. When I made these changes, it enabled me to make
calls on our network, whereas previously it was unable to resolve the SIP
addresses and place a call.

There was a post from Ranga (the author and current lead of JAIN SIP) some
time ago, advising that we should have a look on the sipxbridge
projet on sipfoundry.org (hist latest work) for examples on how to do
SRV resolving with jain-sip.

Ok I will have a look at that.

I am thinking that it would probably be better if we could make SRV

resolution

look as much as possible as simple A/AAAA address resolving, and push
all query specific mumbo jumbo into NetworkUtils.

Good thought. I was considering doing that, but I didn't want to get too
many steps ahead of what had been reviewed and approved. There is also a
similar piece of SRV lookup code in the SIP registration classes, we could
probably integrate that as well, and cut down on redundancy.

I'll explore this some more tomorrow.

Thanks,

Alan

···

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


#9

Argh, this one left my box before it was ready and hence not everything
I say I did here has actually been done. (should disable ctrl+enter one
of these days)

Never mind, continuing here:

I am also seeing that we use InetAddress.getByName() in a few other
locations throughout the sip package. registrarAddress.getHostName(), so
maybe we should move the following in a new getInetAddress() method in
NetworkUtils:

···

=======================================================
// Detect probable IPv4 and IPv6 addresses,
// and avoid attempting a DNS lookup on them.
if (NetworkUtils.isValidIPAddress(host))
{
    byte[] addr = null;
    // attempt parse as IPv4 address
    addr = IPAddressUtil.textToNumericFormatV4(host);
    // if not IPv4, parse as IPv6 address
    if (addr == null)
    {
        addr = IPAddressUtil.textToNumericFormatV6(host);
    }

    //obtain the address without a DNS query.
    address
        = InetAddress.getByAddress(host, addr);

}
else
{
    address = InetAddress.getByName(host);
}

return address;

Since this is very much the same problem, we also need to think of a way
to handle the problem Thomas describes here:

and provide an alternative getHostName() method.

What do you think?

Cheers
Emil

Emil Ivov написа:

Hey Alan,

I have started integrating your patch. I have commtted the util parts
with minor modifications (mostly concerning unformatted code) so they
are already in the repository. Thanks! (Acked)

Concerning OperationSetBasicTelephony though (other than the formatting
:wink: ), I have committed the part that helps avoid the name resolution in
create call (acked again, thanks).

I am afraid however that the intendedDestination and
destinationInetAddress that you are doing the SRV queries for, have no
impact on message routing. They are only used as a hack to pick a
provider/socket for your request to leave through. Resolving them is
therefore somewhat unnecessary.

There was a post from Ranga (the author and current lead of JAIN SIP)
some time ago, advising that we should have a look on the sipxbridge
projet on sipfoundry.org (hist latest work) for examples on how to do
SRV resolving with jain-sip.

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

You might want to check that out.

A few more notes.

I am thinking that it would probably be better if we could make SRV
resolution look as much as possible as simple A/AAAA address resolving,
and push all query specific mumbo jumbo into NetworkUtils.

In other words code that would currently look like:

lookupStr = "_sips._tcp." + destinationURI;

InetSocketAddress hosts[] = NetworkUtils.getSRVRecords(lookupStr);

if(hosts != null && hosts.length > 0)
{
    .. do something with hosts[0] here.
}

Instead we could add a new method in NetworkUtils that could look
something like NetworkUtils.getSrvRecord(String service, String proto)
Cheers
Emil

Alan C Kelly написа:

Emil,

Attached is a new patch file which includes the following changes:

impl.OperationSetBasicTelephonySipImpl
Added an accidentally omitted SDP invite call to my previous SRV lookup code

util.NetworkUtils
Addition of isIPv4Address(), isIPv6Address(), and isValidIPAddress() methods (I think I sent a previous patch for this but I'm not sure.)

util.IPAddressUtil
Local copy of sun.net.util.IPAddressUtil (not sure if this belongs here or what to do with it).

It should be compatible with the current revision (4381).

Alan

----- Original Message -----
From: Emil Ivov <emcho@sip-communicator.org>
Date: Tuesday, September 2, 2008 11:20 am
Subject: Re: [sip-comm-dev] SIP Details

Alan C Kelly написа:

I've submitted a patch for that but it hasn't been accepted yet.

It will be really soon, though. Appologies for the delay.

Cheers
Emil

Alan

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

-------

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

----

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


#10

Hey Alan,

Alan Kelly написа:

I'm not sure which part that was at this point :slight_smile: but thanks!

You are most welcome and thank you too!

Basically this is the part that replaces use of InetAddress.getByName()
with InetAddress.getByAddress().

I am afraid however that the intendedDestination and

destinationInetAddress

that you are doing the SRV queries for, have no impact on message routing.
They are only used as a hack to pick a provider/socket for your request to
leave through. Resolving them is therefore somewhat unnecessary.

I'm not sure I follow. When I made these changes, it enabled me to make
calls on our network, whereas previously it was unable to resolve the SIP
addresses and place a call.

Aha, I see. Then I guess you are probably connecting to a registrar that
only has an SRV record, that is, it doesn't have any A records you
could use.

This is indeed a bug that needs fixing, so your change was definitely
not unnecessary. Let's put it back in after you update your version to
use the new, high level getSRVRecord() method that we are discussing below.

Note however, that this still does not mean that we are doing SRV based
routing.

There was a post from Ranga (the author and current lead of JAIN SIP) some
time ago, advising that we should have a look on the sipxbridge
projet on sipfoundry.org (hist latest work) for examples on how to do
SRV resolving with jain-sip.

Ok I will have a look at that.

I think it would probably have something to do with changing the default
router for jain-sip. You'd have to have a look though.

Cheers
Emil

···

I am thinking that it would probably be better if we could make SRV

resolution

look as much as possible as simple A/AAAA address resolving, and push
all query specific mumbo jumbo into NetworkUtils.

Good thought. I was considering doing that, but I didn't want to get too
many steps ahead of what had been reviewed and approved. There is also a
similar piece of SRV lookup code in the SIP registration classes, we could
probably integrate that as well, and cut down on redundancy.

I'll explore this some more tomorrow.

Thanks,

Alan

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


#11

Hi Emil,

Ok, cool, I'll take a look at that, probably early next week. As I mentioned
in a previous email, I've been reworking the methods to make the changes you
suggested to NetworkUtils. Hopefully we didn't duplicate effort too much.
I'll fit your work into my local code and see if there's anything more
changes to propose.

As for the SRV resolving JAIN SIP router, unfortunately that's probably not
a project I have time to tackle right now. I'll have to look at it some
more.

Thanks for tackling this, SC will hopefully now be able to be used as the
softclient for a communications system we are working on.

Alan

···

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

From: Emil Ivov [mailto:emcho@sip-communicator.org]

Sent: Saturday, September 13, 2008 3:41 PM
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] SIP Details

Hey Alan,

I've just applied the remaining part of your patch. I made some changes
according to the comments I made in my previous mail but they mostly
consisted in moving methods around. I've tried to reduce the amount of
address handling code we use in OperationSetBasicTelephonySipImpl with two
convenience methods in the sip ProtocolProvider and the NetworkUtils
classes.

Could you please have a look and let me know if it makes sense to you?

If everything is OK, you won't need to resubmit your last patch and can only
concentrate on implementing the SRV resolving JAIN SIP router if you are
still interested. (You might want to use the new NetworkUtils utility
methods in there too).

Cheers and thanks for your contrib!
Emil

Alan Kelly написа:

Hi Emil,

I have started integrating your patch. I have commtted the util parts
with

minor

modifications (mostly concerning unformatted code) so they are
already in

the

repository. Thanks! (Acked)

Sorry about the formatting, it appears that when I save a patch from
NetBeans, it has been wreaking havok on some of my formatting (mostly
indents) for some reason. I'll try to be more careful in the future.

Concerning OperationSetBasicTelephony though (other than the
formatting
:wink: ), I have committed the part that helps avoid the name resolution
in

create

call (acked again, thanks).

I'm not sure which part that was at this point :slight_smile: but thanks!

I am afraid however that the intendedDestination and

destinationInetAddress

that you are doing the SRV queries for, have no impact on message

routing.

They are only used as a hack to pick a provider/socket for your
request to leave through. Resolving them is therefore somewhat

unnecessary.

I'm not sure I follow. When I made these changes, it enabled me to
make calls on our network, whereas previously it was unable to resolve
the SIP addresses and place a call.

There was a post from Ranga (the author and current lead of JAIN SIP)
some time ago, advising that we should have a look on the sipxbridge
projet on sipfoundry.org (hist latest work) for examples on how to do
SRV resolving with jain-sip.

Ok I will have a look at that.

I am thinking that it would probably be better if we could make SRV

resolution

look as much as possible as simple A/AAAA address resolving, and push
all query specific mumbo jumbo into NetworkUtils.

Good thought. I was considering doing that, but I didn't want to get
too many steps ahead of what had been reviewed and approved. There is
also a similar piece of SRV lookup code in the SIP registration
classes, we could probably integrate that as well, and cut down on

redundancy.

I'll explore this some more tomorrow.

Thanks,

Alan

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

It all looks good! I just ran some test calls and the DNS is working flawlessly now. Thank you for making this happen. :smiley:

I found several more places where we should be using the new NetworkUtils methods, and I am attaching a patch with these minor changes.

Alan

use-new-NetworkUtils-methods-for-all-SRV-lookups.patch (5.09 KB)

···

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

From: Emil Ivov <emcho@sip-communicator.org>

Date: Saturday, September 13, 2008 3:41 pm
Subject: Re: [sip-comm-dev] SIP Details

Hey Alan,

I've just applied the remaining part of your patch. I made some
changesaccording to the comments I made in my previous mail but
they mostly
consisted in moving methods around. I've tried to reduce the
amount of
address handling code we use in OperationSetBasicTelephonySipImpl with
two convenience methods in the sip ProtocolProvider and the
NetworkUtilsclasses.

Could you please have a look and let me know if it makes sense to you?

If everything is OK, you won't need to resubmit your last patch
and can
only concentrate on implementing the SRV resolving JAIN SIP router if
you are still interested. (You might want to use the new NetworkUtils
utility methods in there too).

Cheers and thanks for your contrib!
Emil

Alan Kelly написа:
> Hi Emil,
>
>> I have started integrating your patch. I have commtted the util
parts with
> minor
>> modifications (mostly concerning unformatted code) so they are
already in
> the
>> repository. Thanks! (Acked)
>
> Sorry about the formatting, it appears that when I save a patch from
> NetBeans, it has been wreaking havok on some of my formatting
(mostly> indents) for some reason. I'll try to be more careful in
the future.
>
>
>> Concerning OperationSetBasicTelephony though (other than the
>> :wink: ), I have committed the part that helps avoid the
name resolution in
> create
>> call (acked again, thanks).
>
> I'm not sure which part that was at this point :slight_smile: but thanks!
>
>
>> I am afraid however that the intendedDestination and
> destinationInetAddress
>> that you are doing the SRV queries for, have no impact on
message routing.
>> They are only used as a hack to pick a provider/socket for your
request to
>> leave through. Resolving them is therefore somewhat unnecessary.
>
> I'm not sure I follow. When I made these changes, it enabled me
to make
> calls on our network, whereas previously it was unable to
resolve the SIP
> addresses and place a call.
>
>
>> There was a post from Ranga (the author and current lead of
JAIN SIP) some
>> time ago, advising that we should have a look on the sipxbridge
>> projet on sipfoundry.org (hist latest work) for examples on
how to do
>> SRV resolving with jain-sip.
>
> Ok I will have a look at that.
>
>
>> I am thinking that it would probably be better if we could make SRV
> resolution
>> look as much as possible as simple A/AAAA address resolving,
and push
>> all query specific mumbo jumbo into NetworkUtils.
>
> Good thought. I was considering doing that, but I didn't want to
get too
> many steps ahead of what had been reviewed and approved. There
is also a
> similar piece of SRV lookup code in the SIP registration
classes, we could
> probably integrate that as well, and cut down on redundancy.
>
> I'll explore this some more tomorrow.
>
> Thanks,
>
> Alan
>
>
> -----------------------------------------------------------------
----
> 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

That makes sense. I think I already have parts of that in NetworkUtils. I am
away from the computer with my code today, so it's hard for me to look up
what we're working with. I'll be able to look at this tomorrow.

···

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

From: Emil Ivov [mailto:emcho@sip-communicator.org]

Sent: Monday, September 08, 2008 8:45 AM
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] SIP Details

Argh, this one left my box before it was ready and hence not everything I
say I did here has actually been done. (should disable ctrl+enter one of
these days)

Never mind, continuing here:

I am also seeing that we use InetAddress.getByName() in a few other
locations throughout the sip package. registrarAddress.getHostName(), so
maybe we should move the following in a new getInetAddress() method in
NetworkUtils:

// Detect probable IPv4 and IPv6 addresses, // and avoid attempting a DNS
lookup on them.
if (NetworkUtils.isValidIPAddress(host))
{
    byte[] addr = null;
    // attempt parse as IPv4 address
    addr = IPAddressUtil.textToNumericFormatV4(host);
    // if not IPv4, parse as IPv6 address
    if (addr == null)
    {
        addr = IPAddressUtil.textToNumericFormatV6(host);
    }

    //obtain the address without a DNS query.
    address
        = InetAddress.getByAddress(host, addr);

}
else
{
    address = InetAddress.getByName(host); }

return address;

Since this is very much the same problem, we also need to think of a way to
handle the problem Thomas describes here:

and provide an alternative getHostName() method.

What do you think?

Cheers
Emil

Emil Ivov написа:

Hey Alan,

I have started integrating your patch. I have commtted the util parts
with minor modifications (mostly concerning unformatted code) so they
are already in the repository. Thanks! (Acked)

Concerning OperationSetBasicTelephony though (other than the
formatting
:wink: ), I have committed the part that helps avoid the name resolution
in create call (acked again, thanks).

I am afraid however that the intendedDestination and
destinationInetAddress that you are doing the SRV queries for, have no
impact on message routing. They are only used as a hack to pick a
provider/socket for your request to leave through. Resolving them is
therefore somewhat unnecessary.

There was a post from Ranga (the author and current lead of JAIN SIP)
some time ago, advising that we should have a look on the sipxbridge
projet on sipfoundry.org (hist latest work) for examples on how to do
SRV resolving with jain-sip.

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

You might want to check that out.

A few more notes.

I am thinking that it would probably be better if we could make SRV
resolution look as much as possible as simple A/AAAA address
resolving, and push all query specific mumbo jumbo into NetworkUtils.

In other words code that would currently look like:

lookupStr = "_sips._tcp." + destinationURI;

InetSocketAddress hosts[] = NetworkUtils.getSRVRecords(lookupStr);

if(hosts != null && hosts.length > 0)
{
    .. do something with hosts[0] here.
}

Instead we could add a new method in NetworkUtils that could look
something like NetworkUtils.getSrvRecord(String service, String proto)
Cheers Emil

Alan C Kelly написа:

Emil,

Attached is a new patch file which includes the following changes:

impl.OperationSetBasicTelephonySipImpl
Added an accidentally omitted SDP invite call to my previous SRV
lookup code

util.NetworkUtils
Addition of isIPv4Address(), isIPv6Address(), and isValidIPAddress()
methods (I think I sent a previous patch for this but I'm not sure.)

util.IPAddressUtil
Local copy of sun.net.util.IPAddressUtil (not sure if this belongs here

or what to do with it).

It should be compatible with the current revision (4381).

Alan

----- Original Message -----
From: Emil Ivov <emcho@sip-communicator.org>
Date: Tuesday, September 2, 2008 11:20 am
Subject: Re: [sip-comm-dev] SIP Details

Alan C Kelly написа:

I've submitted a patch for that but it hasn't been accepted yet.

It will be really soon, though. Appologies for the delay.

Cheers
Emil

Alan

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

-------

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

----

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


#14

Hi,

···

On Mon, Sep 8, 2008 at 6:53 PM, Emil Ivov <emcho@sip-communicator.org> wrote:

There was a post from Ranga (the author and current lead of JAIN SIP) some
time ago, advising that we should have a look on the sipxbridge
projet on sipfoundry.org (hist latest work) for examples on how to do
SRV resolving with jain-sip.

Ok I will have a look at that.

I think it would probably have something to do with changing the default
router for jain-sip. You'd have to have a look though.

Just note that the "single SIP stack" patch also changes the default
router (but in a simplistic way so this shouldn't be difficult to
merge with the SRV incoming update).

--
Sébastien Mazy


#15

Hey again,

Emil Ivov написа:

There was a post from Ranga (the author and current lead of JAIN SIP) some
time ago, advising that we should have a look on the sipxbridge
projet on sipfoundry.org (hist latest work) for examples on how to do
SRV resolving with jain-sip.

Ok I will have a look at that.

I think it would probably have something to do with changing the default
router for jain-sip. You'd have to have a look though.

Just had a quick chat with Ranga. And he confirmed that he's doing this
with a custom router. He also mentioned that if we are going to do this
then we'd better cache results from SRV queries and have a thread update
them periodically.

The point of caching is quite obvious so there's no need to explain it.
The threaded updates are also important. SRV records are often used as a
failover or load distribution mechanism so it is important that we keep
our cache up to date.

Most of this is already implemented in sipxbridge so you should
definitely have a look at it.

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


#16

Hi again Emil,

Incidentally, I really like your code! It takes many details into
account. Looking at the account properties to find the default
transport, for example, is a very good idea!

Thank you! It took me a while to figure out all the changes you made but I think I get it now. You simplified it a lot. There's still some more places that redundancy can be eliminated, I'll send a patch shortly.

> As for the SRV resolving JAIN SIP router, unfortunately that's
probably not
> a project I have time to tackle right now.

Ah, that's a pity! Well, don't hesitate to ping us in case you change
your mind. My TODO list is quite long so it'll probably take a while
before I get down to it.

I'll let you know if/when I have time to do it.

Alan

···

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


#17

Excellent! All very nice fixes!

Applied, acked, and almost committed ... :slight_smile:

I saw that Romain intends to commit Emmanuel's patch tonight. That's a
considerable chunk of code so I'd prefer to handle any potential
conflicts in my own sandbox.

Thank you for your contribution!
Cheers
Emil

Alan C Kelly написа:

···

Hi Emil,

It all looks good! I just ran some test calls and the DNS is working flawlessly now. Thank you for making this happen. :smiley:

I found several more places where we should be using the new NetworkUtils methods, and I am attaching a patch with these minor changes.

Alan

----- Original Message -----
From: Emil Ivov <emcho@sip-communicator.org>
Date: Saturday, September 13, 2008 3:41 pm
Subject: Re: [sip-comm-dev] SIP Details

Hey Alan,

I've just applied the remaining part of your patch. I made some
changesaccording to the comments I made in my previous mail but
they mostly
consisted in moving methods around. I've tried to reduce the
amount of
address handling code we use in OperationSetBasicTelephonySipImpl with
two convenience methods in the sip ProtocolProvider and the
NetworkUtilsclasses.

Could you please have a look and let me know if it makes sense to you?

If everything is OK, you won't need to resubmit your last patch
and can
only concentrate on implementing the SRV resolving JAIN SIP router if
you are still interested. (You might want to use the new NetworkUtils
utility methods in there too).

Cheers and thanks for your contrib!
Emil

Alan Kelly написа:

Hi Emil,

I have started integrating your patch. I have commtted the util

parts with

minor

modifications (mostly concerning unformatted code) so they are

already in

the

repository. Thanks! (Acked)

Sorry about the formatting, it appears that when I save a patch from
NetBeans, it has been wreaking havok on some of my formatting

(mostly> indents) for some reason. I'll try to be more careful in
the future.

Concerning OperationSetBasicTelephony though (other than the

>> :wink: ), I have committed the part that helps avoid the
name resolution in

create

call (acked again, thanks).

I'm not sure which part that was at this point :slight_smile: but thanks!

I am afraid however that the intendedDestination and

destinationInetAddress

that you are doing the SRV queries for, have no impact on

message routing.

They are only used as a hack to pick a provider/socket for your

request to

leave through. Resolving them is therefore somewhat unnecessary.

I'm not sure I follow. When I made these changes, it enabled me

to make

calls on our network, whereas previously it was unable to

resolve the SIP

addresses and place a call.

There was a post from Ranga (the author and current lead of

JAIN SIP) some

time ago, advising that we should have a look on the sipxbridge
projet on sipfoundry.org (hist latest work) for examples on

how to do

SRV resolving with jain-sip.

Ok I will have a look at that.

I am thinking that it would probably be better if we could make SRV

resolution

look as much as possible as simple A/AAAA address resolving,

and push

all query specific mumbo jumbo into NetworkUtils.

Good thought. I was considering doing that, but I didn't want to

get too

many steps ahead of what had been reviewed and approved. There

is also a

similar piece of SRV lookup code in the SIP registration

classes, we could

probably integrate that as well, and cut down on redundancy.

I'll explore this some more tomorrow.

Thanks,

Alan

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

----

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


#18

Hey Alan,

Lubo just noticed the following line in ProtocolProviderServiceJabberImpl:

    serverAddress = NetworkUtils
        .getSRVRecord("xmpp-client", "tcp", serviceName)
            .getHostName();

This was causing jabber to fail in situations where a server only has an
A record and no SRVs. In such cases NetworkUtils would return null. We
fixed that particular case but could you please have a look around and
make sure that things would work even without any SRVs.

Cheers
Emil

Emil Ivov написа:

···

Excellent! All very nice fixes!

Applied, acked, and almost committed ... :slight_smile:

I saw that Romain intends to commit Emmanuel's patch tonight. That's a
considerable chunk of code so I'd prefer to handle any potential
conflicts in my own sandbox.

Thank you for your contribution!
Cheers
Emil

Alan C Kelly написа:

Hi Emil,

It all looks good! I just ran some test calls and the DNS is working flawlessly now. Thank you for making this happen. :smiley:

I found several more places where we should be using the new NetworkUtils methods, and I am attaching a patch with these minor changes.

Alan

----- Original Message -----
From: Emil Ivov <emcho@sip-communicator.org>
Date: Saturday, September 13, 2008 3:41 pm
Subject: Re: [sip-comm-dev] SIP Details

Hey Alan,

I've just applied the remaining part of your patch. I made some
changesaccording to the comments I made in my previous mail but
they mostly
consisted in moving methods around. I've tried to reduce the
amount of
address handling code we use in OperationSetBasicTelephonySipImpl with
two convenience methods in the sip ProtocolProvider and the
NetworkUtilsclasses.

Could you please have a look and let me know if it makes sense to you?

If everything is OK, you won't need to resubmit your last patch
and can
only concentrate on implementing the SRV resolving JAIN SIP router if
you are still interested. (You might want to use the new NetworkUtils
utility methods in there too).

Cheers and thanks for your contrib!
Emil

Alan Kelly написа:

Hi Emil,

I have started integrating your patch. I have commtted the util

parts with

minor

modifications (mostly concerning unformatted code) so they are

already in

the

repository. Thanks! (Acked)

Sorry about the formatting, it appears that when I save a patch from
NetBeans, it has been wreaking havok on some of my formatting

(mostly> indents) for some reason. I'll try to be more careful in
the future.

Concerning OperationSetBasicTelephony though (other than the

>> :wink: ), I have committed the part that helps avoid the
name resolution in

create

call (acked again, thanks).

I'm not sure which part that was at this point :slight_smile: but thanks!

I am afraid however that the intendedDestination and

destinationInetAddress

that you are doing the SRV queries for, have no impact on

message routing.

They are only used as a hack to pick a provider/socket for your

request to

leave through. Resolving them is therefore somewhat unnecessary.

I'm not sure I follow. When I made these changes, it enabled me

to make

calls on our network, whereas previously it was unable to

resolve the SIP

addresses and place a call.

There was a post from Ranga (the author and current lead of

JAIN SIP) some

time ago, advising that we should have a look on the sipxbridge
projet on sipfoundry.org (hist latest work) for examples on

how to do

SRV resolving with jain-sip.

Ok I will have a look at that.

I am thinking that it would probably be better if we could make SRV

resolution

look as much as possible as simple A/AAAA address resolving,

and push

all query specific mumbo jumbo into NetworkUtils.

Good thought. I was considering doing that, but I didn't want to

get too

many steps ahead of what had been reviewed and approved. There

is also a

similar piece of SRV lookup code in the SIP registration

classes, we could

probably integrate that as well, and cut down on redundancy.

I'll explore this some more tomorrow.

Thanks,

Alan

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

----

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


#19

Hey Alan,

I think I actually misled you when I wrote this, sorry. I don't think we
need to be using a router here. I believe the caching code should go in
the address resolver. We actually have complete support for SRVs but we
query the DNS every time we need to send a message. This is a bit too
often so we'd probably have to start caching at one point.

Thought I'd mention this in case you (or anyone else) has thought about
implementing it.

Cheers
Emil

Emil Ivov написа:

···

Hey again,

Emil Ivov написа:

There was a post from Ranga (the author and current lead of JAIN SIP) some
time ago, advising that we should have a look on the sipxbridge
projet on sipfoundry.org (hist latest work) for examples on how to do
SRV resolving with jain-sip.

Ok I will have a look at that.

I think it would probably have something to do with changing the default
router for jain-sip. You'd have to have a look though.

Just had a quick chat with Ranga. And he confirmed that he's doing this
with a custom router. He also mentioned that if we are going to do this
then we'd better cache results from SRV queries and have a thread update
them periodically.

The point of caching is quite obvious so there's no need to explain it.
The threaded updates are also important. SRV records are often used as a
failover or load distribution mechanism so it is important that we keep
our cache up to date.

Most of this is already implemented in sipxbridge so you should
definitely have a look at it.

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


#20

Hi Emil,

Yes, I think I originally had a provision for this, but apparently somewhere
that got dropped. I don't know if I deleted it by mistake or if it didn't
make it into what you actually committed or what. Now that I think about it,
this is possibly a flaw that exists every place we have this code. I've kind
of had some doubts in the back of my mind about whether this had been
handled properly but I never got around to doublechecking it. I'll look at
it at my earliest opportunity (probably late this week).

Alan

···

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

From: Emil Ivov [mailto:emil@sip-communicator.org] On Behalf Of Emil Ivov

Sent: Tuesday, September 23, 2008 8:44 AM
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] SIP Details

Hey Alan,

Lubo just noticed the following line in ProtocolProviderServiceJabberImpl:

    serverAddress = NetworkUtils
        .getSRVRecord("xmpp-client", "tcp", serviceName)
            .getHostName();

This was causing jabber to fail in situations where a server only has an A
record and no SRVs. In such cases NetworkUtils would return null. We fixed
that particular case but could you please have a look around and make sure
that things would work even without any SRVs.

Cheers
Emil

Emil Ivov написа:

Excellent! All very nice fixes!

Applied, acked, and almost committed ... :slight_smile:

I saw that Romain intends to commit Emmanuel's patch tonight. That's a
considerable chunk of code so I'd prefer to handle any potential
conflicts in my own sandbox.

Thank you for your contribution!
Cheers
Emil

Alan C Kelly написа:

Hi Emil,

It all looks good! I just ran some test calls and the DNS is working
flawlessly now. Thank you for making this happen. :smiley:

I found several more places where we should be using the new NetworkUtils

methods, and I am attaching a patch with these minor changes.

Alan

----- Original Message -----
From: Emil Ivov <emcho@sip-communicator.org>
Date: Saturday, September 13, 2008 3:41 pm
Subject: Re: [sip-comm-dev] SIP Details

Hey Alan,

I've just applied the remaining part of your patch. I made some
changesaccording to the comments I made in my previous mail but they
mostly consisted in moving methods around. I've tried to reduce the
amount of address handling code we use in
OperationSetBasicTelephonySipImpl with two convenience methods in
the sip ProtocolProvider and the NetworkUtilsclasses.

Could you please have a look and let me know if it makes sense to you?

If everything is OK, you won't need to resubmit your last patch and
can only concentrate on implementing the SRV resolving JAIN SIP
router if you are still interested. (You might want to use the new
NetworkUtils utility methods in there too).

Cheers and thanks for your contrib!
Emil

Alan Kelly написа:

Hi Emil,

I have started integrating your patch. I have commtted the util

parts with

minor

modifications (mostly concerning unformatted code) so they are

already in

the

repository. Thanks! (Acked)

Sorry about the formatting, it appears that when I save a patch
from NetBeans, it has been wreaking havok on some of my formatting

(mostly> indents) for some reason. I'll try to be more careful in
the future.

Concerning OperationSetBasicTelephony though (other than the

>> :wink: ), I have committed the part that helps avoid the
name resolution in

create

call (acked again, thanks).

I'm not sure which part that was at this point :slight_smile: but thanks!

I am afraid however that the intendedDestination and

destinationInetAddress

that you are doing the SRV queries for, have no impact on

message routing.

They are only used as a hack to pick a provider/socket for your

request to

leave through. Resolving them is therefore somewhat unnecessary.

I'm not sure I follow. When I made these changes, it enabled me

to make

calls on our network, whereas previously it was unable to

resolve the SIP

addresses and place a call.

There was a post from Ranga (the author and current lead of

JAIN SIP) some

time ago, advising that we should have a look on the sipxbridge
projet on sipfoundry.org (hist latest work) for examples on

how to do

SRV resolving with jain-sip.

Ok I will have a look at that.

I am thinking that it would probably be better if we could make
SRV

resolution

look as much as possible as simple A/AAAA address resolving,

and push

all query specific mumbo jumbo into NetworkUtils.

Good thought. I was considering doing that, but I didn't want to

get too

many steps ahead of what had been reviewed and approved. There

is also a

similar piece of SRV lookup code in the SIP registration

classes, we could

probably integrate that as well, and cut down on redundancy.

I'll explore this some more tomorrow.

Thanks,

Alan

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

----

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