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

[Andres]

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 lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>
>  
>


-- 
Andres
Network Admin
http://www.telesip.net