Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add option to use PT number of telepone-event on local offer if no answer is provided #3661

Closed
wants to merge 2 commits into from
Closed

Add option to use PT number of telepone-event on local offer if no answer is provided #3661

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ca8bb64
Add configuration for default incoming payload type number for teleph…
trengginas Aug 15, 2023
db7bd6c
Modification based on comment
trengginas Aug 16, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions pjmedia/include/pjmedia/config.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -459,6 +459,16 @@
# define PJMEDIA_DTMF_DURATION_MSEC 200
#endif

/**
* The payload type number of the DTMF/telephone-event is set dynamically out-of-band.
* In case that remote endpoint doesn't specify the the payload type number
* in the SDP, the incoming DTMF might be ignored (bad RTP PT number). Set this as the
* default payload type number for incoming DTMF/telephone-event if no payload type number
* is specified on the SDP.
*/
#ifndef PJMEDIA_DTMF_TEL_EVENT_RX_PT
# define PJMEDIA_DTMF_TEL_EVENT_RX_PT -1
#endif

/**
* Number of RTP packets received from different source IP address from the
Expand Down
2 changes: 1 addition & 1 deletion pjmedia/src/pjmedia/stream_info.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -304,7 +304,7 @@ static pj_status_t get_audio_codec_info_param(pjmedia_stream_info *si,


/* Get incomming payload type for telephone-events */
si->rx_event_pt = -1;
si->rx_event_pt = PJMEDIA_DTMF_TEL_EVENT_RX_PT;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO this approach sounds hackish because tel-event PT is basically a dynamic PT, which may change between calls or even between SDP offer/answer in the same call (e.g: when codecs are enabled/disabled).

If we want to accept DTMF when remote SDP answer does not specify it in its SDP, perhaps a better approach is to handle it in the SDP negotiation (i.e: do not remove it from the local offer). Then perhaps introduce a config setting for enabling/disabling this behaviour.

Another idea is to allow app overriding si->rx_event_pt via PJSUA callback on_stream_precreate (and PJSUA2). A disadvantage compared to prev approach is: it may not be straightforward as app may need to check the initial local offer to know the offered PT (which is later removed by the SDP nego as remote does not have tel-event).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to accept DTMF when remote SDP answer does not specify it in its SDP, perhaps a better approach is to handle it in the SDP negotiation (i.e: do not remove it from the local offer). Then perhaps introduce a config setting for enabling/disabling this behaviour.

This sounds okay, but since this is remote's issue, perhaps handling it in the app level would be better? App can modify the SDP answer and add the tel-event manually.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the SDP nego scenario:
Offer

v=0
o=- 3899294638 3899294638 IN IP4 192.168.254.200
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 23002 RTP/AVP 96 97 98 99 3 0 8 9 120 121 122
c=IN IP4 192.168.254.200
b=TIAS:64000
a=rtcp:23003 IN IP4 192.168.254.200
a=sendrecv
a=rtpmap:96 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:98 speex/32000
a=rtpmap:99 iLBC/8000
a=fmtp:99 mode=30
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:120 telephone-event/16000
a=fmtp:120 0-16
a=rtpmap:121 telephone-event/8000
a=fmtp:121 0-16
a=rtpmap:122 telephone-event/32000
a=fmtp:122 0-16
a=ssrc:415131524 cname:074d4dc8644366bb

Answer:

v=0
o=- 2616112480 1 IN IP4 192.168.254.6
c=IN IP4 192.168.254.6
t=0 0
m=audio 50080 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20

Later, remote/callee sends DTMF with PT 122. Not clear how they choose the PT based on the offer, I assume it is the latest tel-event.

Copy link
Member

@sauwming sauwming Aug 18, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The latest commit has even more limited usage, since it only allows the last telephone-event PT (so if remote sends 120 or 121, it will still be rejected?).

I would first suggest the app to add the answers themselves. This should be done considering their understanding of the problematic remote, so they are free to choose the telephone event PT remote will most likely send. As the issue lies with the remote itself, there is no need for a library fix at the moment.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it is possible for the app to override the telefone-event PT, than this would be the best approach, at least for us. So we can handle this differently for different PBXes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sauwming, I leaning to agree with you. It's not really clear how the remote choose the PT used. @ilogixxDE , app can modify the SDP answer to include the telephone-event used.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be great, if we can handle the SDP in PJSUA or at least have an option at runtime to set the expected PT Type in case we are facing a system that behaves like the one we have described. We expect to run into similar issues with other PBXes too, so it would be great if we have an easy way to make DTMF work, similar to this PR. Can this be added somehow as an option in PJSUA, please?

for (i=0; i<local_m->attr_count; ++i) {
pjmedia_sdp_rtpmap r;

Expand Down
Loading