latest nist-sip stack issue

Hi,
Upon attempting to use the latest version of NIST-SIP, one major issue appeared on the
situation I am reporting:
In the method createHop() from gov.nist.javax.sip.stack.DefaultRouter, whenever the method 
provider.getNewClientTransaction(request) from the javax.sip.SipProvider class is invoked the 
hopsBackToMe method returns true, which appeared unexpected in the situation where this was tested. 
This causes the provider.getNewClientTransaction(request) method to fail, preventing the request 
to be forwarded. The code from gov.nist.javax.sip.stack.DefaultRouter where the method is 
invoked is the following:
String host = sipUri.getMAddrParam() != null ? sipUri.getMAddrParam(): sipUri.getHost();
--> if (hopsBackToMe(host, port, transport)) {
 if (sipStack.isLoggingEnabled())
  sipStack.logWriter.logDebug("NextHop hops back to me, bailing...");
 return null;
} else {
 return new HopImpl(host, port, transport);
}

The scenario where this problem occurs consists for instance of three clients (Counterpath eyeBeam 
softphones) registered to a SIP Proxy (openser) where a few rules are defined, that 
cause all the signalling except the REGISTER method to be routed to an Application Server (Mobicents) 
running our Conditional Call Control service. The service upon execution of its internal logic, 
attempts to divert a call (or not, sending the invitation to the original destination), using the 
nist-sip stack to forward the call. So after the caller places the call, the signalling passes through 
the openser proxy before reaching the AS. The openser proxy modifies the requests in order to 
allow all inboud requests to go through it (by changing the Record-Route and Route headers). 
Just when the service attempts to send the request an exception caused by the null result of hopsBackToMe() 
is thrown.

With an older version of the NIST-SIP stack this issue would not occur, all the requests being
forwarded without trouble.
This is the original request created by the client:

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.112.128.15:6130;branch=z9hG4bK-d87543-c2346f0cbf5db612-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:[email protected]:6130>
To: <sip:[email protected]>
From: "Luis Teixeira A"<sip:[email protected]>;tag=0c43575d
Call-ID: b17db0382609542e@R1JJRkZJTjI <mailto:b17db0382609542e@R1JJRkZJTjI> .
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Supported: eventlist
User-Agent: eyeBeam release 3010n stamp 19039
Content-Length: 301
v=0
o=- 22782803 22782872 IN IP4 10.112.128.15
s=eyeBeam
c=IN IP4 10.112.128.15
t=0 0
m=audio 9818 RTP/AVP 100 6 0 8 3 18 97 5 101
a=alt:1 1 : 2E52FB16 00000073 10.112.128.15 9818
a=fmtp:101 0-15
a=rtpmap:100 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

and this is the modified request that reaches the AS, having the RequestURI changed just before 
the request is forwarded:
INVITE sip:[email protected] SIP/2.0
Record-Route: <sip:10.112.128.3;ftag=0c43575d;lr=on>,<sip:10.112.128.59:5060;maddr=10.112.128.59;transport=udp;cluster=mobi-cents>
Via: SIP/2.0/UDP 10.112.128.59:5060,SIP/2.0/UDP 10.112.128.3;branch=z9hG4bKc728.06806096.0,SIP/2.0/UDP 10.112.128.15:6130;branch=z9hG4bK-d87543-c2346f0cbf5db612-1--d87543-;rport=6130
Contact: <sip:[email protected]:6130>
To: <sip:[email protected]>
From: "Luis Teixeira A" <sip:[email protected]>;tag=0c43575d
Call-ID: b17db0382609542e@R1JJRkZJTjI <mailto:b17db0382609542e@R1JJRkZJTjI> .
CSeq: 1 INVITE
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,NOTIFY,MESSAGE,SUBSCRIBE,INFO
Content-Type: application/sdp
Supported: eventlist
User-Agent: eyeBeam/release/3010n/stamp/19039
Route: <sip:[email protected]:5060;lr>
Max-Forwards: 68
Content-Length: 301
v=0
o=- 22782803 22782872 IN IP4 10.112.128.15
s=eyeBeam
c=IN IP4 10.112.128.15
t=0 0
m=audio 9818 RTP/AVP 100 6 0 8 3 18 97 5 101
a=alt:1 1 : 2E52FB16 00000073 10.112.128.15 9818
a=fmtp:101 0-15
a=rtpmap:100 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

Do you have an idea about what might be causing this problem? Is that kind of network configuration that is still not well supported or is it a known problem with this version of nist-sip?
 
 
Thanks.
 
Cheers,
 
Luis Teixeira