#281 Multipart/mixed messages with textops and mediaproxy

modules (454)

I have a server sending INVITE messages with a multipart/mixed body. There are 2 misbehaviours I had to correct because of a special constellation:
the content-Type header of my server looks like this:

> Content-Type: multipart/mixed;boundary=unique-boundary-1

saying that the parsing string is "unique-boundary-1". In the textops.c the string is hardcoded and checks for "-Boundary". So if I use the filter_body("application/sdp") function it fails. So Textops should read the delimiter string from Content-Type header dynamically. The hardcoded delimiter is in textops.c line 908.

Filtering works after correcting textops.c, but still mediaproxy module has a problem. After calling filter_body() I will route the call over mediaproxy, so I call use_media_proxy() from mediaproxy.c. But this function works with the uncorrected INVITE pakage again. So if it searches application/sdp it only finds multipart/mixed and no mediaproxy channel is created. Best solution would be to get mediaproxy to work with the previously corrected pakage. I am using a workaround now, replacing "status = get_sdp_message(msg, &sdp);" on line 1445 in mediaproxy.c with "status = 1;".



  • Bogdan-Andrei Iancu

    • assigned_to: nobody --> dan_pascu
  • Robert Smith

    Robert Smith - 2012-11-08

    I'm actually encountering this now with a callmanager setup using SIP-T to communicate over, and I want to get rid of the mixed multipart content and retain the sdp.

    In the SDP body, we have:
    Content-Type: multipart/mixed;boundary=uniqueBoundary#015#012Content-Length: 478#015#012#015#012--uniqueBoundary#015#01

    But it's hard coded to match on "--Boundary" only.

    This bug is quite old, but wanting to bring up that we'd also like to see the ability to honor the boundary= param here to specify a dynamic multipart boundary token.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks