Discussiion list for developers using and contributing to sipXtapi API hosted on sipfoundry.org ()

Andrew Lavigne | 9 Jul 2009 17:43

Input audio sometimes not connected properly

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 <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

headers

Alexander Chemeris | 9 Jul 2009 21:24

Re: 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<alavigne <at> 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 <at> 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 <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

headers

Alexander Chemeris | 9 Jul 2009 23:07

Re: Support for specifying port to use for RTP stream?

Hi Andrew,

If you still need this, I'd be happy to help you understand how to implement
this functionality. But I'd ask you to provide a clean patch back to us, so
we can check it in.

On Fri, Jun 19, 2009 at 4:22 PM, Andrew Lavigne<alavigne <at> nortel.com> wrote:
> Hi, Paulo
>
> When you say "on the fly", I'm going to assume you mean "at the start of
> each call" (and not during a call).
>
> Anyway, I do indeed need to specify the RTP port at the start of each call
> (because for each call, I want to direct the RTP stream to a port that I
> already know about).
>
> Now, as we talked about already, using the RTP start address might suffice
> -- we'll see.     However, regarding your statement that contains your
> comment about 'needing to provide such functionality':  If I was to go down
> that route, do you have any suggestions on the nature of the change required
> to do this?  (i.e. what source would I need to modify, etc)?
>
> ...Andrew
> ________________________________
> From: Paulo Vicentini [mailto:vicentini.paulo <at> gmail.com]
> Sent: Thursday, June 18, 2009 3:18 PM
> To: Lavigne, Andrew (CAR:PC00)
> Cc: sipxtapi-dev <at> list.sipfoundry.org
> Subject: Re: [sipxtapi-dev] Support for specifying port to use for RTP
> stream?
>
> Hi,
> you might specify the udp port to use during initialization time with that
> function.
> Such port would be used on SDP.
>
> Do you need to change/set  RTP port on the fly per call basis?
> If so, I think you need to provide such functionality
> regards
> Paulo
> On Thu, Jun 18, 2009 at 2:47 PM, Andrew Lavigne <alavigne <at> nortel.com> wrote:
>>
>> Hi, Paulo
>>
>> Yes, I've noticed that field.  But that just specifies the start of the
>> range from which sipxtapi will start automatically allocating ports, no?
>>
>> I suppose I could specify a new rtp start port each time I create a new
>> call.  Is that what you are implying?
>>
>> ...Andrew
>> ________________________________
>> From: Paulo Vicentini [mailto:vicentini.paulo <at> gmail.com]
>> Sent: Thursday, June 18, 2009 1:45 PM
>> To: Lavigne, Andrew (CAR:PC00)
>> Cc: sipxtapi-dev <at> list.sipfoundry.org
>> Subject: Re: [sipxtapi-dev] Support for specifying port to use for RTP
>> stream?
>>
>> Hi,
>> what about:
>> SIPXTAPI_API SIPX_RESULT sipxInitialize(SIPX_INST* phInst,
>>   const int udpPort = DEFAULT_UDP_PORT,
>>   const int tcpPort = DEFAULT_TCP_PORT,
>>   const int tlsPort = DEFAULT_TLS_PORT,
>>   const int rtpPortStart = DEFAULT_RTP_START_PORT,
>>   const int maxConnections = DEFAULT_CONNECTIONS,
>>   const char* szIdentity = DEFAULT_IDENTITY,
>>   const char* szBindToAddr = DEFAULT_BIND_ADDRESS,
>>   bool bUseSequentialPorts = false,
>>   const char* szTLSCertificateNickname = NULL,
>>   const char* szTLSCertificatePassword = NULL,
>>   const char* szDbLocation = NULL,
>>   bool bEnableLocalAudio = true) ;
>> you might set rtpPortStart
>> Regards
>> Paulo
>>
>>
>> On Thu, Jun 18, 2009 at 9:56 AM, Andrew Lavigne <alavigne <at> nortel.com>
>> wrote:
>>>
>>> Hi, All
>>>
>>> I'm using sipxtapi to initiate SIP calls.   I need to be able to connect
>>> the RTP packet stream associated with this SIP call (my side of the call,
>>> the client side) to a port of my choosing.  At SIP call setup time, I
>>> already know what port I need to use.   Therefore, I need to somehow tell
>>> sipxtapi that it should use this particular port as part of the SDP data it
>>> sends during the media negotiation phase of setting up a call.  I don't want
>>> sipxtapi to pick a port for me.  I've looked and haven't yet located any
>>> part of the API that would permit me to do this.
>>>
>>> I've also looked through the archives of this mailing list and did come
>>> across one posting a couple of years ago (which outlines a problem similar
>>> to mine).  A reply to that posting hinted that support for this did not
>>> exist.  Can anyone comment on whether there is support for this sort of
>>> thing now, and if not, perhaps a bit more detail on the "will require
>>> changes in underlying libs" that is mentioned?
>>>
>>> Many thanks in advance,
>>> …Andrew
>>> alavigne <at> nortel.com
>>>
>>> ----- quoted message -----
>>>
>>> Re: [sipxtapi-dev] Down and dirty RTP-SIP
>>>
>>> Alexander Chemeris
>>> Sun, 22 Jul 2007 11:57:17 -0700
>>>
>>> Hello,
>>>
>>> On 7/22/07, Brett Dawson <[EMAIL PROTECTED]> wrote:
>>> > I've got an RTP stream from an external device that I can send wherever
>>> > I
>>> > need to.  What is the easiest way to get that RTP stream to a connected
>>> > SIP
>>> > call using the SipxTapi?
>>>
>>> There is no API in sipXtapi to do this. It is implementable, but will
>>> require
>>> changes in underlying libs (sipXtackLib and so).
>>>
>>> Do you need your client to be RTP proxy or you may just mention
>>> this stream in SDP?
>>>
>>> ----- end quoted message -----
>>>
>>> _______________________________________________
>>> sipxtapi-dev mailing list
>>> sipxtapi-dev <at> list.sipfoundry.org
>>> List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
>>
>
>
> _______________________________________________
> sipxtapi-dev mailing list
> sipxtapi-dev <at> 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 <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

headers

Andrew Lavigne | 10 Jul 2009 15:05

Re: Support for specifying port to use for RTP stream?

Hi.

In the intervening time from when I posted that request, I've come to the conclusion that the better for me to
do this is to add a new audio connection into the flow graph associated with my call, and point my external
RTP stream to the sockets of that connection, thereby merging the audio from the external source into my
call.  That way I can still insert signalling tones, etc. 

I've therefore parked the idea of RTP streams that totally bypass sipx.  

I will still keep it in mind, but for now that's on hold.  And, I thank you for your offer.

Thanks,
...Andrew

-----Original Message-----
From: alexander.chemeris <at> gmail.com [mailto:alexander.chemeris <at> gmail.com] On Behalf Of Alexander Chemeris
Sent: Thursday, July 09, 2009 5:08 PM
To: Lavigne, Andrew (CAR:PC00)
Cc: Paulo Vicentini; sipxtapi-dev <at> list.sipfoundry.org
Subject: Re: [sipxtapi-dev] Support for specifying port to use for RTP stream?

Hi Andrew,

If you still need this, I'd be happy to help you understand how to implement this functionality. But I'd ask
you to provide a clean patch back to us, so we can check it in.

On Fri, Jun 19, 2009 at 4:22 PM, Andrew Lavigne<alavigne <at> nortel.com> wrote:
> Hi, Paulo
>
> When you say "on the fly", I'm going to assume you mean "at the start 
> of each call" (and not during a call).
>
> Anyway, I do indeed need to specify the RTP port at the start of each 
> call (because for each call, I want to direct the RTP stream to a port 
> that I already know about).
>
> Now, as we talked about already, using the RTP start address might 
> suffice
> -- we'll see.     However, regarding your statement that contains your 
> comment about 'needing to provide such functionality':  If I was to go 
> down that route, do you have any suggestions on the nature of the 
> change required to do this?  (i.e. what source would I need to modify, etc)?
>
> ...Andrew
> ________________________________
> From: Paulo Vicentini [mailto:vicentini.paulo <at> gmail.com]
> Sent: Thursday, June 18, 2009 3:18 PM
> To: Lavigne, Andrew (CAR:PC00)
> Cc: sipxtapi-dev <at> list.sipfoundry.org
> Subject: Re: [sipxtapi-dev] Support for specifying port to use for RTP 
> stream?
>
> Hi,
> you might specify the udp port to use during initialization time with 
> that function.
> Such port would be used on SDP.
>
> Do you need to change/set  RTP port on the fly per call basis?
> If so, I think you need to provide such functionality regards Paulo On 
> Thu, Jun 18, 2009 at 2:47 PM, Andrew Lavigne <alavigne <at> nortel.com> wrote:
>>
>> Hi, Paulo
>>
>> Yes, I've noticed that field.  But that just specifies the start of 
>> the range from which sipxtapi will start automatically allocating ports, no?
>>
>> I suppose I could specify a new rtp start port each time I create a 
>> new call.  Is that what you are implying?
>>
>> ...Andrew
>> ________________________________
>> From: Paulo Vicentini [mailto:vicentini.paulo <at> gmail.com]
>> Sent: Thursday, June 18, 2009 1:45 PM
>> To: Lavigne, Andrew (CAR:PC00)
>> Cc: sipxtapi-dev <at> list.sipfoundry.org
>> Subject: Re: [sipxtapi-dev] Support for specifying port to use for 
>> RTP stream?
>>
>> Hi,
>> what about:
>> SIPXTAPI_API SIPX_RESULT sipxInitialize(SIPX_INST* phInst,
>>   const int udpPort = DEFAULT_UDP_PORT,
>>   const int tcpPort = DEFAULT_TCP_PORT,
>>   const int tlsPort = DEFAULT_TLS_PORT,
>>   const int rtpPortStart = DEFAULT_RTP_START_PORT,
>>   const int maxConnections = DEFAULT_CONNECTIONS,
>>   const char* szIdentity = DEFAULT_IDENTITY,
>>   const char* szBindToAddr = DEFAULT_BIND_ADDRESS,
>>   bool bUseSequentialPorts = false,
>>   const char* szTLSCertificateNickname = NULL,
>>   const char* szTLSCertificatePassword = NULL,
>>   const char* szDbLocation = NULL,
>>   bool bEnableLocalAudio = true) ;
>> you might set rtpPortStart
>> Regards
>> Paulo
>>
>>
>> On Thu, Jun 18, 2009 at 9:56 AM, Andrew Lavigne <alavigne <at> nortel.com>
>> wrote:
>>>
>>> Hi, All
>>>
>>> I'm using sipxtapi to initiate SIP calls.   I need to be able to 
>>> connect the RTP packet stream associated with this SIP call (my side 
>>> of the call, the client side) to a port of my choosing.  At SIP call 
>>> setup time, I already know what port I need to use.   Therefore, I 
>>> need to somehow tell sipxtapi that it should use this particular 
>>> port as part of the SDP data it sends during the media negotiation 
>>> phase of setting up a call.  I don't want sipxtapi to pick a port 
>>> for me.  I've looked and haven't yet located any part of the API that would permit me to do this.
>>>
>>> I've also looked through the archives of this mailing list and did 
>>> come across one posting a couple of years ago (which outlines a 
>>> problem similar to mine).  A reply to that posting hinted that 
>>> support for this did not exist.  Can anyone comment on whether there 
>>> is support for this sort of thing now, and if not, perhaps a bit 
>>> more detail on the "will require changes in underlying libs" that is mentioned?
>>>
>>> Many thanks in advance,
>>> ...Andrew
>>> alavigne <at> nortel.com
>>>
>>> ----- quoted message -----
>>>
>>> Re: [sipxtapi-dev] Down and dirty RTP-SIP
>>>
>>> Alexander Chemeris
>>> Sun, 22 Jul 2007 11:57:17 -0700
>>>
>>> Hello,
>>>
>>> On 7/22/07, Brett Dawson <[EMAIL PROTECTED]> wrote:
>>> > I've got an RTP stream from an external device that I can send 
>>> > wherever I need to.  What is the easiest way to get that RTP 
>>> > stream to a connected SIP call using the SipxTapi?
>>>
>>> There is no API in sipXtapi to do this. It is implementable, but 
>>> will require changes in underlying libs (sipXtackLib and so).
>>>
>>> Do you need your client to be RTP proxy or you may just mention this 
>>> stream in SDP?
>>>
>>> ----- end quoted message -----
>>>
>>> _______________________________________________
>>> sipxtapi-dev mailing list
>>> sipxtapi-dev <at> list.sipfoundry.org
>>> List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
>>
>
>
> _______________________________________________
> sipxtapi-dev mailing list
> sipxtapi-dev <at> 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 <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

headers

Paulo Vicentini | 10 Jul 2009 15:16

Re: Input audio sometimes not connected properly

Hi,

I have faced an issue related to RTP stream:

If the seq number and time of the received RTP packet is somehow reset ( while *ssrc* remains the *same*), playback is stopped

That seq/time's change in the same SSRC may mislead the media processing

For instance:
got SIP 183....
incoming RTPs :
SSRC=0xE2B0C9A5, Seq=231, Time=36960
SSRC=0xE2B0C9A5, Seq=232, Time=37120
SIP/SDP Status: 200 OK, with session description
SSRC=0xE2B0C9A5, Seq=0, Time=0, Mark==== => *audio processing fails*
SSRC=0xE2B0C9A5, Seq=1, Time=160
SSRC=0xE2B0C9A5, Seq=2, Time=320

Remote endpoint keeps SSRC but reset Seq / Time

We would need to detect that change in the stream and to perform as the very SSRC had changed

Paulo

On Thu, Jul 9, 2009 at 4:24 PM, Alexander Chemeris <Alexander.Chemeris <at> sipez.com> wrote:

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<alavigne <at> 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 <at> 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 <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

_______________________________________________
sipxtapi-dev mailing list
sipxtapi-dev <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

headers

Andrew Lavigne | 10 Jul 2009 15:51

Re: Input audio sometimes not connected properly

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

headers

Paulo Vicentini | 10 Jul 2009 17:23

Re: 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 <alavigne <at> 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_test <at> 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_test <at> 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.chemeris <at> gmail.com [mailto:alexander.chemeris <at> gmail.com] On Behalf Of Alexander Chemeris
Sent: Thursday, July 09, 2009 3:25 PM
To: Lavigne, Andrew (CAR:PC00)
Cc: sipxtapi-dev <at> 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<alavigne <at> 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 <at> 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 <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

_______________________________________________
sipxtapi-dev mailing list
sipxtapi-dev <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

headers

Andrew Lavigne | 10 Jul 2009 19:25

Re: Input audio sometimes not connected properly

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.paulo <at> gmail.com]
Sent: Friday, July 10, 2009 11:24 AM
To: Lavigne, Andrew (CAR:PC00)
Cc: Alexander Chemeris; sipxtapi-dev <at> 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 <alavigne <at> 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_test <at> 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_test <at> 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.chemeris <at> gmail.com [mailto:alexander.chemeris <at> gmail.com] On Behalf Of Alexander Chemeris
Sent: Thursday, July 09, 2009 3:25 PM
To: Lavigne, Andrew (CAR:PC00)
Cc: sipxtapi-dev <at> 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<alavigne <at> 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 <at> 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 <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

_______________________________________________
sipxtapi-dev mailing list
sipxtapi-dev <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

headers

Keith Kyzivat | 10 Jul 2009 19:28

Re: Input audio sometimes not connected properly

Try using the mainline -- that has the most up to date code.

On Fri, Jul 10, 2009 at 1:25 PM, Andrew Lavigne <alavigne <at> nortel.com> wrote:

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.paulo <at> gmail.com]
Sent: Friday, July 10, 2009 11:24 AM

To: Lavigne, Andrew (CAR:PC00)

Cc: Alexander Chemeris; sipxtapi-dev <at> 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 <alavigne <at> 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_test <at> 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_test <at> 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.chemeris <at> gmail.com [mailto:alexander.chemeris <at> gmail.com] On Behalf Of Alexander Chemeris
Sent: Thursday, July 09, 2009 3:25 PM
To: Lavigne, Andrew (CAR:PC00)
Cc: sipxtapi-dev <at> 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<alavigne <at> 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 <at> 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 <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

_______________________________________________
sipxtapi-dev mailing list
sipxtapi-dev <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

_______________________________________________
sipxtapi-dev mailing list
sipxtapi-dev <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

headers

Andrew Lavigne | 10 Jul 2009 19:43

Re: Input audio sometimes not connected properly

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.paulo <at> gmail.com]
Sent: Friday, July 10, 2009 11:24 AM
To: Lavigne, Andrew (CAR:PC00)
Cc: Alexander Chemeris; sipxtapi-dev <at> 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 <alavigne <at> 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_test <at> 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_test <at> 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.chemeris <at> gmail.com [mailto:alexander.chemeris <at> gmail.com] On Behalf Of Alexander Chemeris
Sent: Thursday, July 09, 2009 3:25 PM
To: Lavigne, Andrew (CAR:PC00)
Cc: sipxtapi-dev <at> 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<alavigne <at> 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 <at> 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 <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

_______________________________________________
sipxtapi-dev mailing list
sipxtapi-dev <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

4	June 2010
4	February 2010
4	January 2010
8	December 2009
18	November 2009
2	October 2009
16	September 2009
6	August 2009
32	July 2009
18	June 2009
22	May 2009
3	April 2009
8	March 2009
29	February 2009
8	January 2009
42	December 2008
40	November 2008
77	October 2008
41	September 2008
14	August 2008
14	July 2008
16	June 2008
10	May 2008
31	April 2008
29	March 2008
59	February 2008
54	January 2008
38	December 2007
12	November 2007
45	October 2007
72	September 2007
78	August 2007
269	July 2007
162	June 2007
182	May 2007
80	April 2007
245	March 2007
161	February 2007
62	January 2007
111	December 2006
137	November 2006
84	October 2006
196	September 2006
192	August 2006

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31