On Tue, 24 Feb 2004, Clif Jones wrote: > Gee, maybe I'm missing something, but the spec does not say that.
I copied&pasted the wording bellow from RFC3261. > The > RFC actually says that > when you send a final response, you are required to store that final > response for 64*T1 seconds > and retransmit the final response each time you receive the > retransmitted request. (T1 = 500ms) Sure. That's not mutualy exclusive. Absorbing a retransmissing means you don't pass it to application, that's the point. If you already sent a reply, it is perfectly valid to resend it. -jiri > Otherwise, you would be screwed if you you one and only final response > was lost in transit. :) > > Jiri Kuthan wrote: > > >Andres, > > > >the normative reference for abrorbing retranmissions is in RFC3261 -- > >INFO/RFC refers to it by telling "all transaction handling is like > >for BYE requests". This is the specific piece of text from RFC3261 > >which explains why not absorbing retransmissions breaks the spec. > > > >Cheeers, -jiri > > > >17.2.2 Non-INVITE Server Transaction > >... > >Once in the "Trying" state, any further request > > retransmissions are discarded. ... > > > >On Mon, 23 Feb 2004, Andres wrote: > > > > > > > >>Hi Jiri, > >> > >>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 > >> > >> > >> > >_______________________________________________ > >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 > _______________________________________________ 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
