like your changes did indeed make it into the tree- this code looks exactly
(other than some of the obvious g* types and functions, and a few changes made
after this, adjusting the timestamp and sequence number) like the code I’m
using from the linphone distribution.
looks fairly straight forward- I can’t see any obvious reason why I would
get the results I’m getting.
I do also
have a trace from wireshark that shows this output if that helps?
anywhere else in the code that deals with events? Or that might re-send packets
for some reason?
From: Vadim Lebedev
Sent: Monday, April 14, 2008 6:32 AM
Subject: Re: [Linphone-developers] DTMF issues with oRTP
I’ve developed a custom
SIP application (using my own SIP library), and oRTP for the media channel.
Everything seems to work
great, other than some occasional DTMF issues (RFC2833 using the
rtp_session_send_dtmf() function in oRTP).
If I run wireshark (ethereal)
on the interface, and I send out a DTMF tone, normally I see five packets
(three packets, then the third repeated two more times for reliability)- which
correlates exactly with the code in telephonyevents.c. The maximum duration
gets to 480.
But, occasionally, I’ll
send a DTMF tone, and see hundreds of packets (the last test I did, sent out
200 packets), and the duration keeps incrementing (the last test incremented up
to 32160). It does also send the last packet three times as in the first case
Because of the long
duration, this obviously translates into a long tone on the receiving end,
which is causing me some issues with some termination providers (some deal with
Does anybody have any
thoughts on where these extra packets are coming from?
I’ve downloaded the CVS
version of oRTP from the linphone distribution; I saw there was some changes
related to the sequence number and timestamp, but it didn’t seem to
resolve this issue.
Any help would be greatly
Lot time ago i've fixed oRTP DTMF generating code, i don't remember
if my code finally made it's way to maing oRTP tree...
Here it goes:
address@hidden: a rtp session.
address@hidden: boolean to indicate if the marker bit should
* Allocates a new rtp packet to be used to add named
telephony events. The application can use
* then rtp_session_add_telephone_event() to add named
events to the packet.
* Finally the packet has to be sent with
*Returns: a message block containing the rtp packet if successfull, NULL
if the rtp session
*cannot support telephony event (because the rtp profile it is bound to
does not include
*a telephony event payload type).
*session, int start)
if (mp==NULL) return NULL;
rtp->version = 2;
rtp->padbit = 0;
rtp->extbit = 0;
rtp->cc = 0;
rtp->ssrc = session->local.ssrc;
/* timestamp set later, when packet is sended */
/*seq number set later, when packet is sended */
/*set the payload type */
/*copy the payload */
address@hidden : a rtp session
address@hidden : a character meaning the
dtmf (ex: '1', '#' , '9' ...)
address@hidden : the timestamp
* This functions creates telephony events packets for
@dtmf and sends them.
* It uses rtp_session_create_telephone_event_packet()
* rtp_session_add_telephone_event() to create them and
* rtp_session_sendm_with_ts() to send them.
*Returns: 0 if successfull, -1 if the session cannot
support telephony events or if the dtmf
* given as argument is not valid.
gint rtp_session_send_dtmf(RtpSession *session, gchar dtmf, guint32 userts)
return rtp_session_send_dtmf2(session, dtmf, userts, 480);
gint rtp_session_send_dtmf2(RtpSession *session, gchar dtmf, guint32 userts,
int durationtier = duration/3;
/* create the first telephony event packet */
if (m1==NULL) return -1;
/* create a second packet */
if (m2==NULL) return -1;
/* create a third and final packet */
if (m3==NULL) return -1;
/* and now sends them */
/* the last packet is sent three times in order to improve
/* we need to copymsg() instead of dupmsg() because the
buffers are modified when
the packet is sended because of the host-to-network
conversion of timestamp,ssrc, csrc, and
It could be avoided by making a copy of the buffer when
sending physically the packet, but
it add one more copy for every buffer.
Using iomapped socket, it is possible to avoid the user to
Linphone-developers mailing list