Woof!
Is SIP (specifically our proxy) supposed to re-send data on a TCP/IP
connection? If it doesn't get any response via TCP, should it close the
TCP connection that failed and not use it again?
I'm seeing sipXproxy send the same PDU 3 times down the same TCP/IP
connection, with about 100, 200, and 400 mS between each attempt. Then it
fails over and sends via UDP. It doesn't close the TCP/IP connection and
re-open, even after the failure it leaves it open and keeps trying to use
it for further calls.
I've simulated this with "nc". First, shutdown FS via sipxconfig so it
isn't running.
In window 1, set up nc to listen on TCP 15060 (where FreeSWITCH would be
if it were running):
nc -vl 15060
In window 2, set up nc to listen on UDP 15060:
nc -ulv 15060
Then make a call that would hit FS (the Auto Attendant, for example):
This is what shows up:
Window 1 (TCP):
Connection from 192.168.1.108 port 15060 [tcp/*] accepted
INVITE
sip:[email protected]:15060;action=autoattendant;schedule_id=aa_7;locale=en
SIP/2.0
...
INVITE
sip:[email protected]:15060;action=autoattendant;schedule_id=aa_7;locale=en
SIP/2.0
...
INVITE
sip:[email protected]:15060;action=autoattendant;schedule_id=aa_7;locale=en
SIP/2.0
Then in Window 2 (UDP)
INVITE
sip:[email protected]:15060;action=autoattendant;schedule_id=aa_7;locale=en
SIP/2.0
...
INVITE
sip:[email protected]:15060;action=autoattendant;schedule_id=aa_7;locale=en
SIP/2.0
...
INVITE
sip:[email protected]:15060;action=autoattendant;schedule_id=aa_7;locale=en
SIP/2.0
Then the call fails with a timeout and fast busy, (which is correct as
nothing responded).
But then, if I make another call to the the AA it uses the same, existing
TCP/IP connection and sends 3 INVITES again, etc.
I'd have thought that:
1. TCP/IP wouldn't "resend" on the same connection, that's TCP/IP's job
to retry failed messages.
2. Even if it does "resend" (it shouldn't hurt), once it fails over to
UDP the failed TCP connection would be closed and not reused.
3. Subsequent calls would not reuse a TCP/IP connection that didn't
respond.
--Woof!
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
