The sdp_get() function from sdpops returns an extra blank line sometimes, which looks like a bug to me. When I have an SDP that's in MIME, there's an extra newline at the end of the extracted SDP. Here's a sample config. I use 5.8.1 for testing.
#################### #!KAMAILIO listen=udp:203.0.113.57:5060 debug=1 loadmodule "sdpops" loadmodule "pv" loadmodule "xlog" request_route{exit;} reply_route { sdp_get("$avp(sdp)"); xlog("L_NOTICE", "[$ci] The SDP is [$avp(sdp)].\n"); } ####################
Here are two sample SIP-message bodies. #################### v=0 o=PCD 1730 1730 IN IP4 198.18.114.148 s=PCD c=IN IP4 198.18.114.148 t=0 0 m=audio 29426 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ####################
#################### --e61e7a6a-16a2-46c0-adbb-a41ba86d32a2 Content-Type: application/sdp Content-Length: 130
v=0 o=PCD 1730 1730 IN IP4 198.18.114.148 s=PCD c=IN IP4 198.18.114.148 t=0 0 m=audio 29426 RTP/AVP 0 a=rtpmap:0 PCMU/8000
--e61e7a6a-16a2-46c0-adbb-a41ba86d32a2-- ####################
When the first body is received, the xlog correctly ends with this. m=audio 29426 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ] with length 130
When the second body is received, the xlog incorrectly ends with this, which has an extra newline in it. m=audio 29426 RTP/AVP 0 a=rtpmap:0 PCMU/8000
] with length 132
According to RFC2046, "The CRLF preceding the boundary delimiter line is conceptually attached to the boundary", but it looks like kamailio has a bug that incorrectly processes this.
James
Hello,
probably the source and and specs have to be checked in this case, but meanwhile one can use the transformations to trim whitespaces at the beginning or end of a string (iirc: $(avp(sdp){s.trim}) ).
Cheers, Daniel
On 01.11.24 14:02, James Browne via sr-users wrote:
The sdp_get() function from sdpops returns an extra blank line sometimes, which looks like a bug to me. When I have an SDP that's in MIME, there's an extra newline at the end of the extracted SDP. Here's a sample config. I use 5.8.1 for testing.
#################### #!KAMAILIO listen=udp:203.0.113.57:5060 debug=1 loadmodule "sdpops" loadmodule "pv" loadmodule "xlog" request_route{exit;} reply_route { sdp_get("$avp(sdp)"); xlog("L_NOTICE", "[$ci] The SDP is [$avp(sdp)].\n"); } ####################
Here are two sample SIP-message bodies. #################### v=0 o=PCD 1730 1730 IN IP4 198.18.114.148 s=PCD c=IN IP4 198.18.114.148 t=0 0 m=audio 29426 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ####################
#################### --e61e7a6a-16a2-46c0-adbb-a41ba86d32a2 Content-Type: application/sdp Content-Length: 130
v=0 o=PCD 1730 1730 IN IP4 198.18.114.148 s=PCD c=IN IP4 198.18.114.148 t=0 0 m=audio 29426 RTP/AVP 0 a=rtpmap:0 PCMU/8000
--e61e7a6a-16a2-46c0-adbb-a41ba86d32a2-- ####################
When the first body is received, the xlog correctly ends with this. m=audio 29426 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ] with length 130
When the second body is received, the xlog incorrectly ends with this, which has an extra newline in it. m=audio 29426 RTP/AVP 0 a=rtpmap:0 PCMU/8000
] with length 132
According to RFC2046, "The CRLF preceding the boundary delimiter line is conceptually attached to the boundary", but it looks like kamailio has a bug that incorrectly processes this.
James __________________________________________________________ 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:
Thanks, Daniel. That's exactly what I did (remove two newlines and add exactly one back in). set_body("$(avp(sdp){s.trim})\r\n", "application/sdp");
I had to send an email rather than simply ignore an apparent bug.
James
On Mon, 4 Nov 2024 at 07:37, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
probably the source and and specs have to be checked in this case, but meanwhile one can use the transformations to trim whitespaces at the beginning or end of a string (iirc: $(avp(sdp){s.trim}) ).
Cheers, Daniel
On 01.11.24 14:02, James Browne via sr-users wrote:
The sdp_get() function from sdpops returns an extra blank line sometimes, which looks like a bug to me. When I have an SDP that's in MIME, there's an extra newline at the end of the extracted SDP. Here's a sample config. I use 5.8.1 for testing.
#################### #!KAMAILIO listen=udp:203.0.113.57:5060 debug=1 loadmodule "sdpops" loadmodule "pv" loadmodule "xlog" request_route{exit;} reply_route { sdp_get("$avp(sdp)"); xlog("L_NOTICE", "[$ci] The SDP is [$avp(sdp)].\n"); } ####################
Here are two sample SIP-message bodies. #################### v=0 o=PCD 1730 1730 IN IP4 198.18.114.148 s=PCD c=IN IP4 198.18.114.148 t=0 0 m=audio 29426 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ####################
#################### --e61e7a6a-16a2-46c0-adbb-a41ba86d32a2 Content-Type: application/sdp Content-Length: 130
v=0 o=PCD 1730 1730 IN IP4 198.18.114.148 s=PCD c=IN IP4 198.18.114.148 t=0 0 m=audio 29426 RTP/AVP 0 a=rtpmap:0 PCMU/8000
--e61e7a6a-16a2-46c0-adbb-a41ba86d32a2-- ####################
When the first body is received, the xlog correctly ends with this. m=audio 29426 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ] with length 130
When the second body is received, the xlog incorrectly ends with this, which has an extra newline in it. m=audio 29426 RTP/AVP 0 a=rtpmap:0 PCMU/8000
] with length 132
According to RFC2046, "The CRLF preceding the boundary delimiter line is conceptually attached to the boundary", but it looks like kamailio has a bug that incorrectly processes this.
James __________________________________________________________ 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:
-- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com
-
Daniel-Constantin Mierla -
James Browne