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

[Clif Jones]

Gee, maybe I'm missing something, but the spec does not say that.  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)
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
>
>  
>