FW: latest nist-sip stack issue

In fact the sample route header provided was not correct. Upon trying with a different configuration, like:

<sip:10.112.128.59:5060;lr>,<sip:[email protected]:5060;lr>

I was already able to use this version of the stack for starting a call.
Still, when I try to send a CANCEL to the second leg when diverting to a third leg, the stack will still throw an exception, when entering the 
following in code in gov.nist.javax.sip.stack.SIPClientTransaction:

public void sendRequest() throws SipException {
	SIPRequest sipRequest = this.getOriginalRequest();
	
	try {
				if(this.getOriginalRequest().getMethod().equals(Request.CANCEL)){
				SIPClientTransaction ct = (SIPClientTransaction) 		sipStack.findCancelTransaction(this.getOriginalRequest(), false);
		if (ct == null) {
			// If the original
			// request has generated a final response, the CANCEL SHOULD
			// NOT be
			// sent, as it is an effective no-op, since CANCEL has no
			// effect on
			// requests that have already generated a final response.
		 ---> throw new SipException("Could not find original tx to cancel. RFC 3261 9.1");

Thanks

Luis

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

Luis,

What appears to be happening is  that the route is  pointing the request 
back at your own listening point and as expected,  the router is pushing 
the route back to your own stack. Do you have to remove the topmost 
route header before you try to route the request outwards?  This may be 
the effect you desire but I doubt it. In any case, thats what is going 
on and it is behaving as expected. In the previous version of  JAIN SIP, 
the stack could be configured to strip off the route header. We 
rationalized all this in the new version. I have a suspicion that 
something along these lines is happening.

Ranga


Luis Alberto Teixeira wrote:

>Ranga,
>
>The route header is generated in the openser proxy server, in which a rule is defined that for some given users it adds a Route header with two fields, which can be something like:
>
>	Route: <sip:10.112.128.59:5060>,<sip:[email protected]:5060>
>
>The idea is to let the application server where my service is running be put in the signaling path, so that a request coming from a client first passes by the dedicated proxy server, and then forcefully traversing the AS. Other requests and responses from this and other selected clients should also be forced to pass by the same application server.
>
>Luis
>
>
>
>
>
>
>
>-----Original Message-----
>From: M. Rangnathan [mailto:[email protected]] 
>Sent: segunda-feira, 13 de Março de 2006 17:17
>To: Luis Alberto Teixeira
>Cc: [email protected]
>Subject: Re: [nist-sip] latest nist-sip stack issue
>
>Luis,
>
>How did you compute your Route Header? If it points back at you, thats 
>exactly where the request is going to be heading.
>
>Regards,
>
>Ranga
>
>Luis Alberto Teixeira wrote:
>
>  
>
>>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!