Hi Michael,
Committed and ack-ed! (Issue #392 is now fixed).
Thanks!
Emil
Koch Michael wrote:
> Hi all!
>
> When testing SIP telephony by repeatedly creating and
hanging up a call, I
> occasionally but reproducibly got NullPointerExceptions
from within the JMF
> when closing the send streams in
CallSessionImpl.stopStreaming on the caller
> side. After much analyzing, I found that the following
happened:
>
> * The caller starts the call by sending the INVITE.
> * The callee answers the INVITE first with a RINGING,
then with an OK
> response as UDP packet.
> * The caller starts processing the message in
> OperationSetBasicTelephonySipImpl.processInviteOK. This
takes a few seconds
> (at least with my setup with audio and video) and
involves initializing the
> RTP send streams.
> * The callee resends the OK UDP packet, since the
caller hasn't sent the ACK
> fast enough.
> * The caller somehow doesn't notice that the OK UDP
packet is a duplicate
> and invokes
OperationSetBasicTelephonySipImpl.processInviteOK again. The
RTP
> send streams are created again for the same datasources
and IP
> addresses/ports.
>
> When the call is closed, the JMF gets confused when the
send streams are
> closed, and throws a NullPointerException when the
duplicate send stream is
> closed. In following calls, the RTP managers are
successfully created, but
> no data is sent.
>
> I don't know if it is a bug in the SIP stack that
processResponse is called
> for a duplicate OK, or if the application is supposed
to filter it. In the
> attached patch, I ignore the invite OK if the
callParticipant is already in
> state CONNECTED, which fixes my problem.
>
> Regards
> Michael Koch
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribe sip-communicator.dev.java.net
For additional commands, e-mail: dev-help sip-communicator.dev.java.net
|