Patch to change the Authentication process with different Realm and use the Real IPAddress instead of 127.0.0.1

[Antonio Anderson M. de Souza]

Dear Pascal,

I implemented a patch [1] (the patch is located in the google groups) to Sipdroid 0.9.4, to change the Authentication process with different Realm and use the Real IPAddress instead of 127.0.0.1.

In the summary this patch create a new configuration item to set the Realm value, because there are a lot of SIP Services that use different names for the SIP Proxy, and the Realm for the authentication process, if the Realm is not set the Server is used for the both items as the old behavior, and change all of the "127.0.0.1" IpAddress that was hardcoded for the Real IPAddress.

I make a lot of tests with this patch, including change the Network connection between WiFi, 3g, and Edge, on the Fly, and the implementation worked well in all of these scenarios.

I would like to ask you to take a look in the implementation and give me the permission to commit (anyway before the commit  I'll need to make some comments to explain my implementation, and delete some commented code, but before spend time to make this i would like to get your approval about the changes), or guide me to improve something, bellow follows the changes descriptions:

UI > Preference Screen

• Add a specific field to configure the Realm, there are a lot of SIP Services that use different names for the SIP Proxy, and the Realm for the authentication process, so i created a new configuration item to set the Realm, if the Realm is not set the Server is used for the both items as the old behavior.

Class org/zoolu/net/IpAddress.java

• Add a method to get the Real IPAddress, this method iterate the interfaces and the addresses to get the real IPAddress.

Class org/zoolu/sip/provider/SipProvider.java

• Change all of the 127.0.0.1 strings for the IpAddress.getLocalIpAddress(); to get the reall IPAddress of the phone.

Class org/sipdroid/sipua/SipdroidEngine.java

• Change all of the 127.0.0.1 strings for the IpAddress.getLocalIpAddress(); to get the reall IPAddress of the phone.

Class org/sipdroid/sipua/UserAgent.java

• In method call() before performe the Call recreate the SDP calling a new method called createSessiondescriptor(), this change was made because when the phone changes the IPAddress (roaming from a network to another) it's necessary to update the IPAddress so i think it's better to create a new SDP for each call.
  

Class org/sipdroid/sipua/ui/Settings.java

• Implementation needed to handle the new realm configuration item

Class org/sipdroid/sipua/RegisterAgent.java

• Remove the attributes username, realm, password, and contact
• Add an attribute to store a reference of the UserAgentProfile that has all of the other attributtes

[1] - http://sipdroid-developers.googlegroups.com/web/SipDroid-0.9.5.patch

Best regards,

--
Antonio Anderson M. Souza
Voice Technology
Rua: Libero Badaró, 293
Cj 30D - 30o. andar
CEP: 01009-907
ant...@voicetechnology.com.br
anton...@gmail.com
phone:  +55 11 3588-0188
mobile: +55 11 7525-7543
http://www.voicetechnology.com.br
http://antonioams.blogspot.com

[Pascal Merle]

Hi Antonio,

as this is a larger modification please upload it as a new branch and
start a code review. It's much easier to work with the code in SVN
than with a patch file. When the modifications are finished we can
merge it into trunk.

Concerning the mods itself:

1) I would not obtain the local IP address on every use of via_addr.
We get the intents in Receiver.java for any changes of network
connection. The value should then be updated in the via_addr variables
and SDP.

2) I would like to keep setup as simple as possible. As I have seen in
the issue reports users often don't know which realm to enter. Other
SIP clients can also determine them automatically. Why don't we just
use the realm received in the 401/407 responses? Then you could leave
all the Settings modules as they are (and please don't touch the use
of "dns" preference item).

Thanks for working on this part. I am already on a big new feature...
Pascal

[Antonio Anderson M. de Souza]

Pascal,

Sorry for the late reply, i will start to make the changes as you suggested tomorrow.

What's the big new feature that you are working? What do you think to create a page in the wiki describing the SIPDroid's roadmap?

Best regards,

Antonio

--
Antonio Anderson M. Souza
Voice Technology
Rua: Libero Badaró, 293
Cj 30D - 30o. andar
CEP: 01009-907
ant...@voicetechnology.com.br
anton...@gmail.com
phone:  +55 11 3588-0188
mobile: +55 11 7525-7543
http://www.voicetechnology.com.br
http://antonioams.blogspot.com

[Pascal Merle]

The big new change was the addition of video capability (see preject
home). Now I am taking a few days off.

[hendri...@googlemail.com]

Antonio,

your patch still works great, however, sipdroid has been updated quite
a few times since then.
Is there any cause you haven't updated the svn code yet?
I think many people would appreciate your addition since it allows
sipdroid to connect to a wider range of sip providers.

On Jun 2, 11:12 pm, "Antonio Anderson M. de Souza"

<antonio...@gmail.com> wrote:
> Pascal,
>
> Sorry for the late reply, i will start to make the changes as you suggested
> tomorrow.
>
> What's the big new feature that you are working? What do you think to create
> a page in the wiki describing the SIPDroid's roadmap?
>
> Best regards,
>
> Antonio
>

> > anto...@voicetechnology.com.br
> > antonio...@gmail.com

> > phone:  +55 11 3588-0188
> > mobile: +55 11 7525-7543
> >http://www.voicetechnology.com.br
> >http://antonioams.blogspot.com
>
> --
> Antonio Anderson M. Souza
> Voice Technology
> Rua: Libero Badaró, 293
> Cj 30D - 30o. andar
> CEP: 01009-907

> anto...@voicetechnology.com.br
> antonio...@gmail.com

[Antonio Anderson M. de Souza]

Hendrik,

Sorry for the delay, but i had some urgent projects in my company and didn't have time to change the Pascal recomendations, e sync with the changes.

Probably next week I'll have time to make this.

Best regards,

Antonio Anderson M. Souza
Voice Technology
Rua: Libero Badaró, 293
Cj 30D - 30o. andar
CEP: 01009-907

ant...@voicetechnology.com.br
anton...@gmail.com

phone:  +55 11 3588-0188
mobile: +55 11 7525-7543
http://www.voicetechnology.com.br
http://antonioams.blogspot.com

2009/6/25 hendri...@googlemail.com <hendri...@googlemail.com>

[Poteck]

Hi antonio,
We try to patch manually (line by line) the version 0.9.8 from svn
with no success. The code change a bit from 0.9.5 so propably there
are some bugs....
The sipdroid register without problems in our asterisk but it´s
always
unreacheable to receive or send a call. Propably we mismatch something
in the
code.

The ip adress issue it´s solve but it´s unreacheable don´t know why.
i could post it here if anyone want to take a look....

http://sipdroid-developers.googlegroups.com/web/sipdroide.apk?gda=cQydDz8AAACkjSGwcS3pR8Wsqw2SAXiciSrimpcBw1jTgf8aEH40FHXrSunBfQKOjoPx2n-xUiiccyFKn-rNKC-d1pM_IdV0&gsc=Kg-19SEAAAAhD0OuyfFtXr_6WNqg9RFd2KMi0U5tm2f-vsxcK-Z-iEzfKN-m9S9niuHrq-IEXAE


On Jun 26, 3:21 pm, "Antonio Anderson M. de Souza"

<antonio...@gmail.com> wrote:
> Hendrik,
>
> Sorry for the delay, but i had some urgent projects in my company and didn't
> have time to change the Pascal recomendations, e sync with the changes.
>
> Probably next week I'll have time to make this.
>
> Best regards,
>
> Antonio Anderson M. Souza
> Voice Technology
> Rua: Libero Badaró, 293
> Cj 30D - 30o. andar
> CEP: 01009-907

> anto...@voicetechnology.com.br
> antonio...@gmail.com
> phone:  +55 11 3588-0188
> mobile: +55 11 7525-7543http://www.voicetechnology.com.brhttp://antonioams.blogspot.com
>

> 2009/6/25 hendrikgro...@googlemail.com <hendrikgro...@googlemail.com>

[Teague Gray]

Hi,
I applied the patch as well, it registers fine but the call doesn't
connect. Does it work for you? I previously before applying the patch
kept getting 407 error. Is there are a solution for this?

On Jul 7, 7:45 pm, Poteck <ign...@gmail.com> wrote:
> Hi antonio,
> We try to patch manually (line by line) the version 0.9.8 from svn
> with no success. The code change a bit from 0.9.5 so propably there
> are some bugs....
> The sipdroid register without problems in our asterisk but it´s
> always
> unreacheable to receive or send a call. Propably we mismatch something
> in the
> code.
>
> The ip adress issue it´s solve but it´s unreacheable don´t know why.
> i could post it here if anyone want to take a look....
>

> http://sipdroid-developers.googlegroups.com/web/sipdroide.apk?gda=cQy...

[Antonio Anderson M. de Souza]

Hi

Sorry for the delay, I'll make a new patch for the current version.

Best regards,

Antonio Anderson M. Souza
Voice Technology

http://www.voicetechnology.com.br
http://antonioams.blogspot.com

[ömer]

http://sipdroid-developers.googlegroups.com/web/sipdroid-0.9.11-asterisk-realm-patch.patch

this patch works for me.
uses realm returned from server
and sends ACK, ASAP server sends 407

On Jul 10, 4:26 am, "Antonio Anderson M. de Souza"

<antonio...@gmail.com> wrote:
> Hi
>
> Sorry for the delay, I'll make a new patch for the current version.
>
> Best regards,
>
> Antonio Anderson M. Souza

> Voice Technologyhttp://www.voicetechnology.com.brhttp://antonioams.blogspot.com

[Pascal Merle]

ömer, your version of the patch is working good for me, too,
at least the part fixing the realm thing.

I have committed and released it, slightly modified, and
added you as a member.

[ömer]

Hi Pascal,

in InviteTransactionClient

line 122:
connection_id = sip_provider.sendMessage(ack);
is processed after error responses.

my asterisk server 1.4 sends me 407 proxy authentication required. if
I don't respond to this with an ACK, server responds with 491 and then
connection drops.

The easiest solution I found is moving this ack 3 lines up. So it'll
send ACK directly. The server does not reply with 491.

On Jul 13, 12:52 am, Pascal Merle <pmerl...@googlemail.com> wrote:
> For adding as member send me your name on google code, please.

[ömer]

I think this might correspond to issue #27

[Pascal Merle]

Good. Please commit the change. I'll release a new version.

[jwebber]

Is this in the 1.0.1 release? I don't see the option in the
preferences screen to set Realm.

Thanks,
Joe

[jwebber]

Bump

Where is the Realm configuration item?

-Joe

> > Good. Please commit the change. I'll release a new version.- Hide quoted text -
>
> - Show quoted text -

[Jiri]

Hello Antonio,

please, could you create new patch for the current version of
Sipdroid? I'm desperately waiting to test it with my SIP provider.

Best regards,
Jiri


On Jul 10, 3:26 am, "Antonio Anderson M. de Souza"

<antonio...@gmail.com> wrote:
> Hi
>
> Sorry for the delay, I'll make a new patch for the current version.
>
> Best regards,
>
> Antonio Anderson M. Souza

> Voice Technologyhttp://www.voicetechnology.com.brhttp://antonioams.blogspot.com

[Jiri]

I have tried to implement both above mentioned patches into the latest
trunk source code (http://dpaste.com/86095/). It's maybe a good
starting point for Antonio.

The aim for me is to get it working with my SIP provider - CESNET
(http://www.ces.net/, https://sip.cesnet.cz/cs/swahw/klienti).

Best regards,
Jiri

[Jiri]

I have tested the realm patch a bit more and the conclusion is:

1) The patch works for CESNET. I can register and I can make and
receive a call.
2) Some parties can hear me (having Linksys VoIP phone) some not
(having some other device to receive the call). I guess there is some
bug in the G711 codec on the Sipdroid side.

I suggest to implement the patch into the main branch to allow more
people to connect to their SIP provider.

Then I would like to ask you to fix the codec problem because it is
causing a difficulty to some SIP providers (as mentioned in many
Issues, e.g. http://code.google.com/p/sipdroid/issues/detail?id=82).

Best regards,
Jiri

On Aug 27, 4:24 pm, Jiri <jiri....@gmail.com> wrote:
> I have tried to implement both above mentioned patches into the latest
> trunk source code (http://dpaste.com/86095/). It's maybe a good
> starting point for Antonio.
>
> The aim for me is to get it working with my SIP provider - CESNET

> (http://www.ces.net/,https://sip.cesnet.cz/cs/swahw/klienti).

[Jiri]

On Aug 28, 4:25 pm, Jiri <jiri....@gmail.com> wrote:
> 2) Some parties can hear me (having Linksys VoIP phone) some not
> (having some other device to receive the call). I guess there is some
> bug in the G711 codec on the Sipdroid side.

I can fix this problem by change of several values as suggested in the
issue #2 (http://code.google.com/p/sipdroid/issues/detail?id=2#c18).

[Pascal Merle]

Edit2:
I have already released the change for 2) Thanks for your work.

I would prefer not to include the patch for 1) into the main branch.
As suggested earlier we can start a new branch to sort the following
points out:

- The patch breaks ömers patch that automatically gets the realm from
the server for authentication purposes. This patch increased
interoperability
a lot. We don't want to loose that. Configuration should
only be necessary for _domain_ when the user explicitly wants to
choose it
to be different than server.

- Local IP address should be cached and updated only on the relevant
intents (see above).

[Jiri]

On Sep 3, 10:39 pm, Pascal Merle <pmerl...@googlemail.com> wrote:
> I would prefer not to include the patch for 1) into the main branch.
> As suggested earlier we can start a new branch to sort the following
> points out:

That would be really great if you create an other branch where the
realm stuff could be implemented properly.

> - The patch breaks ömers patch that automatically gets the realm from
> the server for authentication purposes. This patch increased
> interoperability a lot. We don't want to loose that.

I understand it.

> Configuration should only be necessary for _domain_ when the user
> explicitly wants to choose it to be different than server.

I agree. If the realm field is empty, the domain from the server
should be used.

> - Local IP address should be cached and updated only on the relevant
> intents (see above).

Sorry, but here I don't know exactly what's going on in the business
of the local address.

IMHO the proposed patch for the realm implementation is not really
huge. I think that its proper implementation shouldn't take more than
few hours for so experienced person as you are.

[Jiri]

On Sep 3, 10:39 pm, Pascal Merle <pmerl...@googlemail.com> wrote:

> - Local IP address should be cached and updated only on the relevant
> intents (see above).

I have created a patch which should fix this part of the issue. Please
see the file "sipdroid_local_ip_address.patch".

[Jiri]

On Sep 3, 10:39 pm, Pascal Merle <pmerl...@googlemail.com> wrote:

> I would prefer not to include the patch for 1) into the main branch.
> As suggested earlier we can start a new branch to sort the following
> points out:
>
> - The patch breaks ömers patch that automatically gets the realm from
> the server for authentication purposes. This patch increased
> interoperability
> a lot. We don't want to loose that. Configuration should
> only be necessary for _domain_ when the user explicitly wants to
> choose it
> to be different than server.
>
> - Local IP address should be cached and updated only on the relevant
> intents (see above).

I have reimplemented the realm patch and I believe you will be
satisfied with it. Please check the file "sipdroid_realm_new.patch"
which should solve both issues - the local IP and the realm setting.

The new patch implements the realm setting which is taken in account
only if its string length is not zero. In any other case the realm is
deduced from the server name (as it was before).

I have tested it with PBXES without the realm setting as well as with
my provider (CESNET) with realm setting. Everything works fine from my
point of view (I can accept calls and I can call other parties).

Please test it and if it works you can add it in the main tree.

Best regards,
Jiri

[Pascal Merle]

Your patches look good. Please give me your Google ID to add it into
the members' list.

Before committing please see my replies to your postings:

The option (variable names...) you called "realm" should be renamed to
"domain".

The term realm is reserved for the password authentication. domain is
the part after the @ that
is used in all the messages. realm is determined automatically for
sending the password. domain
is what you are really referring to.

Please also add a string saying that it can be left empty for most
providers. This should appear as the summary text for
the preference as long as nothing is entered there.

[Jiri]

Please see my new patch (sipdroid_realm_new2.patch).

You can find my Google ID in my Google Profile.

[Pascal Merle]

Before checking in please check if the modifications to
ExtendedInviteDialog are still necessary.
They were covered by ömer's patch already.

[Jiri]

The first part of the patch of the ExtendedInviteDialog is needed, but
the second part is not. So I have removed that and I'm going to commit
the changes into the tree.

[Ray Bellis]

I've had a problem with the domain/realm setting, with a colleague
seeing the same.

We both had (much) earlier versions installed. He upgraded to 1.07
from the market, and I built 1.09 from source.

We're both using accounts with pbxes.org. The settings page under
"domain" says to leave blank if it's the same as the server. However
we then couldn't SIP register with pbxes.org.

Setting the domain explicitly to "pbxes.org" fixed the problem.
Subsequently erasing the entry also allows us to register.

It appears that the zero length test was failing for some reason.
I've looked at the source (SipdroidEngine.java) and can't tell why
that would be, though. The Settings.java code _was_ correctly showing
the field's "summary" label, and that uses exactly the same logic.

Ray

[Jiri]

I have just tested it with the latest SVN source codes and I'm not
able to reproduce the error what you are experienced with. Please,
checkout the SVN repository and try to rebuild the Sipdroid again.

I propose the following steps:
1) Uninstall your current Sipdroid installation (this will remove all
settings in the /data/data/org.sipdroid.sipua/ directory)
2) Checkout the SVN repository.
3) Build and install new version of the Sipdroid.
4) Setup your Password and Username and see if it will connect to the
PBXES.org (in my case it did).

Cheers,
Jiri

[Ray Bellis]

2009/9/22 Jiri <jiri...@gmail.com>:

>
> I have just tested it with the latest SVN source codes and I'm not
> able to reproduce the error what you are experienced with. Please,
> checkout the SVN repository and try to rebuild the Sipdroid again.
>
> I propose the following steps:
> 1) Uninstall your current Sipdroid installation (this will remove all
> settings in the /data/data/org.sipdroid.sipua/ directory)
> 2) Checkout the SVN repository.
> 3) Build and install new version of the Sipdroid.
> 4) Setup your Password and Username and see if it will connect to the
> PBXES.org (in my case it did).

I don't believe this would show the problem. I'm sure the code works
fine when it's installed with no existing settings present.

I think it's somehow related to old and/or obsolete preferences data
affecting the code.

Ray

[Jiri]

Please, post here the content of your /data/data/org.sipdroid.sipua/
shared_prefs/org.sipdroid.sipua_preferences.xml file if you are still
experiencing the error.

[Ray Bellis]

2009/9/22 Jiri <jiri...@gmail.com>:

>
> Please, post here the content of your /data/data/org.sipdroid.sipua/
> shared_prefs/org.sipdroid.sipua_preferences.xml file if you are still
> experiencing the error.

Per my original post the fault is now gone.

It's likely that the only way to reproduce it is to re-install a much
older version, configure it, and then attempt an upgrade. I may be
able to try this.

Note that I saw this when upgrading from source, and a colleague had
the identical problem upgrading via the Android Market. It was his
finding the fault that led me to try it from source.

Ray

[Jiri]

I see. I'm afraid that here I can not help. What would definetely help
to avoid such kind of problems is to sign next release with new key.
This would force the user to uninstall the application before the new
version is installed.

[Ray Bellis]

2009/9/22 Jiri <jiri...@gmail.com>:

>
> I see. I'm afraid that here I can not help. What would definetely help
> to avoid such kind of problems is to sign next release with new key.
> This would force the user to uninstall the application before the new
> version is installed.

I will try to replicate the problem and report back.

Forcing the user to re-enter all of their settings is an inadequate work around.

Ray

[Bryan]

Hi,
I'd really like to be able to use sipdroid, but can't properly
register with asterisk due to the ip address issue. It seems that this
patch is having a lot of trouble remaining implemented. Is there
anything that I can do to help get this patch committed? Are there any
tests that I can run that might help?
Is the only problem right now that users running old versions of the
beta would have to re-enter their account settings?
Thank you,
Bryan

On Sep 22, 1:06 pm, Ray Bellis <ray.bel...@gmail.com> wrote:
> 2009/9/22 Jiri <jiri....@gmail.com>:

[Jiri]

Hi Bryan,

please try to uncomment the content of the function setLocalIpAddress
() in the file org/zoolu/net/IpAddress.java. This could fix your
problem. Unfortunately, it can also bring another problem as described
in the issue #139 (http://code.google.com/p/sipdroid/issues/detail?
id=139). Please report the result of your test here.

Best regards,
Jiri

[Bryan]

Jiri,

I checked out the svn, uncommented the ipaddress code and built it,
but localhost is still being sent in. I tried uninstalling, setting
the ipaddress to "" initially, instead of "127.0.0.1", and building,
but it's still sending in 127.0.0.1. I don't know where it's coming
from, but the peer is still listed as UNREACHABLE.

I'm comparing the REGISTER headers between Sipdroid and Ekiga, and 2
fields are present in Ekiga, but missing in Sipdroid:

Route: <sip:sip.emman.org:5060;lr>
ALLOW:
INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING

Besides that, Ekiga uses the correct IP in VIA, Contact and Call-ID
fields whereas Sipdroid sends 127.0.0.1, and Ekiga includes the port
5060 in the VIA field.

I don't see those missing fields defined in the
org.zoolu.sip.provider.SipStack class.

I'll log the my windows mobile 6 phone's registration tomorrow and
report any differences.

Thanks,
Bryan

[Bryan]

Jiri,

I'm seeing the registration timeout error now. Last night I was
testing from the same subnet as my asterisk server. Sipdroid was
sending the localhost, instead of the proper ip, but still
registering. The UNREACHABLE problem persisted and I couldn't receive
calls.

Testing off network this morning (from work), the proper ip and port
appear to be sent, rather than 127.0.0.1, but registration times out.
Asterisk is responding to the initial registration (1 REGISTER) with a
"401 Unauthorized".

The only difference that I'm seeing now is that Ekiga has it's VIA
field using port 5060, whereas Sipdroid sends it's outgoing port, in
this case, 46946.

Windows Mobile registration looks mostly like Ekiga and Sipdroid,
though without rport.

I'll try some more off-network registrations between Ekiga and
Sipdroid to look for differences and try to find out why asterisk
would respond with "401 Unauthorized".

Bryan

[Bryan]

I should specify that Windows Mobile doesn't use the ALLOW or ROUTE
fields, like Sipdroid and unlike Ekiga, so I don't think those are the
problem. How can I try removing the port from the FROM/VIA/Contact
fields? Ekiga only specifies a port in the VIA field, and it's 5060,
rather than it's own outgoing port. I think I should be looking in the
IPAddress or SipStack classes, right?

Thanks!

[Bryan]

UserAgentProfile class is appending the port.

[Bryan]

It looks like Sipdroid is sending the wrong port. The port indicated
in the VIA field doesn't match what asterisk says it's receiving on.

[Bryan]

I think the problem is simply that the via and contact aren't being
updating with the received and rport values returned by asterisk. I'm
trying to find out where to change that.

[Bryan]

org.zoolu.sip.provider.SipProvider.processReceivedMessage has code to
handle the received and rport values from the provider, HOWEVER, the
checking is performed on the provider's values instead of the
client's.

Sipdroid is sending this to Asterisk:
Via: SIP/2.0/UDP 127.0.0.1;rport

Asterisk is transmitting to the client:
Via: SIP/2.0/UDP 127.0.0.1:received=66.227.95.240;rport=3963

processReceivedMessage is checking:

src_addr == via_addr?
rport?
src_port == via_port?
force_rport?

The src and via values are the same, but they are not the client's
values, but instead the providers. This may be necessary if the
provider is forwarding the client elsewhere, but this sort of checking
needs to be done to the sip_provider object in Sipdroid as well.

[Bryan]

Hello again,

I think I've nearly solved the issues (9,21,109,111,147,149)
surrounding the branch not being updated and the received and rport
values being ignored in the via header.

I think that the SipProvider.via_addr, SipProvider.host_port, branch,
and via header should all be updated in:
org.zoolu.sip.provider.SipProvider.processReceivedMessage. The problem
that I'm running into is that the listeners are tracked using a
transaction id that is built off of those values, so changing them
breaks the callbacks to the listeners from the sip_provider.

Here's what I'm looking at, but how do I fix the callbacks to the
listeners?

<snippet>
protected void processReceivedMessage(Message msg) {
try { // logs
</snippet>
...
<snippet>
if (msg.isRequest()) {
ViaHeader vh = msg.getViaHeader();
boolean via_changed = false;
String src_addr = msg.getRemoteAddress();
int src_port = msg.getRemotePort();
String via_addr = vh.getHost();
int via_port = vh.getPort();
if (via_port <= 0)
via_port = SipStack.default_port;
if (!via_addr.equals(src_addr)) {
vh.setReceived(src_addr);
via_changed = true;
}
if (vh.hasRport()) {
vh.setRport(src_port);
via_changed = true;
} else {
if (force_rport && via_port != src_port) {
vh.setRport(src_port);
via_changed = true;
}
}
if (via_changed) {
msg.removeViaHeader();
msg.addViaHeader(vh);
}
}
// my new code starts here
// handle "received" and "rport" parameters FOR RESPONSES TOO!
// pick a new branch (RFC3261), and handle received and rport values
(RFC3581)
else {
ViaHeader vh = msg.getViaHeader();
String received_addr = vh.getReceived();
int via_port = vh.getRport();
if (received_addr != null)
via_addr = received_addr;
if (via_port > 0)
host_port = via_port;
// start a new transaction
vh = new ViaHeader(vh.getProtocol(), via_addr, host_port);
if (rport)
vh.setRport();
vh.setBranch(pickBranch(msg));
msg.removeViaHeader();
msg.addViaHeader(vh);
// there's no listener keyed on the new transactionId
}
</snippet>
...

Any help would be really great. Thank you!

Bryan