Hi Andrew,
Thank you for reporting the bug.
I'll try to reproduce it, but it would be helpful if you post backtrace
of the crash.
On Sat, Jul 11, 2009 at 1:57 AM, Paulo
Vicentini<vicentini.pa...@gmail.com> wrote:
> to the list
>
> ---------- Forwarded message ----------
> From: Andrew Lavigne <alavi...@nortel.com>
> Date: Fri, Jul 10, 2009 at 6:13 PM
> Subject: RE: [sipxtapi-dev] Input audio sometimes not connected properly
> To: Paulo Vicentini <vicentini.pa...@gmail.com>, Keith Kyzivat
> <kam...@gmail.com>
>
>
> So, I've moved to the main branch. The good news is that my issue with the
> RTP stream changing and packets being dropped is now ok - the packets from
> the new stream (with a new SSRC) are now accepted. Many thanks for your
> replies - they pointed me in the right direction.
>
> The bad news is that I now seem to be getting an execption thrown when I try
> to set the audio input device to NONE, like so:
>
> sipxAudioSetCallInputDevice(g_hInst, "NONE");
>
> This was working fine in the 3.2 branch, but now it throws an exception
>
> "Unhandled exception at 0x10148c96 (sipXtapid.dll) in
> TelephonyIntegration.exe: 0xC0000005: Access violation reading location
> 0x0000001c."
>
> It would appear to be the following bit of code is where it encounters this
> in OsMsgPool::findFreeMsg(), on the NULL != mpMutex check.
>
> if (NULL != mpMutex)
> {
> mpMutex->acquire();
> }
>
> I'm not sure why this is happening now, but not before. Any clue as to why
> this is so? In any case, I will investigate....
>
> ...Andrew
>
> ________________________________
> From: Paulo Vicentini [mailto:vicentini.pa...@gmail.com]
> Sent: Friday, July 10, 2009 3:59 PM
> To: Keith Kyzivat
> Cc: Lavigne, Andrew (CAR:PC00); sipxtapi-dev@list.sipfoundry.org
> Subject: Re: [sipxtapi-dev] Input audio sometimes not connected properly
>
> Hi,
> SSRC changes will not be an issue for you in the main branch, but we should
> still address suddenly changes on TS and Seq (while SSRC keeps the same)
> Paulo
> On Fri, Jul 10, 2009 at 2:45 PM, Keith Kyzivat <kam...@gmail.com> wrote:
>>
>> Last I knew, you should not be too worried -- Alex has been trying to keep
>> it solid and stable, even with addition of new features.
>> On Fri, Jul 10, 2009 at 1:43 PM, Andrew Lavigne <alavi...@nortel.com>
>> wrote:
>>>
>>> Hi again.
>>>
>>> I checked out the latest main branch
>>> (http://scm.sipfoundry.org/rep/sipX/main) and I do see the methods you
>>> describe below. I had been using the 3.2 version because on the sipxtapi
>>> web page it says that the 3.2 branch is "Active, Stable; Receive only
>>> bugfixes", whereas the main branch says that the status is "Active". (and
>>> I wanted something stable and working)
>>>
>>> It would seem, however, that I need the latest functionality. I'm going
>>> to compile and try using the latest main version and see if this helps.
>>>
>>> Should I be concerned about stability if I use the latest on main?
>>>
>>> ...Andrew
>>>
>>> --- original message ---
>>>
>>>
>>> Hi, Paulo
>>>
>>> Thanks for replying.
>>>
>>> Interesting... I don't have these methods in my code base. Looks like
>>> maybe I'm not using the right / most recent load.
>>>
>>> This is my subversion URL:
>>>
>>> http://scm.sipfoundry.org/rep/sipX/branches/sipXtapi-3.2
>>>
>>> Should I be using something different?
>>>
>>> Thanks,
>>> ...Andrew
>>>
>>>
>>> ________________________________
>>> From: Paulo Vicentini [mailto:vicentini.pa...@gmail.com]
>>> Sent: Friday, July 10, 2009 11:24 AM
>>> To: Lavigne, Andrew (CAR:PC00)
>>> Cc: Alexander Chemeris; sipxtapi-dev@list.sipfoundry.org
>>> Subject: Re: [sipxtapi-dev] Input audio sometimes not connected properly
>>>
>>> Hi,
>>> Check if these functions below were called.
>>> if "SSRC id changes" - Then mediaLib should detect it (at least it used
>>> to work).
>>> I had an issue when SSRC remained the same while Seq and TimeStamp
>>> sudden changed.
>>>
>>>
>>> void MprRtpDispatcher::MpRtpStream::setSSRC(RtpSRC ssrc)
>>> {
>>> // Reset decoder if this is not the first time setSSRC() is called.
>>> // Note, that we deliberately does not check whether SSRC really
>>> changed.
>>> // We trust caller to perform this check. Furthermore some broken
>>> // implementations does not change SSRC on a new stream start.
>>> if (mAddress != 0 && mpDecode != NULL)
>>> {
>>> mpDecode->reset();
>>> }
>>>
>>> setValue(ssrc);
>>> }
>>>
>>> /**************************************************/
>>> UtlBoolean MprDecode::handleReset()
>>> {
>>> OsLock lock(mLock);
>>>
>>> // Reset JB, JBE and dejitter
>>> mpJB->reset();
>>> mpJbEstimationState->reset();
>>> if (mpMyDJ != NULL)
>>> {
>>> mpMyDJ->reset();
>>> }
>>>
>>> mIsStreamInitialized = FALSE;
>>> mNumPrevCodecs = 0;
>>>
>>> return TRUE;
>>> }
>>> Paulo
>>> On Fri, Jul 10, 2009 at 10:51 AM, Andrew Lavigne <alavi...@nortel.com>
>>> wrote:
>>>>
>>>> Hi, Alexander
>>>>
>>>> Thanks for your reply. Much appreciated. (and the other reply, too).
>>>>
>>>> Good to hear that the re-INVITE works for you. I've done a little
>>>> digging inside the code and it seems to me that something is getting
>>>> confused in the dejitter buffer (class MprDejitter in sipXmediaLib).
>>>>
>>>> During the re-INVITE scenario, the media gateway switches over to a new
>>>> RTP stream (it is sending me a PCMA RTP stream before the re-INVITE, then
>>>> switches to a PCMU RTP stream afterwards. The SIP exchange contains the
>>>> proper SDP negotiation for the new codec type).
>>>>
>>>> In the trace fragment below, 47.129.106.75 is my little test client, and
>>>> 47.135.211.232 is the media gateway that is hosting the audio conference.
>>>> You can see that the media gateway is sending PCMA RTP packets up until
>>>> the
>>>> time where it sends the SIP re-INVITE. My test client then replies with the
>>>> appropriate SIP messages. In the SDP data (which I've not included here)
>>>> associated with these SIP messages, a new port and new codec is negotiated
>>>> for the new RTP stream that will be sent by the media gateway after the
>>>> re-INVITE. Then, the media gateway starts sending packets along this new
>>>> RTP stream.
>>>>
>>>> So, here's the interesting point:
>>>>
>>>> The packet stream going from my client to the media gateway changes it's
>>>> codec from PCMA to PCMU, but the timestamp, sequence number maintain their
>>>> incrementing sequence, and SSRC id remains unchanged. However, for the
>>>> packet stream coming back from my media gateway, the timestamp and sequence
>>>> number are reset to new values, and the SSRC id changes. This is the part
>>>> that seems to trip up code in MprDejitter. In the method pullPacket(),
>>>> there's a check that compares an existing timestamp value with the
>>>> timestamp
>>>> value from a new packet. This check causes the code that retrieves the
>>>> packet to be bypassed, effectively causing the packet to be dropped. All
>>>> of
>>>> the packets from the point of switchover on get dropped because of this
>>>> (and
>>>> this is probably why I don't hear anything after this point).
>>>>
>>>> So, the question is this: is the media gateway doing something improper
>>>> by switching to a new SSRC id, and resetting sequence id and timestamp?
>>>> Or
>>>> is there something amiss with this bit of logic in pullPacket(). I'm not
>>>> familiar enough with the standards to know this is valid behavior or not.
>>>>
>>>>
>>>>
>>>> No. Time Source Destination
>>>> Protocol Info
>>>> 3494 24.633243000 47.129.106.75 47.135.211.232 RTP
>>>> PT=ITU-T G.711 PCMA, SSRC=0x4A5425E6, Seq=618, Time=885647077
>>>> 3495 24.651004000 47.135.211.232 47.129.106.75 RTP
>>>> PT=ITU-T G.711 PCMA, SSRC=0x95070000, Seq=2941, Time=3132451048
>>>> 3496 24.653266000 47.129.106.75 47.135.211.232 RTP
>>>> PT=ITU-T G.711 PCMA, SSRC=0x4A5425E6, Seq=619, Time=885647237
>>>> 3497 24.670539000 47.135.211.232 47.129.106.75 RTP
>>>> PT=ITU-T G.711 PCMA, SSRC=0x95070000, Seq=2942, Time=3132451208
>>>> 3498 24.673185000 47.129.106.75 47.135.211.232 RTP
>>>> PT=ITU-T G.711 PCMA, SSRC=0x4A5425E6, Seq=620, Time=885647397
>>>> 3500 24.691061000 47.135.211.232 47.129.106.75
>>>> SIP/SDP Request: INVITE sip:telephony_t...@47.129.106.75:6060, with
>>>> session
>>>> description
>>>> 3501 24.693107000 47.129.106.75 47.135.211.232 RTP
>>>> PT=ITU-T G.711 PCMA, SSRC=0x4A5425E6, Seq=621, Time=885647557
>>>> 3502 24.693878000 47.135.211.232 47.129.106.75 ICMP
>>>> Destination unreachable (Port unreachable)
>>>> 3503 24.695575000 47.129.106.75 47.135.211.232 SIP
>>>> Status: 100 Trying
>>>> 3504 24.699837000 47.129.106.75 47.135.211.232 RTP
>>>> Unknown RTP version 0
>>>> 3506 24.700186000 47.135.211.232 47.129.106.75 ICMP
>>>> Destination unreachable (Port unreachable)
>>>> 3508 24.707695000 47.129.106.75 47.135.211.232
>>>> SIP/SDP Status: 200 OK, with session description
>>>> 3509 24.713177000 47.129.106.75 47.135.211.232 RTP
>>>> PT=ITU-T G.711 PCMU, SSRC=0x4A5425E6, Seq=622, Time=885647717
>>>> 3510 24.713955000 47.135.211.232 47.129.106.75 ICMP
>>>> Destination unreachable (Port unreachable)
>>>> 3511 24.719948000 47.135.211.232 47.129.106.75 SIP
>>>> Request: ACK sip:telephony_t...@47.129.106.75:6060
>>>> 3512 24.733115000 47.129.106.75 47.135.211.232 RTP
>>>> PT=ITU-T G.711 PCMU, SSRC=0x4A5425E6, Seq=623, Time=885647877
>>>> 3521 24.753133000 47.129.106.75 47.135.211.232 RTP
>>>> PT=ITU-T G.711 PCMU, SSRC=0x4A5425E6, Seq=624, Time=885648037
>>>> 3522 24.758177000 47.135.211.232 47.129.106.75 RTP
>>>> PT=ITU-T G.711 PCMU, SSRC=0xE8E, Seq=22427, Time=26582
>>>> 3523 24.773143000 47.129.106.75 47.135.211.232 RTP
>>>> PT=ITU-T G.711 PCMU, SSRC=0x4A5425E6, Seq=625, Time=885648197
>>>> 3524 24.778966000 47.135.211.232 47.129.106.75 RTP
>>>> PT=ITU-T G.711 PCMU, SSRC=0xE8E, Seq=22428, Time=26742
>>>> [... Etc etc ... ]
>>>>
>>>> ...Andrew
>>>>
>>>> -----Original Message-----
>>>> From: alexander.cheme...@gmail.com [mailto:alexander.cheme...@gmail.com]
>>>> On Behalf Of Alexander Chemeris
>>>> Sent: Thursday, July 09, 2009 3:25 PM
>>>> To: Lavigne, Andrew (CAR:PC00)
>>>> Cc: sipxtapi-dev@list.sipfoundry.org
>>>> Subject: Re: [sipxtapi-dev] Input audio sometimes not connected properly
>>>>
>>>> Hi Andrew,
>>>>
>>>> We use sipXtapi a lot with our own Bridge (also sipXtapi-based), and it
>>>> works perfectly with re-INVITE. So, no, this issue is not known.
>>>> It would be helpful if you post here WireShark capture of the session
>>>> with the note when audio is lost. Then we'll be able to see what's going.
>>>>
>>>> Also I'd recommend to add a simple audio logging to a file to
>>>> MprDecode::doProcessFrame(). Just create a file, named after resource name
>>>> (getName()) and write all audio data from 'outBufs[0]'
>>>> right before "return TRUE". Then look into the file - what does it
>>>> contains.
>>>>
>>>> On Thu, Jul 9, 2009 at 7:43 PM, Andrew Lavigne<alavi...@nortel.com>
>>>> wrote:
>>>> > Hi, All
>>>> >
>>>> > I'm getting the sense that this list is not all that active. Still, I
>>>> > have a troublesome issue upon which I really really hope someone can
>>>> > give me some insight.
>>>> >
>>>> > Using a simple little client with Sipxtapi, I'm setting up a SIP call
>>>> > with an audio RTP stream to an audio conference bridge on a media
>>>> > gateway.
>>>> > Mostly, everything gets set up ok: The initial SIP Invite goes as
>>>> > expected, the initial RTP stream for setting up the conference works
>>>> > perfectly fine.
>>>> > Then, the media gateway sends my client a sip re-INVITE, along with a
>>>> > new SDP for the new audio stream that will be used for the actual
>>>> > conference.
>>>> > I'm looking at the SIP and RTP data in wireshark and everything gets
>>>> > set up perfectly...
>>>> >
>>>> > EXCEPT that most of the time, the RTP stream that comes back from the
>>>> > media gateway into sipxtapi seems to be improperly connected up. I
>>>> > see the proper RTP packets coming into sipxtapi, but I hear nothing in
>>>> > my speakers. Once in a blue moon, the issue does not manifest and I
>>>> > hear everything fine.
>>>> > Then I'll run it again and - poof - no audio can be heard (even though
>>>> > in wireshark I can clearly see it being sent from the media gateway
>>>> > into my app).
>>>> >
>>>> > It seems like something is not quite right down in the medialib
>>>> > somewhere - some sort of race condition or timing issue. Sometimes it
>>>> > works, sometimes it doesn't. I'm poking around, placing debug lines
>>>> > and breakpoints, trying to isolate the problem, but so far no luck.
>>>> > My questions to any experts out there are:
>>>> >
>>>> > 1) is there any sort of known issue like this in sipxmedialib? If so,
>>>> > is there some easy workaround?
>>>> > 2) any sort of hint as to where I'd look in order to verify if the RTP
>>>> > packets are getting mixed in properly into the Flow Graph? That would
>>>> > be helpful, too.
>>>> >
>>>> > 3) any other ideas that I have not yet thought of.
>>>> >
>>>> > Please, please... if anyone knowledgeable is out there reading this,
>>>> > could they please give me a few minutes of their time. I would be
>>>> > most appreciative. This bug (I'm going to call it a bug until proven
>>>> > otherwise) is really wasting a lot of my time.
>>>> >
>>>> > Many thanks x 100,
>>>> > ...Andrew Lavigne
>>>> >
>>>> > _______________________________________________
>>>> > sipxtapi-dev mailing list
>>>> > sipxtapi-dev@list.sipfoundry.org
>>>> > 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
>>>> sipxtapi-dev@list.sipfoundry.org
>>>> List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
>>>
>>>
>>> _______________________________________________
>>> sipxtapi-dev mailing list
>>> sipxtapi-dev@list.sipfoundry.org
>>> List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
>>
>
>
>
> _______________________________________________
> sipxtapi-dev mailing list
> sipxtapi-dev@list.sipfoundry.org
> 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
sipxtapi-dev@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
