2 apr 2007 kl. 19.32 skrev Raj Jain:
I found a subtle difference between the two traces you sent (the
call that works and the call that gets dropped). This may or may
not be what's causing the problem.
The call that gets dropped had a retransmission of INVITE from UAC
to UAS (and therefore retransmission of 200 OK from UAS to UAC).
There is nothing wrong with the re-transmission as such, but I
noticed a potential bug in Asterisk in the way it responds to an
INVITE retransmission. Asterisk is bumping up the session version
number in the retransmitted 200 OK's SDP. This is as if Asterisk is
treating the INVITE retransmission as a RE-INVITE.
Asterisk sends 200 OK:
o=root 16300 16300 IN IP4 203.89.nnn.nnn
Asterisk sends 200 OK (retransmission):
o=root 16300 16301 IN IP4 203.89.nnn.nnn
Ideally, this bug should have nothing to do with why Asterisk is
ignoring the ACK (which is why it keeps reatrasmitting the 200 OK
and eventually drops the call). However, if you can confirm that
all dropped calls have INVITE retransmission then that might give
us a clue?
Raj,
That's an interesting observation. Do you think this will cause any
issues? Even though it's not
beautiful, I fail to see why a UA would check that.
/O
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
