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

[Jiri Kuthan]

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
> >>>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
> >>
> >>
> >>
> >
> >_______________________________________________
> >Serusers mailing list
> >Serusers at iptel.org
> >http://mail.iptel.org/mailman/listinfo/serusers
> >
> >
> >
>
>
> --
> 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
>