Summary:ASTERISK-08658: No audio when peer sends IPV4 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
Versions:Frequency of
Environment:Attachments:( 0) rtp.diff
Description:When * asterisk receives invite with this sdp:
o=160 0 0 IN IP4
c=IN IP4
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.


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, "")) {
+            sprintf(host, "");
+        }

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 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 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.