[Serdev] TCP Blocking Connect issue
Andrew Mee
andrew at healthshare.net.au
Wed Aug 25 06:09:37 UTC 2004
Yes! It didn't work...
Debug always says
subst_uri: running. r=1
subst_uri: no match
No matter where I put it. I even tried some simpler regular expressions,
same problem...
Thanks
Andrew
Jiri Kuthan wrote:
>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/
>
>
>
--
Andrew Mee
Programmer
HealthShare
Level 3 80 Stamford Rd Indooroopilly QLD 4086 Australia
T +61 (0)7 3378 7575 F +61 (0)7 3878 9883 M 0415 9044 65 E andrew at healthshare.com.au W www.healthshare.com.au
Disclaimer
The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and unlawful. Despite our best efforts, the sender and HealthShare makes no warranties that this e-mail is free of infection by computer viruses or other contamination.
-------------- 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/5cdebbc9/andrew.vcf
More information about the Serdev
mailing list