SIPREC Parsing gets an error of "Error connecting call: TypeError: Cannot read property '0' of undefined" due to inactive instead of sendonly

[IdoMagor]

Hello,

We've recently experienced a use-case in which we've sent in our SIP-REC Invite the variable "inactive" instead of "sendonly", which crashed the SIPREC parsePayload function.

I'm currently using this commit(95a6e71 - link).

Maybe I didn't found by mistake, but are there any changes that allow for receiving inactive and still function regarding receiving the SIP-REC and process it?

Sincerely yours, Ido Magor

[davehorton]

can you show the entire INVITE that causes the issue?

[IdoMagor]

Hello,

Regarding the SIP-REC Invite itself, you can ignore the IP address areas because I've switched the values from our URLs/IPs.

None the less, this is the SIP-REC Invite:

INVITE sip:9999@192.168.1.1:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.1.2:5060;branch=z9hG4bKB1DC85A9C
From: <sip:192.168.1.2>;tag=1ABEB6F7-D6D
To: <sip:9999@192.168.1.1>
Date: Mon, 07 Jun 2021 07:16:23 GMT
Call-ID: 199096CE-C69711EB-B1CAAD5D-148688C8@192.168.1.2
Supported: timer,resource-priority,replaces,sdp-anat
Require: 100relsiprec
Min-SE:  1800
Cisco-Guid: 0427911521-3331789291-3179475176-3642784766
User-Agent: Cisco-SIPGateway/IOS-16.9.5
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1623050183
Contact: <sip:192.168.1.2:5060;transport=tcp>;+sip.src
Expires: 180
Allow-Events: telephone-event
Session-ID: a8e7cb77a26f507699a1faa64b607b5c;remote=00000000000000000000000000000000
X-Orig-Call-ID: 0427911521-3331789291-3179475176-3642784766
X-Ingress-Label: 2
Content-Type: multipart/mixed;boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 2257

--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=CiscoSystemsSIP-GW-UserAgent 5179 6446 IN IP4 192.168.1.2
s=SIP Call
c=IN IP4 192.168.1.2
t=0 0
m=audio 19254 RTP/AVP 0 101 19
c=IN IP4 192.168.1.2
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
a=inactive
a=label:1
m=audio 19236 RTP/AVP 0 101 19
c=IN IP4 192.168.1.2
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
a=inactive
a=label:2

--uniqueBoundary
Content-Type: application/rs-metadata+xml
Content-Disposition: recording-session

<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns="urn:ietf:params:xml:ns:recording:1">
    <datamode>complete</datamode>
    <session session_id="GZBIusaXEeuxxK1dFIaIyA==">
        <sipSessionID>f845891467cf5c2189987435807bd432;remote=1aa1123b8825c906d03681ba23102629</sipSessionID>
        <start-time>2021-06-07T07:16:23.618Z</start-time>
    </session>
    <participant participant_id="GZBIusaXEeuxxa1dFIaIyA==">
        <nameID aor="sip:0733165805@192.168.40.34">
        </nameID>
    </participant>
    <participantsessionassoc participant_id="GZBIusaXEeuxxa1dFIaIyA==" session_id="GZBIusaXEeuxxK1dFIaIyA==">
        <associate-time>2021-06-07T07:16:23.618Z</associate-time>
    </participantsessionassoc>
    <stream stream_id="GbZGg8aXEeuxy61dFIaIyA==" session_id="GZBIusaXEeuxxK1dFIaIyA==">
        <label>1</label>
    </stream>
    <participant participant_id="GZBIusaXEeuxxq1dFIaIyA==">
        <nameID aor="sip:+972546136443@192.168.10.140">
        </nameID>
    </participant>
    <participantsessionassoc participant_id="GZBIusaXEeuxxq1dFIaIyA==" session_id="GZBIusaXEeuxxK1dFIaIyA==">
        <associate-time>2021-06-07T07:16:23.618Z</associate-time>
    </participantsessionassoc>
    <stream stream_id="GbZGg8aXEeuxzK1dFIaIyA==" session_id="GZBIusaXEeuxxK1dFIaIyA==">
        <label>2</label>
    </stream>
    <participantstreamassoc participant_id="GZBIusaXEeuxxa1dFIaIyA==">
    </participantstreamassoc>
    <participantstreamassoc participant_id="GZBIusaXEeuxxq1dFIaIyA==">
    </participantstreamassoc>
</recording>

--uniqueBoundary--

[IdoMagor]

@davehorton Hey Dave,

By any chance, is there an update regarding this issue?

Thanks :)

[davehorton]

please try with the latest (note: master branch has been renamed to main)