[asterisk-dev] Odd PJMEDIA_SDP_EMISSINGRTPMAP
Joshua C. Colp
jcolp at digium.com
Thu Aug 1 17:48:43 CDT 2019
On Thu, Aug 1, 2019, at 7:30 PM, James Cloos wrote:
> I tried once again to switch an asterisk install to use pj instead of
> chan_sip, and am seeing an odd error.
>
> This particular one is dealing with unwanted calls (endless sewer style
> of reply), and given this sdp:
>
> v=0
> o=200107170215185:5060 16264 18299 IN IP4 0.0.0.0
> s=pplsip
> c=IN IP4 0.0.0.0
> t=0 0
> m=audio 25282 RTP/AVP 100 6 0 8 3 18 5 101
> a=rtpmap:0 pcmu/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-11
>
> pj returns PJMEDIA_SDP_EMISSINGRTPMAP, which means it cannot find an
> rtpmap line. Even though two exist.
>
> I see that example has 0.0.0.0 for the o and c lines, so obviously the
> attacker doesn't want audio. But I'd still like to waste some of their
> cycles dealing with a series of 180s.
>
> Chan_sip would send the call to the dialplan.
>
> Should pj not also?
It's not as tolerant/forgiving as chan_sip. It's following this from the RFC I believe:
For each media format of that type supported by the
agent, there SHOULD be a media format listed in the "m=" line. In
the case of RTP, if dynamic payload types are used, an rtpmap
attribute MUST be present to bind the type to a specific format.
There is dynamic payload 100 in the SDP, but no rtpmap to state what it is thus violating that part of the SDP, and likely why the pjmedia-sdp code doesn't like it.
--
Joshua C. Colp
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
More information about the asterisk-dev
mailing list