[Serdev] TCP Blocking Connect issue

[Jiri Kuthan]

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/