2 Aug 2007 16:11
Re: DTMF codes not recognized
Pedro Sanchez <psanchez <at> nortel.com>
2007-08-02 14:11:53 GMT
2007-08-02 14:11:53 GMT
Benny Prijono wrote: > Pedro Sanchez wrote: >> config.h:192 sets the length ... but still I can't get DTMF to work>> >>> Also, can you suggest any other possible reasons why the server can't >>> recognize the DTMF coming from PJSUA? > > Silly idea, but maybe the payload type? > > The payload type for telephone-event is set by these two macros in > config.h: > - PJMEDIA_RTP_PT_TELEPHONE_EVENTS > - PJMEDIA_RTP_PT_TELEPHONE_EVENTS_STR > > -benny > (oops, this time with the attachment. You'll have to select Analyze|Decode As|RTP in the wireshark menu) I don't think this is a problem since other SIP clients that work well also use 101 for the payload type, it seems to be very popular
But I have a theory that I want to explore. In RFC 2833 (telephony-event) every DTMF digit is encoded as a sequence of one or more RTP EVENT packets. The number of packets in the sequence depends on the duration of the key press. In PJLIB the duration is set in the macro PJMEDIA_DTMF_DURATION. Each RTP EVENT packet carries an accumulated "Event duration" field indicating the total "running" time of the key press. It also carries a flag "End of Event" which tells whether the particular packet is the last one in the sequence or not. PJSIP preceeds what otherwise seems like a good DTMF sequence with an initial RTP EVENT packet that has the "Event Duration" field set to zero. I don't see this in any of the other SIP clients I can test. I don't know if this is somehow confusing the server but I'd like to get rid of it to test. I attach a wireshark trace of the DTMF sequence; note the very first packet there which makes the total number of packets for the first digit (3) to be 11 instead of 10 as for the other digits. I'm trying to figure out where in the code this is happening. If you can shorten my search time with a pointer to where I can look this up that would be great. Thanks, -- -- Pedro
_______________________________________________ pjsip mailing list: pjsip <at> pjsip.org http://pjsip.org/mailman/listinfo/pjsip Visit pjsip blog: http://blog.pjsip.org
>>
>>> Also, can you suggest any other possible reasons why the server can't
>>> recognize the DTMF coming from PJSUA?
>
> Silly idea, but maybe the payload type?
>
> The payload type for telephone-event is set by these two macros in
> config.h:
> - PJMEDIA_RTP_PT_TELEPHONE_EVENTS
> - PJMEDIA_RTP_PT_TELEPHONE_EVENTS_STR
>
> -benny
>
(oops, this time with the attachment. You'll have to select
Analyze|Decode As|RTP in the wireshark menu)
I don't think this is a problem since other SIP clients that work well
also use 101 for the payload type, it seems to be very popular
But I have a theory that I want to explore. In RFC 2833
(telephony-event) every DTMF digit is encoded as a sequence of one or
more RTP EVENT packets. The number of packets in the sequence depends on
the duration of the key press. In PJLIB the duration is set in the macro
PJMEDIA_DTMF_DURATION.
Each RTP EVENT packet carries an accumulated "Event duration" field
indicating the total "running" time of the key press. It also carries a
flag "End of Event" which tells whether the particular packet is the
last one in the sequence or not.
PJSIP preceeds what otherwise seems like a good DTMF sequence with an
initial RTP EVENT packet that has the "Event Duration" field set to
zero. I don't see this in any of the other SIP clients I can test.
I don't know if this is somehow confusing the server but I'd like to get
rid of it to test. I attach a wireshark trace of the DTMF sequence; note
the very first packet there which makes the total number of packets for
the first digit (3) to be 11 instead of 10 as for the other digits.
I'm trying to figure out where in the code this is happening. If you can
shorten my search time with a pointer to where I can look this up that
would be great.
Thanks,
RSS Feed