RE: latest nist-sip stack issue

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!