[Asterisk-Users] INFO/DTMF retransmissions in * not absorbed?

[Jiri Kuthan]

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
> >Asterisk-Users at lists.digium.com
> >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
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>