[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    [Sip-implementors] RFC2833/4733: DTMF Event and constant 'Duration'-field (>0) confusion
From:       Eize Slange <eize.slange () gmail ! com>
Date:       2013-02-18 8:15:19
Message-ID: CAKu5E4Rb6+gfk+MUmKMrr-NVMkUFf38_8Yv0dCC8-FtOuAH--Q () mail ! gmail ! com
[Download RAW message or body]

Hello all,

We're currently in discussion about some RFC-2833 DTMF digit is sent in
correct way. The problem is caused by the "Duration"-field in the RFC2833
header. After reading RFC-2833 ($3.6 Sending Event Packets) and also
RFC-4733 (2.5.1.2 Transmission of Event Packets), we're still not able to
100% answer next question:

Is it allowed that the 'Duration'-field contains a fixed >0 value (e.g
1200) for the sent 6 packets (see also example below)? It is meant as an
'one event' happening.
I'm reading the specs (and examples) that is should increment, which I also
see happen with lots of other media endpoints.

See below the example of the packet
-----------------------------------
Sending "1" as single event (payloadType=101)...
(focus on the 'Duration'-field)

Time(ms) M-marker Seq TimeStamp Duration EventID E-marker
   0        1      1     0        1200     "1"      0
  20        0      2     0        1200     "1"      0
  40        0      3     0        1200     "1"      0
  60        0      4     0        1200     "1"      1
  80        0      5     0        1200     "1"      1
 100        0      6     0        1200     "1"      1

In my opinion, only the 'End'-marker packets are allowed to have fixed
Duration. So it should increment from low to 1200. This is also how it's
visible in the examples (of RFC4733).
Or is above example correct/valid?
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[prev in list] [next in list] [prev in thread] [next in thread]