< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index | Next in Thread > |
Definitely sounds odd. I don’t think we did anything to
specifically fix something like that – but there are many many fixes since 0.9
and would highly recommend that you upgrade to 1.0. Scott From: Sunitha Beeram
[mailto:Sunitha.Beeram@xxxxxxxxxx] My application uses SIP INVITES and also INFO messages during the
session. Sometimes the INFO messages result in actions from the remote SIP
client which lead to re-INVITEs. During such a session, about 300s
(5min) into the meeting, AckNotReceived event is dispatched and the
session is "end"ed. This happened on about 3 attempts, but the
behavior hasnt' shown up since. The remote end uses an asterisk client. Trace: SIP:Timeout Message SIP:InviteSessionHandler::onAckNotReceived SIP:InviteSession::Connected: end SIP:Sending SipReq: BYE xxx@xxxxxxx
tid=4f140f079e8a4157 cseq=BYE contact=601 / 8 from(tu) SIP:Transition InviteSession::Connected ->
InviteSession::Terminated I looked at tcpdump traces, I didn't see any retransmission
attempts and found this to be weird. It looked like the ACK to the 200 OK made
it back in 90ms, however, the BYE was issued ~40ms after the 200 OK was sent. I
do understand it might be difficult to gather the entire context from this
; there is a possibility that some message earlier-on didn't get an ACK
and am matching wrong messages, but as said, I didn't find any retransmission
attempts. ~Sunitha From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx] Dum will wait for the ACK before a issuing the BYE – doesn’t
sound related to unexpected BYE’s terminating an INVITE session. Can you
describe what you were seeing in more detail? From:
resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Sunitha
Beeram Hi,
I am currently using reSIProcate 0.9 and am planning to move to 1.0. The
release notes for 1.0 states among fixes for DUM, that it has " fixes to dum states for
initiating a BYE while waiting for an ACK". Can someone elaborate on this bug? I
ran into some unexpected BYEs terminating an INVITE session and want to know if
the 2 bugs are related. Thanks
|