Why telephone-event/8000 hardcoded (Arjun Kamath)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

I have found a 'hack' which seems to work, but I'd really like to know if
it's advisable to do this, and if possible, if someone could suggest a
better way.

So firstly to elaborate on my need. I would like the SIP client to
advertise, along with its codecs the telephone-event/8000 or
telephone-event/16000 or both depending on the codecs being used. So
overall, depending on the sampling rate of the codec being used, the RFC
2833 DTMF tones should be sent as either telephone-event/8000 or
telephone-event/16000.

I explored the code and I was surprised to find that the /8000 part was
hardcoded.

<endpoint.c>

#if defined(PJMEDIA_RTP_PT_TELEPHONE_EVENTS) &&
PJMEDIA_RTP_PT_TELEPHONE_EVENTS != 0

    /*
     * Add support telephony event
     */
    if (endpt->has_telephone_event)
    {
        //DTMF 8kHz
        m->desc.fmt[m->desc.fmt_count++] =
            pj_str(PJMEDIA_RTP_PT_TELEPHONE_EVENTS_STR);

        /* Add rtpmap. */
        attr = PJ_POOL_ZALLOC_T(pool, pjmedia_sdp_attr);
        attr->name = pj_str("rtpmap");
        attr->value = pj_str(PJMEDIA_RTP_PT_TELEPHONE_EVENTS_STR
                     " telephone-event/8000");
        m->attr[m->attr_count++] = attr;

        /* Add fmtp */
        attr = PJ_POOL_ZALLOC_T(pool, pjmedia_sdp_attr);
        attr->name = pj_str("fmtp");
        attr->value = pj_str(PJMEDIA_RTP_PT_TELEPHONE_EVENTS_STR " 0-15");
        m->attr[m->attr_count++] = attr;
    }
#endif

Can someone explain why this hard-coding? Is there never any need to change
the sampling rate?

<From RFC 2833>

4.4 Payload Format

   Based on the characteristics described above, this document defines
   an RTP payload format called "tone" that can represent tones
   consisting of one or more frequencies. (The corresponding MIME type
   is "audio/tone".) The default timestamp rate is 8,000 Hz, but other
   rates may be defined. Note that the timestamp rate does not affect
   the interpretation of the frequency, just the durations.

So here's my hack in endpoint.c

..
        //DTMF 16kHz
        m->desc.fmt[m->desc.fmt_count++] =
            pj_str("97");

        // Add rtpmap.
        attr = PJ_POOL_ZALLOC_T(pool, pjmedia_sdp_attr);
        attr->name = pj_str("rtpmap");
        attr->value = pj_str("97"
                     " telephone-event/16000");
        m->attr[m->attr_count++] = attr;

        // Add fmtp
        attr = PJ_POOL_ZALLOC_T(pool, pjmedia_sdp_attr);
        attr->name = pj_str("fmtp");
        attr->value = pj_str(PJMEDIA_RTP_PT_TELEPHONE_EVENTS_STR " 0-15");
        m->attr[m->attr_count++] = attr;
..

I know this is a silly and ugly hack. But it seemed to convince the remote
side to let me send DTMF events to it.

I found very scant information about this on the internet, so please
forgive me if its a silly question.

Regards,
Arjun


> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 3 Aug 2012 13:27:52 +0300
> From: Arjun Kamath <junnaonly@xxxxxxxxx>
> To: pjsip at lists.pjsip.org
> Subject: telephone-event/16000
> Message-ID:
>         <
> CADzHbEUH7LPPgHeSTfVDw54BPZV2vuUoS5VLXjZfQZne4GJDdQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> Does PJSIP support sending DTMF tones as telephone-event/16000. Right now,
> when I have AMR-NB active, DTMF works fine, but I get the
> PJMEDIA_RTP_EREMNORFC2833 with AMR-WB.
>
> --
> Best Regards,
>
> Arjun P. Kamath
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120807/fae7ba3d/attachment-0001.html>


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux