Encoding Parameter crash?
24 views
Skip to first unread message
Adam Condus
Oct 24, 2024, 9:51:21 PMOct 24
to Sipwise rtpengine
Hello,
I'm using Kamailio (v5.6.4) + rtpengine (v11.5.1.11-1~bpo11+1).
The remote client is using an intercom system (useragent is: Wahsega-AC-Intercom/2.4.8) with our SIP server. When they place a call, it seems to crash rtpengine. When looking at the SIP packet the only thing that caught my eye was that they were sending "a=rtpmap:18 G729/8000/170" in SDP. The following is a [sanitized] example:
INVITE sip:15554...@sip.example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.37:54917;branch=z9hG4bKSJRc387R
From: "1000"<sip:10...@sip.example.com>;tag=1390597437
To: <sip:15554...@sip.example.com>
CSeq: 1 INVITE
Max-Forwards: 70
Call-ID: U75uR.Le-MS.jfjdP...@192.168.1.37
Contact: <sip:10...@192.168.1.37:54917;rinstance=1317448035>
Content-Length: 208
Content-Type: application/sdp
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE
Session-Expires: 300
Supported: timer
User-Agent: Wahsega-AC-Intercom/2.4.8
v=0
o=- 1729709438 1729709438 IN IP4 192.168.1.37
s=-
c=IN IP4 192.168.1.37
t=0 0
m=audio 23508 RTP/AVP 18 101
a=sendrecv
a=rtpmap:18 G729/8000/170
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
I don't have this intercom system; however I was able to replicate a crash by forcing Asterisk to send a similar attribute.
I'm assuming this is caused by the encoding parameter being set to 170. Is there any way to guard against this? I do have a debug log of my test call; which I've attached.
Thanks.
I'm using Kamailio (v5.6.4) + rtpengine (v11.5.1.11-1~bpo11+1).
The remote client is using an intercom system (useragent is: Wahsega-AC-Intercom/2.4.8) with our SIP server. When they place a call, it seems to crash rtpengine. When looking at the SIP packet the only thing that caught my eye was that they were sending "a=rtpmap:18 G729/8000/170" in SDP. The following is a [sanitized] example:
INVITE sip:15554...@sip.example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.37:54917;branch=z9hG4bKSJRc387R
From: "1000"<sip:10...@sip.example.com>;tag=1390597437
To: <sip:15554...@sip.example.com>
CSeq: 1 INVITE
Max-Forwards: 70
Call-ID: U75uR.Le-MS.jfjdP...@192.168.1.37
Contact: <sip:10...@192.168.1.37:54917;rinstance=1317448035>
Content-Length: 208
Content-Type: application/sdp
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE
Session-Expires: 300
Supported: timer
User-Agent: Wahsega-AC-Intercom/2.4.8
v=0
o=- 1729709438 1729709438 IN IP4 192.168.1.37
s=-
c=IN IP4 192.168.1.37
t=0 0
m=audio 23508 RTP/AVP 18 101
a=sendrecv
a=rtpmap:18 G729/8000/170
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
I don't have this intercom system; however I was able to replicate a crash by forcing Asterisk to send a similar attribute.
I'm assuming this is caused by the encoding parameter being set to 170. Is there any way to guard against this? I do have a debug log of my test call; which I've attached.
Thanks.
Richard Fuchs
Oct 25, 2024, 9:11:05 AMOct 25
to rtpe...@googlegroups.com
On 24/10/2024 21.51, Adam Condus wrote:
> I don't have this intercom system; however I was able to replicate a
> crash by forcing Asterisk to send a similar attribute.
>
> I'm assuming this is caused by the encoding parameter being set to
> 170. Is there any way to guard against this? I do have a debug log of
> my test call; which I've attached.
Do you have a gdb backtrace for this? When I try to reproduce this, I
> I don't have this intercom system; however I was able to replicate a
> crash by forcing Asterisk to send a similar attribute.
>
> I'm assuming this is caused by the encoding parameter being set to
> 170. Is there any way to guard against this? I do have a debug log of
> my test call; which I've attached.
just get an error from ffmpeg and no crash.
FTR, the `/170` is the number of audio channels. So this is quite a
strange input SDP.
Cheers
Reply all
Reply to author
Forward
0 new messages