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

[Jiri Kuthan]

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
> >>>>>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
> >>
> >>
> >>
> >_______________________________________________
> >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
> >
> >
> >
> _______________________________________________
> 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
>