[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