[Home]

Summary:ASTERISK-08658: No audio when peer sends IPV4 0.0.0.0 in sdp
Reporter:Sergey Basmanov (sb)Labels:
Date Opened:2007-01-25 03:38:47.000-0600Date Closed:2007-01-25 11:33:38.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) rtp.diff
Description:When * asterisk receives invite with this sdp:
v=0
o=160 0 0 IN IP4 0.0.0.0
s=
c=IN IP4 0.0.0.0
t=0 0
m=audio 5000 RTP/AVP 3 18 101
a=rtpmap:3 GSM/8000/1/8000
a=rtpmap:18 G729/8000/1/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
it doesn't sends/receives rtp at all.

****** ADDITIONAL INFORMATION ******

I watched this call with tcpdump. Remote correctly sends rtp stream to address/port provided by * in reply to invite. But rtp debug shows nothing.
Remote is behind NAT (type unknown).
Comments:By: Sergey Basmanov (sb) 2007-01-25 03:50:07.000-0600

Probably this issue is not related only to sip. Code in rtp.c returns immediately when no address is set (ast_rtp_read/ast_rtp_write).
And because of this, I see no way how remote can send audio to *.
As workaround, I think we need to set ip/port to same as signalling if it's all zeroes, when parsing sdp.
Or this needs to be fixed in rtp.c ?
By: Sergey Basmanov (sb) 2007-01-25 04:25:50.000-0600

This small fix in chan_sip solved issue.
       if (sscanf(c, "IN IP4 %256s", host) != 1) {
               ast_log(LOG_WARNING, "Invalid host in c= line, '%s'\n", c);
               return -1;
       }
+        /* Very ugly fix */
+        if (!strcmp(host, "0.0.0.0")) {
+            sprintf(host, "192.168.1.1");
+        }
By: Sergey Basmanov (sb) 2007-01-25 04:46:19.000-0600

Hmm.. After more closer look to source, I see that this may be fixed in rtp.c
But I wonder if this will not open any security issue or breaks anything else.
Patch for rtp.c is attached.
By: Olle Johansson (oej) 2007-01-25 11:32:09.000-0600

Well, if there's 0.0.0.0 in the SDP we are not supposed to send any RTP at all. So we are doing things perfectly right. It's the old method of indicating a hold situation.

Asterisk supports hold both by getting 0.0.0.0 as the IP and the a:direction directive.

This is not a bug
By: Joshua C. Colp (jcolp) 2007-01-25 11:33:38.000-0600

As oej stated this is not a bug, closing it out.