Re: problem while reducing the seding rate

The way I usually track RFC2833 packets is by intercepting them prior to 
queue, handling them as they arrive and dropping them there, by 
overriding onRTPPacketRecv.  I also do soft processing for dropping 
"silent" packets when the gateway is unable to do this for me as well.

bool RTPStream::onRTPPacketRecv(IncomingRTPPkt &pkt)
{
         Event event;
         struct dtmf2833 *evt;
         unsigned pid = Driver::sip.getDTMFPayload();
         AudioCodec *codec;
         Level level;

         // this is where we test for 2833!!!

         if(!pid || pid != pkt.getPayloadType())
                 goto check2;

         evt = (struct dtmf2833 *)pkt.getPayload();

         if(evt->event != lastevt)
                 goto post;

         if(tonecount)
                 goto checkbit;

         if(evt->ebit)
                 goto checkbit;

post:
         lastevt = evt->event;

         memset(&event, 0, sizeof(event));
         switch(evt->event)
         {
         case 0:
         case 1:
         case 2:
         case 3:
         case 4:
         case 5:
         case 6:
         case 7:
         case 8:
         case 9:
         case 10:
         case 11:
         case 12:
        case 13:
         case 14:
         case 15:
                 event.id = DTMF_KEYUP;
                 event.dtmf.digit = evt->event;
                 event.dtmf.duration = 60;
                 break;
         case 16:
                 event.id = LINE_PICKUP;
                 break;
         default:
                 return false;
         }
         if(session->postEvent(&event))
         {
                 setSource(NULL);
                 setSink(NULL);
                 setTone(NULL);
         }

checkbit:
         if(evt->ebit && tonecount && stopid != MSGPORT_WAKEUP)
         {
                 memset(&event, 0, sizeof(event));
                 event.id = stopid;
                 stopid = MSGPORT_WAKEUP;
                 session->postEvent(&event);
                 tonecount = 0;
         }
         else if(evt->ebit)
                 tonecount = 0;
         else
                 tonecount = 3;
         return false;

check2:
         lastevt = 256;

         if(pkt.getPayloadType() != Driver::sip.getDataPayload())
                 return false;

         if(sink)
                 goto silence;

         if(Driver::sip.getDTMFInband())
                 goto silence;

         return false;

silence:
         level = Driver::sip.silence;
         codec = session->codec;
         if(!level || !codec)
                 return true;

	if(codec->isSilent(level, (void *)pkt.getRawPacket(), 
Driver::sip.info.framecount))
                 return false;

         return true;
}




Michel de Boer wrote:
> Hi Dinil,
> 
> This sounds like the problem that I had with sending RTP DTMF events.
> All RTP packets in this case have the same timestamp and ccRTP
> discards packets when the timestamp gets too old.
> 
> In your case you increase the PERIOD, but it seems that
> you keep the payload size of your packets the same. That means
> that the timestamps you provide with putData will not be in
> sync with the timestamp clock from ccRTP itself. The timestamp
> of your second packet indicates that this packet should come 50ms after
> the first packet. But you only deliver it 100ms after the first
> packet.
> 
> I think you have to deliver the data to ccRTP with the correct
> rate (depending on the number of samples per second). So if you
> want to double the period from 50 to 100 then you should also double
> the size of your payload.
> 
> Regards,
> Michel
> 
> 
> 
> Dinil Divakaran wrote:
> 
>>
>> Hi all,
>>
>> I was working on an example for transmitting an audio file using ccrtp 
>> (http://www.gnu.org/software/ccrtp/doc/refman/html/audiotx_8cpp-example.html) 
>>
>>
>> The following lines are from the above example. In this code, packets are
>> sent and then thread sleeps for a time of 'PERIOD' milliseconds. I 
>> changed
>> the value of PERIOD to 100 (milliseconds) and found that even though the
>> program says that the packets are sent; the packets weren't actually 
>> sent.
>> 'tcpdump' showed that only the first packet was sent; and thereafter only
>> RTCP packets were sent (with still lesser frequency). When I changed the
>> value of 'PERIOD' to 50, the packets were sent successfully.
>>
>> Can anyone please tell me where have I gone wrong ?
>>
>> -------------------------------------------------------------------------- 
>>
>>                               .
>>                               .
>>                               .
>>
>>         cout << "Transmitting " << PACKET_SIZE
>>              << " octects long packets "
>>              << "every " << PERIOD << " milliseconds..." << endl;
>>
>>         unsigned char buffer[PACKET_SIZE];
>>         int count=PACKET_SIZE;
>>
>>         // This will be useful for periodic execution
>>         TimerPort::setTimer(PERIOD);
>>
>>         setCancel(cancelImmediate);
>>         // This is the main loop, where packets are transmitted.
>>         for( int i = 0 ; (!sendingfile || count > 0) ; i++ ){
>>
>>             count = ::read(audioinput,buffer,PACKET_SIZE);
>>             if( count > 0 ){
>>                 // send an RTP packet, providing timestamp,
>>                 // payload type and payload.
>>                 socket->putData(PACKET_SIZE * i, buffer, PACKET_SIZE);
>>             }
>>             cout << "." << flush;
>>
>>             // Let's wait for the next cycle
>>             Thread::sleep(TimerPort::getTimer());
>>             TimerPort::incTimer(PERIOD);
>>         }
>>         cout << endl << "I have got no more data to send. " <<endl;
>>
>>                               .
>>                               .
>>                               .
>>                               .
>> -------------------------------------------------------------------------- 
>>
>>
>> - Dinil
>>
>>
>>
>> _______________________________________________
>> Ccrtp-devel mailing list
>> [email protected]
>> http://lists.gnu.org/mailman/listinfo/ccrtp-devel
>>
>>
> 
> 
> _______________________________________________
> Ccrtp-devel mailing list
> [email protected]
> http://lists.gnu.org/mailman/listinfo/ccrtp-devel

_______________________________________________
Ccrtp-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/ccrtp-devel

begin:vcard
fn:David Sugar
n:Sugar;David
org:GNU Telephony
adr:;;;;;;USA
email;internet:[email protected]
x-mozilla-html:FALSE
url:http://www.gnutelephony.org
version:2.1
end:vcard