[Serdev] TCP Blocking Connect issue

[Andrew Mee]

Umm... Ok I'm a little lost in your explanation, I have followed the 
packets back and forth, there is no record route information that says 
contact this UA at specific port number in the packet headers. So when 
it tries to Forward the ACK to the called UA from the Proxy, it fails 
because it (as assumed) uses an incorrect old port number and it has 
lost it's original TCP connection for whatever reason. Surely this ACK 
should be resent by the Proxy to the UA to the next ip:port combination 
it has a record of when it can't get through before it gives up on the 
call. I don't see how this is ok that the ACK is not delivered??

It seems the original INVITE method will find the correct port to send 
information on so it sets up the first part of the call.

I'm hoping I haven't missed something here?

Thanks

Andrew

Jiri Kuthan wrote:

>That's still a valid case -- forwarding of ACK should be governed by 
>record-routing since it belongs to a dialog and should be forwarded
>to where 200 came from (which is dead now). Content of user location
>database shall have no impact on where to forward. In which case, it is
>ok that the ACK cannot be delivered.
>
>What you need to verify is that new initial request will get forwarded
>to the right place, even if some alternate destinations are no longer
>valid.
>
>-jiri
>
>
>At 04:40 AM 8/23/2004, Andrew Mee wrote:
>  
>
>>Yep, I just watched the crashed binding expire (it took an hour)
>>
>>Our previous tests do show that when I send an Invite that it only checks the first binding then stops... It does not check subsequent bindings. i.e..
>>serctl ul show support at 192.168.2.253
>><sip:192.168.2.11:14858;transport=tcp>;q=0.00;expires=1991 <-- Bad
>><sip:192.168.2.11:7308;transport=tcp>;q=0.00;expires=2911  <-- Bad
>><sip:192.168.2.11:11822;transport=tcp>;q=0.00;expires=3595 <-- Good
>>
>>test2 calls support
>>Ok does invite up to ACK to support (from debug)
>>13(13758) Sending:
>>ACK sip:192.168.2.11:14858;transport=tcp SIP/2.0
>>Record-Route: <sip:support at 192.168.2.253;transport=tcp;ftag=7790d6ca5a9c418da27c37a55ee9c94c;lr=on>
>>Via: SIP/2.0/TCP 192.168.2.253;branch=0;i=01
>>Via: SIP/2.0/TCP 192.168.2.28:16532
>>Max-Forwards: 69
>>From: "HS User" <sip:test2 at 192.168.2.253>;tag=7790d6ca5a9c418da27c37a55ee9c94c;epid=872603d44e
>>To: <sip:support at 192.168.2.253>;tag=4b2b9c668798498eb7e0e20a8c64c72d
>>Call-ID: a2a3e3fb7e3e4a4b92175ffdc68f04ec at 192.168.2.28
>>CSeq: 1 ACK
>>User-Agent: RTC/1.2
>>Content-Length: 0
>>
>>.
>>13(13758) orig. len=504, new_len=529, proto=2
>>13(13758) tcp_send: no open tcp connection found, opening new one
>>13(13758) ERROR: tcp_blocking_connect: SO_ERROR (111) Connection refused
>>13(13758) ERROR: tcpconn_connect: tcp_blocking_connect failed
>>13(13758) ERROR: tcp_send: connect failed
>>13(13758) msg_send: ERROR: tcp_send failed
>>13(13758) Warning: sl_send_reply: I won't send a reply for ACK!!
>>13(13758) ERROR: sl_reply_error used: Unfortunately error on sending to next hop occured (477/SL)
>>13(13758) DEBUG:destroy_avp_list: destroing list (nil)
>>13(13758) receive_msg: cleaning up
>>
>>But thendoesn't try next available binding.
>>
>>Andrew
>>
>>Jiri Kuthan wrote:
>>
>>    
>>
>>>At 03:13 AM 8/23/2004, Andrew Mee wrote:
>>>
>>>
>>>      
>>>
>>>>It seems your assumption is right!
>>>>
>>>>Client Logs in.
>>>>serctl ul show support at 192.168.2.253
>>>><sip:192.168.2.11:10227;transport=tcp>;q=0.00;expires=3546
>>>>
>>>>Crash Client!!
>>>>
>>>>serctl ul show support at 192.168.2.253
>>>><sip:192.168.2.11:10227;transport=tcp>;q=0.00;expires=3457
>>>>
>>>>Restart Client
>>>>
>>>>serctl ul show support at 192.168.2.253
>>>><sip:192.168.2.11:10227;transport=tcp>;q=0.00;expires=3403
>>>><sip:192.168.2.11:14858;transport=tcp>;q=0.00;expires=3585
>>>>
>>>>Ok the question now if the TCP connection cannot be made should it delete the not available connection and then try the next connection... or...
>>>>Should perhaps register delete existing entries and create new ones?
>>>>  
>>>>        
>>>>
>>>The right way is to have the dead bindings expired. The question is:
>>>if one of the bindings is valid and active, does the INVITE to the
>>>address of record fail? That should not happen, SER should try those
>>>which are available. If that does happen, that would be a shortcoming.
>>>Can you verify that?
>>>
>>>Thanks,
>>>
>>>-jiri
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>Serdev mailing list
>>serdev at lists.iptel.org
>>http://lists.iptel.org/mailman/listinfo/serdev
>>    
>>
>
>--
>Jiri Kuthan            http://iptel.org/~jiri/ 
>
>  
>


-- 
Andrew Mee
 


-------------- 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/20040823/ecf7f999/andrew.vcf