[Serdev] TCP Blocking Connect issue

[Andrew Mee]

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
>  
>