[Serdev] TCP Blocking Connect issue

[Jiri Kuthan]

Have you tried moving the subst action after the loose_route condition?

-jiri

At 07:34 AM 8/25/2004, Andrew Mee wrote:
>Oooopppsss... ignore my comments on re.c... I didn't look at it correctly....
>
>Andrew
>
>Andrew Mee wrote:
>
>>
>>Apologies on the big email... there was just a lot of information :)
>>
>>Ok I tried the substr code lots of times with no luck.
>>In the end I had a look at re.c and noticed the code around line 481 looks wrong
>>i.e it should be  r!=0 (I think) as this then made the code work, at least according to debug information....
>>
>>But..... Then SER dropped out with memory errors.... I assume perhaps this bit of code is unfinished? :)
>>
>>Andrew
>>
>>
>>
>>Jiri Kuthan wrote:
>>
>>>We are possibly getting closer...nailing down the critical pieces of troubleshooting information has been very helpful
>>>to us. Thanks!
>>>
>>>In summary I guess what you describe is caused by the way Windows Messenger
>>>constructs record-routing -- based on RFC2543 (obsoleted) and maddr.
>>>We may be better backwards-compatible (questions to my collegue,
>>>Jan, are inline).
>>>
>>>This is a quick attempt to resolve the problem. It may or may not work,
>>>in any case I would love to hear from you if it worked. I'm pesimistic
>>>and guess it won't help but learning that would be a great troubleshooting
>>>aid to me.
>>>
>>> move the subst_uri action from the loose_route condition after it and
>>> let me know if it did any better. (I hope the ACK will then be processed as
>>> outbound request and not record-routed request -- that should work too.)
>>>
>>>-jiri
>>>
>>>At 01:07 AM 8/25/2004, Andrew Mee wrote:
>>> 
>>>
>>>>Tried this in my config to no avail....
>>>>
>>>>However I'm attaching the DEBUG log file and I noticed the following:
>>>>
>>>>serctl ul show support at 192.168.2.253
>>>><sip:192.168.2.11:7887;transport=tcp>;q=0.00;expires=3541 <-- Bad
>>>><sip:192.168.2.11:8346;transport=tcp>;q=0.00;expires=3598  <-- Good
>>>>  
>>>
>>>
>>>Content of User Location cache has no impact on forwarded of subsequent in-dialog reqeusts such as ACKs. ACK must be forwarded based on Route
>>>rules. The facts they are not is casued by too different ways how
>>>SER and Messenger works.
>>>
>>>
>>> 
>>>
>>>>But this line occurs....
>>>>
>>>>14(10871) check_self - checking if port 5060 matches port 5060
>>>>14(10871) rwrite(): Rewriting Request-URI with
>>>>'sip:192.168.2.11:7887;transport=tcp'
>>>>  
>>>
>>>
>>>
>>>
>>>That's a message from user lookup. User location lookup shall NOT
>>>be applied to subsequent requests, only to initial requests.
>>>The fact, that it is applied tells me there is a potential shortcoming
>>>with record-routing in SER that cannot handle Messenger's obsoleted
>>>Record-routing.
>>>
>>>To recap the essential pieces:
>>>- this is the ACK; it is SIP-2543 compliant, strict-routing-based, with
>>> use of maddr parameter in Route (driven by UAS's contact)
>>>T 192.168.2.28:1071 -> 192.168.2.253:5060 [AP]
>>> ACK sip:support at 192.168.2.253;transport=tcp;ftag=455e2e10b10e464cafe24f3603
>>> 111429;lr=on SIP/2.0
>>> Route: <sip:support at 192.168.2.253:8346;maddr=192.168.2.11;transport=tcp>
>>>
>>>SER should recognize this as a record-routed message and forward it to
>>>the destination in Route/maddr: 192.168.2.11:8346.
>>>
>>>Here is where I begin to be confused. The record-routing certainly does
>>>not return TRUE -> the subst_uri is never executed. I think that is
>>>subject to fixing but I am not sure what is the root reason. (Jan, cc, will know better.) It is indicated by the "rewrite" log line which tells usrloc was applied (i.e., loose_route must have returned false).
>>>
>>>It appears that SER's rr-ing fails to replace request-URI. That's indicated by passing the uri==myself condition, which should not be passed if r-URI was replaced with Route uri containing the port number 8346. Other indication is that the comparison bellow does not include the port
>>>8346.
>>>If the config file change mentioned above does not help, that would be an indication for it too.
>>>
>>>14(10871) check_self - checking if host==us: 13==13 &&  
>>>[192.168.2.253] == [192.168.2.253]
>>>14(10871) check_self - checking if port 5060 matches port 5060
>>>
>>>
>>>Here all the critical log lines.
>>>
>>>14(10871) check_self - checking if host==us: 13==13 &&  
>>>[192.168.2.253] == [192.168.2.253]
>>>14(10871) check_self - checking if port 5060 matches port 5060
>>>14(10871) check_self - checking if host==us: 13==13 &&  
>>>[192.168.2.253] == [192.168.2.253]
>>>14(10871) check_self - checking if port 5060 matches port 8346
>>>14(10871) parse_headers: flags=256
>>>14(10871) DEBUG: get_hdr_body : content_length=0
>>>14(10871) found end of header
>>>14(10871) fnr(): No next Route HF found
>>>14(10871) ras(): No next URI found
>>>14(10871) check_self - checking if host==us: 13==13 &&  
>>>[192.168.2.253] == [192.168.2.253]
>>>14(10871) check_self - checking if port 5060 matches port 5060
>>>14(10871) rwrite(): Rewriting Request-URI with 'sip:192.168.2.11:7887;transport=tcp'
>>>
>>>
>>> 
>>
>>_______________________________________________
>>Serdev mailing list
>>serdev at lists.iptel.org
>>http://lists.iptel.org/mailman/listinfo/serdev
>> 
>
>
>_______________________________________________
>Serdev mailing list
>serdev at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serdev

--
Jiri Kuthan            http://iptel.org/~jiri/