[jitsi-issues] [JIRA] Commented: (JITSI-897) Problems if another SIP client sends a "double INVITE" (re-invite)

emcho (JIRA) jira-no-reply at java.net
Mon Jan 14 13:40:53 CET 2013


    [ http://java.net/jira/browse/JITSI-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353364#action_353364 ] 

emcho commented on JITSI-897:
-----------------------------

This should be better now with r10262. Could you please test and let us know if this works better for you?

> Problems if another SIP client sends a "double INVITE" (re-invite)
> ------------------------------------------------------------------
>
>                 Key: JITSI-897
>                 URL: http://java.net/jira/browse/JITSI-897
>             Project: jitsi
>          Issue Type: Bug
>          Components: development
>    Affects Versions: future
>         Environment: Operating System: All
> Platform: All
>            Reporter: wernerd
>            Assignee: jitsi-issues
>            Priority: Critical
>             Fix For: 2.0
>
>         Attachments: double-invite1.pcap.tar.gz
>
>
> 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.
> Following exceptions were thrown:
>      [java] BasicTrackControl:prefetchTrack():96  2 bm = 
> com.sun.media.BasicFilterModule at 498d1538
>      [java] BasicTrackControl:prefetchTrack():96  2 bm = 
> com.sun.media.BasicFilterModule at 4d6c3541
>      [java] BasicTrackControl:prefetchTrack():96  2 bm = 
> com.sun.media.BasicFilterModule at 1a6fc530
>      [java] BasicTrackControl:prefetchTrack():96  2 bm = 
> com.sun.media.BasicRendererModule at 1ffadfdf
>      [java] BasicRendererModule.doPrefetch:155 Render : true
>      [java] BasicRenderModule.doPrefetch:159 Render :
> net.java.sip.communicator.impl.neomedia.jmfext.media.renderer.audio.PortAudioRenderer at 5879ff89
>      [java] BasicTrackControl:prefetchTrack():96  2 bm = 
> com.sun.media.BasicFilterModule at 5bbb8077
>      [java] BasicTrackControl:prefetchTrack():96  2 bm = 
> com.sun.media.BasicFilterModule at 72ef33ad
>      [java] BasicTrackControl:prefetchTrack():96  2 bm = 
> com.sun.media.BasicFilterModule at 7e4c974d
>      [java] BasicTrackControl:prefetchTrack():96  2 bm = 
> com.sun.media.BasicFilterModule at 56618102
>      [java] BasicTrackControl:prefetchTrack():96  2 bm = 
> com.sun.media.BasicFilterModule at 256ee01c
>      [java] BasicTrackControl:prefetchTrack():96  2 bm = 
> com.sun.media.BasicFilterModule at 123b6177
>      [java] 18:46:47.658 SCHWERWIEGEND:
> impl.neomedia.MediaStreamImpl.stopSendStreams().1911 Failed to close stream
> com.sun.media.rtp.SendSSRCInfo at 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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        




More information about the issues mailing list