[sip-comm-dev] SOme problems if another SIP client send a "double INVITE"


#1

Dear all,

testing with another SIP client (pjsua) I found some problems and
strange behaviour in conjunctions with RTP/SRTP

Attached is a wireshark file that shows the network activities.

The following call flow:

- pjsua (at address *.130) calls SC (at address *.1) and sends an INVITE
  offering several codecs

- SC answers with 200 OK, also offersing several codecs (2 in this case)
  (pjsua always reduces the number of codecs to one, for example if it
  receives an invite with several codes it send a 200 OK that contains
  only the one codec it selected).

- pjsua sends ACK but sends another INVITE immediately afte rthe ACK
  that contains only the one codec that pjsua selected.

- SC answers with 200 OK to this second invite

- pjsua sends ACK

In this case sometimes I don't hear pjsua audio, sometimes I hear it.
The attached files shows the second case also with a successful ZRTP
exchange. However, while the pjsua data is encrypted, the SC data is
not (I can deduct this from the RTP data pattern sent by SC). Thus
it seems that SC does seems to use 2 RTP sessions on the same port?
Could that happen because of the double invite (sort of re-invite) that
SC creates a second set of RTP session objects. This would explain that
sometimes I don't hear pjsip's audio.

To check this theory I reduced the number of codecs in SC to just
one so that SC offers only one codec in 200 OK. In this case pjsua
does not perform a second invite (because there was no reason to
reduce the number of codecs) and the RTP connection was ok, ZRTP
was ok and data was encrypted in both directions.

Can you have a look to this?

Regards,
Werner

double-invite1.pcap.tar.gz (104 KB)


#2

Additional info:

During the tests I got the following exceptions. Maybe this helps to
locate the problem? I'm not sure if these exceptions are connected to
the problem I've reported in the previous mail.

Regards,
Werner

     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@498d1538
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@4d6c3541
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@1a6fc530
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicRendererModule@1ffadfdf
     [java] BasicRendererModule.doPrefetch:155 Render : true
     [java] BasicRenderModule.doPrefetch:159 Render : net.java.sip.communicator.impl.neomedia.jmfext.media.renderer.audio.PortAudioRenderer@5879ff89
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@5bbb8077
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@72ef33ad
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@7e4c974d
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@56618102
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@256ee01c
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@123b6177
     [java] 18:46:47.658 SCHWERWIEGEND: impl.neomedia.MediaStreamImpl.stopSendStreams().1911 Failed to close stream com.sun.media.rtp.SendSSRCInfo@23852c7f
     [java] java.lang.NullPointerException
     [java] at com.sun.media.rtp.RTCPTransmitter.bye(RTCPTransmitter.java:119)
     [java] at com.sun.media.rtp.RTCPReporter.releasessrc(RTCPReporter.java:137)
     [java] at com.sun.media.rtp.RTCPReporter.close(RTCPReporter.java:132)
     [java] at com.sun.media.rtp.RTPSessionMgr.stopParticipating(RTPSessionMgr.java:2492)
     [java] at com.sun.media.rtp.RTPSessionMgr.removeSendStream(RTPSessionMgr.java:1627)
     [java] at com.sun.media.rtp.SendSSRCInfo.close(SendSSRCInfo.java:254)
     [java] at net.java.sip.communicator.impl.neomedia.MediaStreamImpl.stopSendStreams(MediaStreamImpl.java:1896)
     [java] at net.java.sip.communicator.impl.neomedia.MediaStreamImpl.stopSendStreams(MediaStreamImpl.java:1858)
     [java] at net.java.sip.communicator.impl.neomedia.MediaStreamImpl.closeSendStreams(MediaStreamImpl.java:543)
     [java] at net.java.sip.communicator.impl.neomedia.MediaStreamImpl.close(MediaStreamImpl.java:505)
     [java] at net.java.sip.communicator.impl.neomedia.AudioMediaStreamImpl.close(AudioMediaStreamImpl.java:418)
     [java] at net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.setAudioStream(CallPeerMediaHandler.java:746)
     [java] at net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.closeStream(CallPeerMediaHandler.java:390)
     [java] at net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.close(CallPeerMediaHandler.java:375)
     [java] at net.java.sip.communicator.service.protocol.media.MediaAwareCallPeer.setState(MediaAwareCallPeer.java:523)
     [java] at net.java.sip.communicator.service.protocol.media.MediaAwareCallPeer.setState(MediaAwareCallPeer.java:495)
     [java] at net.java.sip.communicator.impl.protocol.sip.CallPeerSipImpl.setDisconnectedState(CallPeerSipImpl.java:1325)
     [java] at net.java.sip.communicator.impl.protocol.sip.CallPeerSipImpl.hangup(CallPeerSipImpl.java:745)
     [java] at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.hangupCallPeer(OperationSetBasicTelephonySipImpl.java:1516)
     [java] at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.hangupCallPeer(OperationSetBasicTelephonySipImpl.java:1493)
     [java] at net.java.sip.communicator.impl.gui.main.call.CallManager$HangupCallThread.run(CallManager.java:1299)
     [java] 18:46:47.663 SCHWERWIEGEND: util.UtilActivator.uncaughtException().81 An uncaught exception occurred in thread=Thread[Thread-1352,6,main] and
message was: null
     [java] java.lang.NullPointerException
     [java] at com.sun.media.rtp.RTCPTransmitter.bye(RTCPTransmitter.java:119)
     [java] at com.sun.media.rtp.RTCPReporter.releasessrc(RTCPReporter.java:137)
     [java] at com.sun.media.rtp.RTCPReporter.close(RTCPReporter.java:132)
     [java] at com.sun.media.rtp.RTPSessionMgr.stopParticipating(RTPSessionMgr.java:2492)
     [java] at com.sun.media.rtp.RTPSessionMgr.removeSendStream(RTPSessionMgr.java:1627)
     [java] at com.sun.media.rtp.SendSSRCInfo.close(SendSSRCInfo.java:254)
     [java] at com.sun.media.rtp.RTPSessionMgr.dispose(RTPSessionMgr.java:3107)
     [java] at net.java.sip.communicator.impl.neomedia.MediaStreamImpl.close(MediaStreamImpl.java:529)
     [java] at net.java.sip.communicator.impl.neomedia.AudioMediaStreamImpl.close(AudioMediaStreamImpl.java:418)
     [java] at net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.setAudioStream(CallPeerMediaHandler.java:746)
     [java] at net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.closeStream(CallPeerMediaHandler.java:390)
     [java] at net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.close(CallPeerMediaHandler.java:375)
     [java] at net.java.sip.communicator.service.protocol.media.MediaAwareCallPeer.setState(MediaAwareCallPeer.java:523)
     [java] at net.java.sip.communicator.service.protocol.media.MediaAwareCallPeer.setState(MediaAwareCallPeer.java:495)
     [java] at net.java.sip.communicator.impl.protocol.sip.CallPeerSipImpl.setDisconnectedState(CallPeerSipImpl.java:1325)
     [java] at net.java.sip.communicator.impl.protocol.sip.CallPeerSipImpl.hangup(CallPeerSipImpl.java:745)
     [java] at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.hangupCallPeer(OperationSetBasicTelephonySipImpl.java:1516)
     [java] at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.hangupCallPeer(OperationSetBasicTelephonySipImpl.java:1493)
     [java] at net.java.sip.communicator.impl.gui.main.call.CallManager$HangupCallThread.run(CallManager.java:1299)

···

Am 03.01.2011 19:24, schrieb Werner Dittmann:

Dear all,

testing with another SIP client (pjsua) I found some problems and
strange behaviour in conjunctions with RTP/SRTP

Attached is a wireshark file that shows the network activities.

The following call flow:

- pjsua (at address *.130) calls SC (at address *.1) and sends an INVITE
  offering several codecs

- SC answers with 200 OK, also offersing several codecs (2 in this case)
  (pjsua always reduces the number of codecs to one, for example if it
  receives an invite with several codes it send a 200 OK that contains
  only the one codec it selected).

- pjsua sends ACK but sends another INVITE immediately afte rthe ACK
  that contains only the one codec that pjsua selected.

- SC answers with 200 OK to this second invite

- pjsua sends ACK

In this case sometimes I don't hear pjsua audio, sometimes I hear it.
The attached files shows the second case also with a successful ZRTP
exchange. However, while the pjsua data is encrypted, the SC data is
not (I can deduct this from the RTP data pattern sent by SC). Thus
it seems that SC does seems to use 2 RTP sessions on the same port?
Could that happen because of the double invite (sort of re-invite) that
SC creates a second set of RTP session objects. This would explain that
sometimes I don't hear pjsip's audio.

To check this theory I reduced the number of codecs in SC to just
one so that SC offers only one codec in 200 OK. In this case pjsua
does not perform a second invite (because there was no reason to
reduce the number of codecs) and the RTP connection was ok, ZRTP
was ok and data was encrypted in both directions.

Can you have a look to this?

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

More info :slight_smile: :

Indeed the exceptions are related to the problem described below. The
exceptions happen if I hangup the call.

Regards,
Werner

···

Am 03.01.2011 19:34, schrieb Werner Dittmann:

Additional info:

During the tests I got the following exceptions. Maybe this helps to
locate the problem? I'm not sure if these exceptions are connected to
the problem I've reported in the previous mail.

Regards,
Werner

     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@498d1538
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@4d6c3541
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@1a6fc530
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicRendererModule@1ffadfdf
     [java] BasicRendererModule.doPrefetch:155 Render : true
     [java] BasicRenderModule.doPrefetch:159 Render : net.java.sip.communicator.impl.neomedia.jmfext.media.renderer.audio.PortAudioRenderer@5879ff89
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@5bbb8077
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@72ef33ad
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@7e4c974d
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@56618102
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@256ee01c
     [java] BasicTrackControl:prefetchTrack():96 2 bm = com.sun.media.BasicFilterModule@123b6177
     [java] 18:46:47.658 SCHWERWIEGEND: impl.neomedia.MediaStreamImpl.stopSendStreams().1911 Failed to close stream com.sun.media.rtp.SendSSRCInfo@23852c7f
     [java] java.lang.NullPointerException
     [java] at com.sun.media.rtp.RTCPTransmitter.bye(RTCPTransmitter.java:119)
     [java] at com.sun.media.rtp.RTCPReporter.releasessrc(RTCPReporter.java:137)
     [java] at com.sun.media.rtp.RTCPReporter.close(RTCPReporter.java:132)
     [java] at com.sun.media.rtp.RTPSessionMgr.stopParticipating(RTPSessionMgr.java:2492)
     [java] at com.sun.media.rtp.RTPSessionMgr.removeSendStream(RTPSessionMgr.java:1627)
     [java] at com.sun.media.rtp.SendSSRCInfo.close(SendSSRCInfo.java:254)
     [java] at net.java.sip.communicator.impl.neomedia.MediaStreamImpl.stopSendStreams(MediaStreamImpl.java:1896)
     [java] at net.java.sip.communicator.impl.neomedia.MediaStreamImpl.stopSendStreams(MediaStreamImpl.java:1858)
     [java] at net.java.sip.communicator.impl.neomedia.MediaStreamImpl.closeSendStreams(MediaStreamImpl.java:543)
     [java] at net.java.sip.communicator.impl.neomedia.MediaStreamImpl.close(MediaStreamImpl.java:505)
     [java] at net.java.sip.communicator.impl.neomedia.AudioMediaStreamImpl.close(AudioMediaStreamImpl.java:418)
     [java] at net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.setAudioStream(CallPeerMediaHandler.java:746)
     [java] at net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.closeStream(CallPeerMediaHandler.java:390)
     [java] at net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.close(CallPeerMediaHandler.java:375)
     [java] at net.java.sip.communicator.service.protocol.media.MediaAwareCallPeer.setState(MediaAwareCallPeer.java:523)
     [java] at net.java.sip.communicator.service.protocol.media.MediaAwareCallPeer.setState(MediaAwareCallPeer.java:495)
     [java] at net.java.sip.communicator.impl.protocol.sip.CallPeerSipImpl.setDisconnectedState(CallPeerSipImpl.java:1325)
     [java] at net.java.sip.communicator.impl.protocol.sip.CallPeerSipImpl.hangup(CallPeerSipImpl.java:745)
     [java] at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.hangupCallPeer(OperationSetBasicTelephonySipImpl.java:1516)
     [java] at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.hangupCallPeer(OperationSetBasicTelephonySipImpl.java:1493)
     [java] at net.java.sip.communicator.impl.gui.main.call.CallManager$HangupCallThread.run(CallManager.java:1299)
     [java] 18:46:47.663 SCHWERWIEGEND: util.UtilActivator.uncaughtException().81 An uncaught exception occurred in thread=Thread[Thread-1352,6,main] and
message was: null
     [java] java.lang.NullPointerException
     [java] at com.sun.media.rtp.RTCPTransmitter.bye(RTCPTransmitter.java:119)
     [java] at com.sun.media.rtp.RTCPReporter.releasessrc(RTCPReporter.java:137)
     [java] at com.sun.media.rtp.RTCPReporter.close(RTCPReporter.java:132)
     [java] at com.sun.media.rtp.RTPSessionMgr.stopParticipating(RTPSessionMgr.java:2492)
     [java] at com.sun.media.rtp.RTPSessionMgr.removeSendStream(RTPSessionMgr.java:1627)
     [java] at com.sun.media.rtp.SendSSRCInfo.close(SendSSRCInfo.java:254)
     [java] at com.sun.media.rtp.RTPSessionMgr.dispose(RTPSessionMgr.java:3107)
     [java] at net.java.sip.communicator.impl.neomedia.MediaStreamImpl.close(MediaStreamImpl.java:529)
     [java] at net.java.sip.communicator.impl.neomedia.AudioMediaStreamImpl.close(AudioMediaStreamImpl.java:418)
     [java] at net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.setAudioStream(CallPeerMediaHandler.java:746)
     [java] at net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.closeStream(CallPeerMediaHandler.java:390)
     [java] at net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.close(CallPeerMediaHandler.java:375)
     [java] at net.java.sip.communicator.service.protocol.media.MediaAwareCallPeer.setState(MediaAwareCallPeer.java:523)
     [java] at net.java.sip.communicator.service.protocol.media.MediaAwareCallPeer.setState(MediaAwareCallPeer.java:495)
     [java] at net.java.sip.communicator.impl.protocol.sip.CallPeerSipImpl.setDisconnectedState(CallPeerSipImpl.java:1325)
     [java] at net.java.sip.communicator.impl.protocol.sip.CallPeerSipImpl.hangup(CallPeerSipImpl.java:745)
     [java] at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.hangupCallPeer(OperationSetBasicTelephonySipImpl.java:1516)
     [java] at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.hangupCallPeer(OperationSetBasicTelephonySipImpl.java:1493)
     [java] at net.java.sip.communicator.impl.gui.main.call.CallManager$HangupCallThread.run(CallManager.java:1299)

Am 03.01.2011 19:24, schrieb Werner Dittmann:

Dear all,

testing with another SIP client (pjsua) I found some problems and
strange behaviour in conjunctions with RTP/SRTP

Attached is a wireshark file that shows the network activities.

The following call flow:

- pjsua (at address *.130) calls SC (at address *.1) and sends an INVITE
  offering several codecs

- SC answers with 200 OK, also offersing several codecs (2 in this case)
  (pjsua always reduces the number of codecs to one, for example if it
  receives an invite with several codes it send a 200 OK that contains
  only the one codec it selected).

- pjsua sends ACK but sends another INVITE immediately afte rthe ACK
  that contains only the one codec that pjsua selected.

- SC answers with 200 OK to this second invite

- pjsua sends ACK

In this case sometimes I don't hear pjsua audio, sometimes I hear it.
The attached files shows the second case also with a successful ZRTP
exchange. However, while the pjsua data is encrypted, the SC data is
not (I can deduct this from the RTP data pattern sent by SC). Thus
it seems that SC does seems to use 2 RTP sessions on the same port?
Could that happen because of the double invite (sort of re-invite) that
SC creates a second set of RTP session objects. This would explain that
sometimes I don't hear pjsip's audio.

To check this theory I reduced the number of codecs in SC to just
one so that SC offers only one codec in 200 OK. In this case pjsua
does not perform a second invite (because there was no reason to
reduce the number of codecs) and the RTP connection was ok, ZRTP
was ok and data was encrypted in both directions.

Can you have a look to this?

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi Werner,

these exceptions are caught, there is a big comment regarding the
exception, thanks to Lubomir.
It says something about not closing send streams on re-invites.
Have a look at : net.java.sip.communicator.impl.neomedia.MediaStreamImpl:1900.

Hope it helps
damencho

···

On Thu, Jan 6, 2011 at 12:51 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

More info :slight_smile: :

Indeed the exceptions are related to the problem described below. The
exceptions happen if I hangup the call.

Regards,
Werner

Am 03.01.2011 19:34, schrieb Werner Dittmann:

Additional info:

During the tests I got the following exceptions. Maybe this helps to
locate the problem? I'm not sure if these exceptions are connected to
the problem I've reported in the previous mail.

Regards,
Werner

 \[java\] BasicTrackControl:prefetchTrack\(\):96  2 bm =  com\.sun\.media\.BasicFilterModule@498d1538
 \[java\] BasicTrackControl:prefetchTrack\(\):96  2 bm =  com\.sun\.media\.BasicFilterModule@4d6c3541
 \[java\] BasicTrackControl:prefetchTrack\(\):96  2 bm =  com\.sun\.media\.BasicFilterModule@1a6fc530
 \[java\] BasicTrackControl:prefetchTrack\(\):96  2 bm =  com\.sun\.media\.BasicRendererModule@1ffadfdf
 \[java\] BasicRendererModule\.doPrefetch:155 Render : true
 \[java\] BasicRenderModule\.doPrefetch:159 Render : net\.java\.sip\.communicator\.impl\.neomedia\.jmfext\.media\.renderer\.audio\.PortAudioRenderer@5879ff89
 \[java\] BasicTrackControl:prefetchTrack\(\):96  2 bm =  com\.sun\.media\.BasicFilterModule@5bbb8077
 \[java\] BasicTrackControl:prefetchTrack\(\):96  2 bm =  com\.sun\.media\.BasicFilterModule@72ef33ad
 \[java\] BasicTrackControl:prefetchTrack\(\):96  2 bm =  com\.sun\.media\.BasicFilterModule@7e4c974d
 \[java\] BasicTrackControl:prefetchTrack\(\):96  2 bm =  com\.sun\.media\.BasicFilterModule@56618102
 \[java\] BasicTrackControl:prefetchTrack\(\):96  2 bm =  com\.sun\.media\.BasicFilterModule@256ee01c
 \[java\] BasicTrackControl:prefetchTrack\(\):96  2 bm =  com\.sun\.media\.BasicFilterModule@123b6177
 \[java\] 18:46:47\.658 SCHWERWIEGEND: impl\.neomedia\.MediaStreamImpl\.stopSendStreams\(\)\.1911 Failed to close stream com\.sun\.media\.rtp\.SendSSRCInfo@23852c7f
 \[java\] java\.lang\.NullPointerException
 \[java\]     at com\.sun\.media\.rtp\.RTCPTransmitter\.bye\(RTCPTransmitter\.java:119\)
 \[java\]     at com\.sun\.media\.rtp\.RTCPReporter\.releasessrc\(RTCPReporter\.java:137\)
 \[java\]     at com\.sun\.media\.rtp\.RTCPReporter\.close\(RTCPReporter\.java:132\)
 \[java\]     at com\.sun\.media\.rtp\.RTPSessionMgr\.stopParticipating\(RTPSessionMgr\.java:2492\)
 \[java\]     at com\.sun\.media\.rtp\.RTPSessionMgr\.removeSendStream\(RTPSessionMgr\.java:1627\)
 \[java\]     at com\.sun\.media\.rtp\.SendSSRCInfo\.close\(SendSSRCInfo\.java:254\)
 \[java\]     at net\.java\.sip\.communicator\.impl\.neomedia\.MediaStreamImpl\.stopSendStreams\(MediaStreamImpl\.java:1896\)
 \[java\]     at net\.java\.sip\.communicator\.impl\.neomedia\.MediaStreamImpl\.stopSendStreams\(MediaStreamImpl\.java:1858\)
 \[java\]     at net\.java\.sip\.communicator\.impl\.neomedia\.MediaStreamImpl\.closeSendStreams\(MediaStreamImpl\.java:543\)
 \[java\]     at net\.java\.sip\.communicator\.impl\.neomedia\.MediaStreamImpl\.close\(MediaStreamImpl\.java:505\)
 \[java\]     at net\.java\.sip\.communicator\.impl\.neomedia\.AudioMediaStreamImpl\.close\(AudioMediaStreamImpl\.java:418\)
 \[java\]     at net\.java\.sip\.communicator\.service\.protocol\.media\.CallPeerMediaHandler\.setAudioStream\(CallPeerMediaHandler\.java:746\)
 \[java\]     at net\.java\.sip\.communicator\.service\.protocol\.media\.CallPeerMediaHandler\.closeStream\(CallPeerMediaHandler\.java:390\)
 \[java\]     at net\.java\.sip\.communicator\.service\.protocol\.media\.CallPeerMediaHandler\.close\(CallPeerMediaHandler\.java:375\)
 \[java\]     at net\.java\.sip\.communicator\.service\.protocol\.media\.MediaAwareCallPeer\.setState\(MediaAwareCallPeer\.java:523\)
 \[java\]     at net\.java\.sip\.communicator\.service\.protocol\.media\.MediaAwareCallPeer\.setState\(MediaAwareCallPeer\.java:495\)
 \[java\]     at net\.java\.sip\.communicator\.impl\.protocol\.sip\.CallPeerSipImpl\.setDisconnectedState\(CallPeerSipImpl\.java:1325\)
 \[java\]     at net\.java\.sip\.communicator\.impl\.protocol\.sip\.CallPeerSipImpl\.hangup\(CallPeerSipImpl\.java:745\)
 \[java\]     at net\.java\.sip\.communicator\.impl\.protocol\.sip\.OperationSetBasicTelephonySipImpl\.hangupCallPeer\(OperationSetBasicTelephonySipImpl\.java:1516\)
 \[java\]     at net\.java\.sip\.communicator\.impl\.protocol\.sip\.OperationSetBasicTelephonySipImpl\.hangupCallPeer\(OperationSetBasicTelephonySipImpl\.java:1493\)
 \[java\]     at net\.java\.sip\.communicator\.impl\.gui\.main\.call\.CallManager$HangupCallThread\.run\(CallManager\.java:1299\)
 \[java\] 18:46:47\.663 SCHWERWIEGEND: util\.UtilActivator\.uncaughtException\(\)\.81 An uncaught exception occurred in thread=Thread\[Thread\-1352,6,main\] and

message was: null
[java] java.lang.NullPointerException
[java] at com.sun.media.rtp.RTCPTransmitter.bye(RTCPTransmitter.java:119)
[java] at com.sun.media.rtp.RTCPReporter.releasessrc(RTCPReporter.java:137)
[java] at com.sun.media.rtp.RTCPReporter.close(RTCPReporter.java:132)
[java] at com.sun.media.rtp.RTPSessionMgr.stopParticipating(RTPSessionMgr.java:2492)
[java] at com.sun.media.rtp.RTPSessionMgr.removeSendStream(RTPSessionMgr.java:1627)
[java] at com.sun.media.rtp.SendSSRCInfo.close(SendSSRCInfo.java:254)
[java] at com.sun.media.rtp.RTPSessionMgr.dispose(RTPSessionMgr.java:3107)
[java] at net.java.sip.communicator.impl.neomedia.MediaStreamImpl.close(MediaStreamImpl.java:529)
[java] at net.java.sip.communicator.impl.neomedia.AudioMediaStreamImpl.close(AudioMediaStreamImpl.java:418)
[java] at net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.setAudioStream(CallPeerMediaHandler.java:746)
[java] at net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.closeStream(CallPeerMediaHandler.java:390)
[java] at net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.close(CallPeerMediaHandler.java:375)
[java] at net.java.sip.communicator.service.protocol.media.MediaAwareCallPeer.setState(MediaAwareCallPeer.java:523)
[java] at net.java.sip.communicator.service.protocol.media.MediaAwareCallPeer.setState(MediaAwareCallPeer.java:495)
[java] at net.java.sip.communicator.impl.protocol.sip.CallPeerSipImpl.setDisconnectedState(CallPeerSipImpl.java:1325)
[java] at net.java.sip.communicator.impl.protocol.sip.CallPeerSipImpl.hangup(CallPeerSipImpl.java:745)
[java] at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.hangupCallPeer(OperationSetBasicTelephonySipImpl.java:1516)
[java] at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.hangupCallPeer(OperationSetBasicTelephonySipImpl.java:1493)
[java] at net.java.sip.communicator.impl.gui.main.call.CallManager$HangupCallThread.run(CallManager.java:1299)

Am 03.01.2011 19:24, schrieb Werner Dittmann:

Dear all,

testing with another SIP client (pjsua) I found some problems and
strange behaviour in conjunctions with RTP/SRTP

Attached is a wireshark file that shows the network activities.

The following call flow:

- pjsua (at address *.130) calls SC (at address *.1) and sends an INVITE
offering several codecs

- SC answers with 200 OK, also offersing several codecs (2 in this case)
(pjsua always reduces the number of codecs to one, for example if it
receives an invite with several codes it send a 200 OK that contains
only the one codec it selected).

- pjsua sends ACK but sends another INVITE immediately afte rthe ACK
that contains only the one codec that pjsua selected.

- SC answers with 200 OK to this second invite

- pjsua sends ACK

In this case sometimes I don't hear pjsua audio, sometimes I hear it.
The attached files shows the second case also with a successful ZRTP
exchange. However, while the pjsua data is encrypted, the SC data is
not (I can deduct this from the RTP data pattern sent by SC). Thus
it seems that SC does seems to use 2 RTP sessions on the same port?
Could that happen because of the double invite (sort of re-invite) that
SC creates a second set of RTP session objects. This would explain that
sometimes I don't hear pjsip's audio.

To check this theory I reduced the number of codecs in SC to just
one so that SC offers only one codec in 200 OK. In this case pjsua
does not perform a second invite (because there was no reason to
reduce the number of codecs) and the RTP connection was ok, ZRTP
was ok and data was encrypted in both directions.

Can you have a look to this?

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi damencho,

thanks for the hint. Sometime ago I saw this comment :slight_smile: .

Thus it seems that the reorganizing (close/open, etc) of
streams does not work correctly for such a RE-INVITE.

I can reproduce it but for my tests I have a work around
and limit the number of codecs in SC to one.

Regards,
Werner

···

Am 06.01.2011 12:08, schrieb Damian Minkov:

Hi Werner,

these exceptions are caught, there is a big comment regarding the
exception, thanks to Lubomir.
It says something about not closing send streams on re-invites.
Have a look at : net.java.sip.communicator.impl.neomedia.MediaStreamImpl:1900.

Hope it helps
damencho

On Thu, Jan 6, 2011 at 12:51 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

More info :slight_smile: :

Indeed the exceptions are related to the problem described below. The
exceptions happen if I hangup the call.

Regards,
Werner

Am 03.01.2011 19:34, schrieb Werner Dittmann:

Additional info:

SNIP ---- SNAP

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

All,

I've created an issue in the bugtracker for this:
issue # 897

Regards,
Werner

···

Am 06.01.2011 12:19, schrieb Werner Dittmann:

Hi damencho,

thanks for the hint. Sometime ago I saw this comment :slight_smile: .

Thus it seems that the reorganizing (close/open, etc) of
streams does not work correctly for such a RE-INVITE.

I can reproduce it but for my tests I have a work around
and limit the number of codecs in SC to one.

Regards,
Werner

Am 06.01.2011 12:08, schrieb Damian Minkov:

Hi Werner,

these exceptions are caught, there is a big comment regarding the
exception, thanks to Lubomir.
It says something about not closing send streams on re-invites.
Have a look at : net.java.sip.communicator.impl.neomedia.MediaStreamImpl:1900.

Hope it helps
damencho

SNIP ---- SNAP

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net