Error connecting call: Error: expected multipart SIPREC body"

[stuartfortman]

I see there is an issue opened already which is giving the same error, but I don't think it's for the same reason as I see there is a space after Content-Type:

Node version is v11.9.0

{"level":30,"time":1549309126729,"msg":"received SIPREC invite: sip:1229999999@192.168.2.123:5060;transport=udp","pid":5740,"hostname":"fax","callid":"9E098659@192.168.4.150","v":1} {"level":50,"time":1549309126734,"msg":"Error connecting call: Error: expected multipart SIPREC body","pid":5740,"hostname":"fax","callid":"9E098659@192.168.4.150","v":1}

invite.txt

[davehorton]

Hmm, this is strange. The metaswitch did not send an SDP with two m= media streams, which is the whole point of siprec - to get both streams. It only sent one m= line. Any ideas on why this would be?

--metaswitch-boundary
Content-Type: application/sdp

v=0
o=- 3120900133 3120900133 IN IP4 192.168.4.153
s=-
c=IN IP4 192.168.4.153
t=0 0
m=audio 40160 RTP/AVP 2 0 101
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=label:1

--metaswitch-boundary

[stuartfortman]

I believe the metaswitch mixes the two media streams together and sends it down to the sip rec server.

[davehorton]

OK, that's interesting. Is it possible to confirm that with them?

Assuming that is the case, I would need to make some changes to support it, which I am willing to do. It might take a few days before I have time though :(

Are you using rtpengine or freeswitch as the media server? It would be helpful to know so I can get your scenario working first

[stuartfortman]

MG MetaSwitch Local Media Gateway will provide RTP mixpoint resources for this call. I see this in the logs which I'm guessing is what that means. I was previously using an Asterisk box which I modified to ignore the Requires: siprec

Does the changes need to happen in the payload-parser.js file?

[davehorton]

Yes, changes would be required in that file, but others as well.

In a way, it really simplifies things since all we would really want to do in this degenerate case of a single stream is connect it to a Freeswitch (or rtpengine) and make a recording, however there is a lot of code that is assuming we have two media streams to deal with, and therefore we need to route them through the media server in a specific (more complex) way, and also need to combine SDPs from two endpoints to reply with an sdp containing 2 m= lines, which would also not be the case.

[stuartfortman]

I missed the question about rtpengine vs freeswitch. I have both spun up on the box, but planned on trying rtpengine.