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/
