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 <[email protected]>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:[email protected]: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:[email protected]: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: [email protected] [mailto:[email protected]]
> On Behalf Of Alexander Chemeris
> Sent: Thursday, July 09, 2009 3:25 PM
> To: Lavigne, Andrew (CAR:PC00)
> Cc: [email protected]
> 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<[email protected]> 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
> > [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/
>
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
