Hello,
I got this message under some circumstances (the number called)
Jun 12 15:15:01 proxy1 /usr/sbin/kamailio[16096]: ERROR: <core> [core/parser/sdp/sdp.c:228]: set_sdp_payload_fmtp(): Invalid payload location
What means "Payload location" ?
SDP Debug from the callee: Jun 12 15:15:01 proxy1 /usr/sbin/kamailio[16096]: DEBUG: sdpops [sdpops_mod.c:1626]: sdp_get_helper(): Found SDP v=0#015#012o=- 5793 1 IN IP4 192.168.50.50#015#012s=-#015#012t=0 0#015#012m=audio 24734 RTP/AVP 8 101#015#012c=IN IP4 217.112.190.117#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:18 annexa=yes#015#012a=fmtp:101 0-15#015#012a=ptime:30#015#012a=silenceSupp:off - - - -#015#012a=sendrecv#015#012
SDP Debug called pbx:
Jun 12 15:15:01 proxy1 /usr/sbin/kamailio[16097]: DEBUG: sdpops [sdpops_mod.c:1626]: sdp_get_helper(): Found SDP v=0#015#012o=root 1673681431 1673681431 IN IP4 217.112.180.5#015#012s=Asterisk PBX 11.25.1#015#012c=IN IP4 217.112.180.5#015#012t=0 0#015#012m=audio 10884 RTP/AVP 8 101#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 0-16#015#012a=ptime:20#015#012a=sendrecv#015#012
We also found that it occurs everytime when RTPEngine is engaged.
this is related to sdp_keep_codec which doesn't remove fmtp payload.
The issue is related to the function call sdp_keep_codecs_by_id(..). It seems to not remove multiple "a=fmtp" lines related to a removed codec. Shortened example: ` m=audio 15684 RTP/AVP 8 18 4 0 101 13 a=fmtp:18 annexa=yes a=fmtp:18 annexb=no `
The resulting SDP that cause the error message is then this: ` v=0 o=- 7292 1 IN IP4 192.168.50.50 s=- t=0 0 m=audio 18466 RTP/AVP 8 101 c=IN IP4 XXX.XXX.XXX.XXX a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexa=yes a=fmtp:101 0-15 a=ptime:30 a=silenceSupp:off - - - - a=sendrecv `
Debug log file that shows the problem, second "a=fmtp" is not removed
[sdpops.txt](https://github.com/kamailio/kamailio/files/3293025/sdpops.txt)
It seems that the function sdp_remove_str_codec_id_attr(..) only removes the first attribute for a deleted codec.
I am traveling for the next week, maybe somebody else could have a look to this issue. Otherwise I can investigate after my return.
@henningw - did you get a chance to look deeper at this one?
@miconda not yet unfortunately
I looked into the SDPops module and also the SDP core parser. Furthermore I read the relevant RFCs more closely.
It seems that this particular situation (having two ftmp for one media/codec) is not valid.
RFC 4566: 6. SDP Attributes [...] a=fmtp:<format> <format specific parameters>
This attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP does not have to understand them. The format must be one of the formats specified for the media. Format-specific parameters may be any set of parameters required to be conveyed by SDP and given unchanged to the media tool that will use this format. At most one instance of this attribute is allowed for each format.
RFC 5939: 3.13.1. The "rtpmap" and "fmtp" Attributes [...] An "fmtp" attribute capability in a potential configuration for a media format that already has an "fmtp" attribute in the actual configuration may lead to multiple fmtp format parameters for that media format and that is not allowed by SDP [RFC4566]. The delete-attributes MUST be used to ensure that there are not multiple "fmtp" attributes for a given media format in a media description.
Closed #1983.
-
Daniel-Constantin Mierla -
Henning Westerholt
-
nicoonline