[Serdev] TCP Blocking Connect issue

Mon Aug 23 05:23:11 UTC 2004

At 06:41 AM 8/23/2004, Andrew Mee wrote:
>Umm... Ok I'm a little lost in your explanation, 

ACK must include ROUTE header field which forces SER to forward the
request to a destination which is dead after the UAS crashed. -> it can't
be delivered.

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

It should be there. Incoming ACK should have Route based on Record-Route
from 200.

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

Well, if UA crashes, dialog state disappears. I don't see any use of delivering
a message, which is a part of a dialog, which no longer exists. Read RFC3261 for
normative reference. If a UAS wishes to be super-persistent, then after the crash
it must completely reconstruct dialog state (otherwise subsequent rquests will
be denied as out-of-dialog) and transport state (otherwise different port numbers
will cause failed delivery).

-jiri

>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
>
>
>
>
>
>_______________________________________________
>Serdev mailing list
>serdev at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serdev

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