RE: latest nist-sip stack issue

Ranga,

No, my problem is not related to the one Eduardo exposed. In my case the getSentBy() method is correctly returning a string object. I am using the latest version retrieved from the is2.antd.nist.gov cvs repository. When I remove the check, no errors occur but the request is not forwarded, like if it would in fact hop back to the host.

Thanks.

Luis



-----Original Message-----
From: M. Rangnathan [mailto:[email protected]] 
Sent: quinta-feira, 9 de Março de 2006 19:27
To: Luis Alberto Teixeira
Cc: [email protected]
Subject: Re: [nist-sip] latest nist-sip stack issue


Luis,

Is the null pointer you are seeing in any way related to the problem 
earlier reported by Miguel Martins ( mail entitled SIP Stack Error ). 
Can you check if the getSentBy() is returning null and hence causing 
your problem. If so then are you using the current stack version? I had 
fixed an issue some time ago where getSentBy() was returning null and 
causing this problem. You may also want to just remove this check and 
see if all else works. However, please check on this possiblity of 
getSentBy() returning null.

Mail me back if the problem still persists and I will fix it.


Thanks

Ranga

Luis Alberto Teixeira wrote:

>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
> 
> 
> 
>
>
>_______________________________________________
>nist-sip mailing list
>[email protected]
>http://www-x.antd.nist.gov/mailman/listinfo/nist-sip
>  
>


-- 
M. Ranganathan 

Advanced Networking Technologies Division,
National Institute of Standards and Technology (NIST),
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
tel:301 975 3664 , fax:301 590 0932 http://w3.antd.nist.gov/
Advanced Networking Technologies For the People!