[sip-comm-dev] [PATCH] Ignore duplicate SIP invite OK message


#1

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

ignore-duplicate-invite-ok.patch (1.08 KB)


#2

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