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
* 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
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.
ignore-duplicate-invite-ok.patch (1.08 KB)