List Info

Thread: Ignore duplicate SIP invite OK message




Ignore duplicate SIP invite OK message
user name
2007-08-15 06:12:37
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
  Approximate file size 1395 bytes
Re: Ignore duplicate SIP invite OK message
user name
2007-10-29 10:03:56
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-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net


[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )