Andres, thanks for your reply. I beg to disagree, here are the arguments: 1) Having INFO is imho a useful thing: it allows elements out of the media path to control DTMF-based service logic. Otherwise, you will end up processing media which affects bandwidth and latency noticably and does not scale. 2) Apart from the out-of-order argument, reprocessing retransmissions is a bug worth fixing. It is responsibility of transaction layer to absorb UDP retransmissions and never let app see them. (Similarly like TCP does not pass retranmissions to apps.) I think there are more cases for proper transaction processing other than just DTMF/INFO. 3) out-of-order delivery may or may not be an issue: gnerally, one would need to mainain a kind of playout buffer like for RTP. O-o-o delivery does not matter to me personaly since I send DTMF/INFO in stop-and-go mode. (BTW, I think the text in the RFC is not entirely correct, re-INIVITE should not cause CSeq gaps. Nevertheless, the RFC does not prevent anybody from implementing an "INFO playout buffer").
-jiri On Sun, 22 Feb 2004, Andres wrote: > Hi Jiri, > > Been there. We switched from INFO to RFC2833 for this same reason. > Take a look at: > http://bugs.digium.com/bug_view_page.php?bug_id=0001033 > > Not only retransmissions are affected but out of order packets too. > This behaviour can be partly blamed on the RFC: > > "In addition, the INFO method does not define additional mechanisms > for ensuring in-order delivery. While the CSeq header will be > incremented upon the transmission of new INFO messages, this should > not be used to determine the sequence of INFO information. This is > due to the fact that there could be gaps in the INFO message CSeq > count caused by a user agent sending re-INVITES or other SIP > messages. " > > Regards, > Andres > > > > Jiri Kuthan wrote: > > >I'm wondering whether people know if there could be a problem > >with * receiving retransmissions of INFO/DTMF requests. > > > >I'm trying to play DTMF via INFO to *. If it takes a 200 reply too > >long to come back, the request is retransmitted. Whenever this > >happens, the IVR down in PSTN reports that the number sequence > >is incorrect. > > > >This makes me guess that * turns INFO retransmissions into new > >DTMF digits on the PSTN part. > > > >Does anybody have the same experience? Is it a known problem? > >Are there any patches? > > > >Thanks, > > > >-jiri > > > >-- > >Jiri Kuthan http://iptel.org/~jiri/ > > > >_______________________________________________ > >Asterisk-Users mailing list > >[EMAIL PROTECTED] > >http://lists.digium.com/mailman/listinfo/asterisk-users > >To UNSUBSCRIBE or update options visit: > > http://lists.digium.com/mailman/listinfo/asterisk-users > > > > > > > > > -- > Andres > Network Admin > http://www.telesip.net > > > _______________________________________________ > Asterisk-Users mailing list > [EMAIL PROTECTED] > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users