Hi,

thanks for the follow up!

I don’t think though that this has anything to do with rtpengine since the SDP parser is part of the kamailio project and the error specifically occurs in „core/parser/sdp/sdp.c:523“. Also the example is unfortunately not the same since the „c=“ line is on session level and not on media level.

I read through the RFCs and found two points in different RFCs, and i am not sure which takes precedence in this case, that’s mainly why i posted to the mailing list rather than opening an issue on the kamailio github:

In RFC8866 5.7:

A session description MUST contain either at least one "c=" line in each media description or a single "c=" line at the session level. It MAY contain a single session-level "c=" line and additional media-level "c=" line(s) per-media-description, in which case the media-level values override the session-level settings for the respective media.

Technically the SDP i posted does not conform to this, but then there is RFC3264 8.2:

Existing media streams are removed by creating a new SDP with the port number for that stream set to zero.  The stream description MAY omit all attributes present previously, and MAY list just a single media format.

So which RFC takes precendence? If it’s RFC8866 5.7 then the device is doing something wrong, but if it’s RFC3264 8.2 and i understand it correctly so that the device can omit even the „c=“ line (… The stream description MAY omit all attributes present previously…) then i would argue that kamailio is doing something wrong.

Any ideas? Should i open an issue on github?

Mit kommunikativen Grüßen I Best regards

Thomas Baumgartner

VoIP Engineering

Diese Nachricht kann Betriebs- bzw. Geschäftsgeheimnisse oder vertrauliche Informationen enthalten und ist ausschließlich für den beabsichtigten Empfänger bestimmt. Sollten Sie diese E-Mail irrtümlich erhalten, benachrichtigen Sie uns bitte, und löschen Sie diese Mail einschließlich aller angefertigten Kopien.

This message may contain trade secrets or confidential information and is intended exclusively for the intended recipient. If you receive this e-mail in error, please notify us and delete this e-mail including all copies made.

Von: Sergei Safarov <s.safarov@gmail.com>
Gesendet: Dienstag, 24. September 2024 13:14
An: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org>
Cc: Thomas Baumgartner <t.baumgartner@ipaustria.com>
Betreff: Re: [SR-Users] SDP parsing fails when media stream is removed, there is no session-wide "c=" line and offending media stream omits all attributes

Please check

https://datatracker.ietf.org/doc/html/rfc7345

You will find example

   v=0
   o=- 4423478999 5424222292 IN IP4 ua2.example.com
   s=-
   c=IN IP4 ua2.example.com
   t=0 0
   m=audio 0 UDP/TLS/RTP/SAVP 0
   m=image 32000 UDP/TLS/UDPTL t38
   a=setup:active
   a=fingerprint: SHA-1 \
     FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
   a=T38FaxRateManagement:transferredTCF
 
In my opinion, this example equal to your case.
Probable this need to be reported on RTPengine bug tracker.
 
Sergey Safarov
 

On Mon, 2024-09-23 at 08:27 +0000, Thomas Baumgartner via sr-users wrote:

Hi,

we have a problem with a device trying to send T.38 fax. During the T.38 ReInvite Kamailio fails to parse the SDP (via rtpengine_manage), and subsequently rtpengine is failing to do it’s job.

The problem seems to be that Kamailio is trying to find a media address, since there is no session-wide c= line present it goes to the media c= lines, but since the first media stream which was an audio stream is being removed (port 0) and can therefore omit all attributes (as per RFC 3264 8.2, or am i understanding this wrong?), the Kamailio SDP parser is failing, even if there is another c= line in the T.38 media stream.

Here is the offending SDP from the ReInvite (IP changed):

v=0

o=xmserver 1726638425 1726638427 IN IP4 169.254.1.1

s=xmserver

t=0 0

m=audio 0 RTP/AVP 8

m=image 56002 udptl t38

c=IN IP4 169.254.1.1

a=sendrecv

a=T38FaxVersion:0

a=T38MaxBitRate:14400

a=T38FaxFillBitRemoval:0

a=T38FaxTranscodingMMR:0

a=T38FaxTranscodingJBIG:0

a=T38FaxRateManagement:transferredTCF

a=T38FaxMaxBuffer:200

a=T38FaxMaxDatagram:72

a=T38FaxUdpEC:t38UDPRedundancy

And here is the corresponding log entry:

<core> [core/parser/sdp/sdp.c:523]: parse_sdp_session(): can't find media IP in the message

Can anyone confirm my findings? Is it possible to adjust the SDP parser for these kind of scenarios?

Mit kommunikativen Grüßen I Best regards

Thomas

__________________________________________________________

Kamailio - Users Mailing List - Non Commercial Discussions

To unsubscribe send an email to sr-users-leave@lists.kamailio.org

Important: keep the mailing list in the recipients, do not reply only to the sender!

Edit mailing list options or unsubscribe: