[reSIProcate] [recon-devel] onDtmfEvent tone representation?

[Dario Bozzali]

Hello,
I updated sources to last revision and I saw new changes to handle dtmf-relay contents.
In my opinion, the code could be improved adding some checks.
According to RFC 4733 (see at the end of the mail) valid event codes are restricted to 0-255.
Moreover, I'm not sure but I think that event codes 10-15 can be expressed using also one character in "*#AaBbCcDd" as value for signal.
So we could decode that event codes handling all cases (see the patch attached to this mail).
At the moment when we encode that event codes we use integer value. I don't know if this is the best choice for interoperability with other systems.
Finally, skipEol method is already defined in SdpContents.cxx. I suggest to reuse that implementation in DtmfPayloadContents (again, see suggested patch).
Best regards,
Dario.


RFC 4733 " RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals"
7.  IANA Considerations
...
   Legal event codes range from 0 to 255.  The initial registry content
   is shown in Table 7, and consists of the sixteen events defined in
   Section 3 of this document.  The remaining codes have the following
   disposition:

   o  codes 17-22, 50-51, 90-95, 113-120, 169, and 206-255 are available
      for assignment;

   o  codes 23-40, 49, and 52-63 are reserved for events defined in
      [16];

   o  codes 121-137 and 174-205 are reserved for events defined in [17];

   o  codes 16, 41-48, 64-88, 96-112, 138-168, and 170-173 are reserved
      in the first instance for specifications reviving the
      corresponding RFC 2833 events, and in the second instance for
      general assignment after all other codes have been assigned.

        +------------+--------------------------------+-----------+
        | Event Code | Event Name                     | Reference |
        +------------+--------------------------------+-----------+
        |          0 | DTMF digit "0"                 |  RFC 4733 |
        |          1 | DTMF digit "1"                 |  RFC 4733 |
        |          2 | DTMF digit "2"                 |  RFC 4733 |
        |          3 | DTMF digit "3"                 |  RFC 4733 |
        |          4 | DTMF digit "4"                 |  RFC 4733 |
        |          5 | DTMF digit "5"                 |  RFC 4733 |
        |          6 | DTMF digit "6"                 |  RFC 4733 |
        |          7 | DTMF digit "7"                 |  RFC 4733 |
        |          8 | DTMF digit "8"                 |  RFC 4733 |
        |          9 | DTMF digit "9"                 |  RFC 4733 |
        |         10 | DTMF digit "*"                 |  RFC 4733 |
        |         11 | DTMF digit "#"                 |  RFC 4733 |
        |         12 | DTMF digit "A"                 |  RFC 4733 |
        |         13 | DTMF digit "B"                 |  RFC 4733 |
        |         14 | DTMF digit "C"                 |  RFC 4733 |
        |         15 | DTMF digit "D"                 |  RFC 4733 |
        +------------+--------------------------------+-----------+

            Table 7: audio/telephone-event Event Code Registry


-----Original Message-----
From: recon-devel [mailto:recon-devel-bounces at resiprocate.org] On Behalf Of Daniel Pocock
Sent: martedì 18 marzo 2014 16.33
To: recon-devel at resiprocate.org
Subject: [recon-devel] onDtmfEvent tone representation?


ConversationManager::onDtmfEvent has an int argument for the tone

Is the 0 button equal to integer 0 or '0'?

Is the A button equal to 'A' or 10 or something else?

Should we define these in an enum perhaps?

Regards,

Daniel


_______________________________________________
recon-devel mailing list
recon-devel at resiprocate.org
List Archive: http://list.resiprocate.org/archive/recon-devel/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DtmfPayloadContents.patch
Type: application/octet-stream
Size: 4830 bytes
Desc: DtmfPayloadContents.patch
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20140319/5db91658/attachment.obj>