I certainly welcome and applaud your comments and suggestions. But I could not continue to push this issue as an asterisk "bug" since the RFC did not back me up. Absorbing these SIP INFO retransmissions is more like a common sense thing/feature that should be implemented in asterisk rather than an RFC violation, since the RFC is quite vague. If anybody has the knowledge to implement this feature I can certainly help test it.
Regards, Andres.
Jiri Kuthan wrote:
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
_______________________________________________ Serusers mailing list [EMAIL PROTECTED] http://mail.iptel.org/mailman/listinfo/serusers
-- 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
