[SIPForum-discussion] Re: 回复： [SIPForum-discussion] DTMF RFC 2833........Westage of bandwidth

[santosh chintalwar]

Hay Mark,

If it will send three RTP packet then there is no problem....
But I used one UAC ( called KPhone ) which will send last DTMF digit untill
we dont send other one....
You can check with this Phone......

Santosh


On 9/12/07, mark lee <gogofly_lee at yahoo.com.cn> wrote:
>
> Hi,Santosh,
> Acctually one DTMF event is only embeded into one RTP packet,so it only
> wastes three RTP packets to retransmitted DTMF event three times.
>
> Mark
>
> *santosh chintalwar <sschintalwar at gmail.com>* 写道：
>
> Hi All,
>
> According to RFC 2833  of
>
>  3.6 Sending Event Packets
>
>     If an event continues for more than one period, the source generating
>    the events should send a new event packet with the RTP timestamp
>    value corresponding to the beginning of the event and the duration of
>    the event increased correspondingly. (The RTP sequence number is
>    incremented by one for each packet.) If there has been no new event
>      in the last interval, the event SHOULD be retransmitted three times
>      or until the next event is recognized. This ensures that the duration
>    of the event can be recognized correctly even if the last packet for
>    an event is lost.
>
>
> According to Highlight  is that mean we need to transmite whatever last
> DTMF digit send by the user ( or UAC ) ???
>
> If this is the case then we are wasting the badwidth by sending last
> event.... dont we???
>
> Any comment on this......????
>
> Thanks,
> Santosh
>
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>
>
> ------------------------------
> 雅虎邮箱，以安全著称，是值得信赖的邮箱专家！ <http://mail.yahoo.com.cn/?=89034>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20070913/133ec244/attachment-0002.html>