[Serdev] TCP Blocking Connect issue

[Andrew Mee]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: andrew.vcf
Type: text/x-vcard
Size: 889 bytes
Desc: not available
Url : http://lists.iptel.org/pipermail/serdev/attachments/20040825/77279c44/andrew.vcf