Ok, that's what I guessed. I've never really tested such setup with SSRC changing in the middle of a stream. *Probably* it will become better after I check in multicast stuff I'm working on now, as it also includes changes to unicast SSRC handling. But for now you should look into MprFromNet::pushPacket() and see what's wrong there.
On Tue, Oct 28, 2008 at 9:00 PM, Paulo Vicentini <[EMAIL PROTECTED]> wrote: > Indeed there is two SSRC from remote endpoint (141) > > SSRC=0x4DC75BA4 > > SSRC=0x788E0349 > > sipxtapi could be having problem in handle them... > > On Tue, Oct 28, 2008 at 1:39 PM, Paulo Vicentini <[EMAIL PROTECTED]> > wrote: >> >> Earlier capture was cut off.... >> >> A new one is attached. >> >> br >> >> On Tue, Oct 28, 2008 at 1:27 PM, Paulo Vicentini >> <[EMAIL PROTECTED]> wrote: >>> >>> Hi >>> >>> Following is attached capture >>> >>> (192.168.15.100 is sipxtapi EP) >>> >>> br >>> On Tue, Oct 28, 2008 at 11:27 AM, stipus <[EMAIL PROTECTED]> wrote: >>>> >>>> As long as you didn't use Wireshark to capture and replay the RTP, you >>>> can't be sure that this RTP doesn't contain silence…. >>>> >>>> >>>> >>>> It's a 10 minute test (time to download and install wireshark and >>>> capture a few packets), and then you can be sure if it's a problem within >>>> sipxtapi or not. >>>> >>>> >>>> >>>> stipus >>>> >>>> >>>> >>>> >>>> >>>> De : [EMAIL PROTECTED] >>>> [mailto:[EMAIL PROTECTED] De la part de Paulo >>>> Vicentini >>>> Envoyé : mardi 28 octobre 2008 14:52 >>>> >>>> À : [email protected] >>>> Objet : Re: [sipxtapi-dev] stop to playback decoded RTP >>>> >>>> >>>> >>>> Hi, >>>> After the end of the announcement, valid RTP packets are entering thru >>>> NetInTask (get1Msg) and apparently they are pushed to the queue, so that it >>>> is not a network issue. >>>> >>>> The strange thing, although I can't hear anything from remote, is that >>>> SpkrThread still receives messages from Queue (pMsg = 0x00bc12b8 >>>> {mpData1=957 mpData2=1430840 }) and waveOutWrite is being called without >>>> error ( returning 0) >>>> >>>> tks >>>> >>>> Paulo >>>> >>>> >>>> >>>> On Mon, Oct 27, 2008 at 6:44 PM, stipus <[EMAIL PROTECTED]> wrote: >>>> >>>> You can use Wireshark to capture all IP packets, and then decode & play >>>> received and sent RTP (if it's in one of the supported formats – only G711 >>>> as far as I know). >>>> >>>> >>>> >>>> You can access the RTP replay feature from the wireshark statistics / >>>> VOIP calls menu. >>>> >>>> >>>> >>>> stipus >>>> >>>> >>>> >>>> De : [EMAIL PROTECTED] >>>> [mailto:[EMAIL PROTECTED] De la part de Paulo >>>> Vicentini >>>> Envoyé : lundi 27 octobre 2008 20:53 >>>> À : [email protected] >>>> Objet : [sipxtapi-dev] stop to playback decoded RTP >>>> >>>> >>>> >>>> I am facing a problem in a specific scenario: >>>> >>>> sipxtapiEP----------------media server plays >>>> message-------------------EP (several kinds) >>>> >>>> (both EPs are able to hear the message) >>>> >>>> sipxtapiEP(can't hear other EP ) ------------(message is >>>> over)------------------EP (is able to hear sipxtapiEP) >>>> >>>> Whenever an ingoing / outgoing call is intercepted by a media server >>>> that plays a message (e.g announcement / collect call message) before >>>> bridging between the finals endpoints I have the following problem: >>>> While playing the message both endpoints are able to hear the message >>>> but after all the message is played, sipxtapi EP is mute (can't hear other >>>> end EP), although it is able to send / receive RTP. >>>> The other end is able to hear (audio voice) sipxtapi EP after message is >>>> played. >>>> SDP session description remains the same by the end of the announcements >>>> (no re-invite). >>>> Without a media server (announcement) in mid of the call all is fine >>>> (receive / make). >>>> >>>> I do check NetInTask / MprFromNet and I saw that RTP packets are still >>>> been pushed after the end of the message. >>>> I will check Spk Task and others to see what's going on…but any help to >>>> figure out my issue is welcome. >>>> >>>> Thank you >>>> >>>> >>>> _______________________________________________ >>>> sipxtapi-dev mailing list >>>> [email protected] >>>> List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/ >>>> >>>> >>>> >>>> _______________________________________________ >>>> sipxtapi-dev mailing list >>>> [email protected] >>>> List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/ >>> >> > > > _______________________________________________ > sipxtapi-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/ > -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
