Open IdoMagor opened 3 years ago
can you show the entire INVITE that causes the issue?
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--
@davehorton Hey Dave,
By any chance, is there an update regarding this issue?
Thanks :)
please try with the latest (note: master branch has been renamed to main)
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