[Home]

Summary:ASTERISK-14386: Multiple m=video or m=audio lines cause a ip port number mismatch.
Reporter:Arun Punj (arunpunj)Labels:
Date Opened:2009-06-26 10:04:14Date Closed:2011-07-26 14:57:19
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Test Setup
-----------

Two Sip terminals capable of generating multiple m=video lines. Say terminals
T1 and T2. T1 calls T2.

T1 generates following offer to T2 ( some lines and fields edited out for privacy)

v=0
o=ViPr 1 1 IN IP4 10.55.100.53
s=-
e=NoEmail@NoEmail.com
t=0 0
m=audio 51068 RTP/AVP 9 113 112 111 0 8 15
c=IN IP4 10.55.100.53
a=rtpmap:9 G722/8000
a=rtpmap:113 G7221/32000
a=fmtp:113 bitrate=32000
a=rtpmap:112 G7221/24000
a=fmtp:112 bitrate=24000
a=rtpmap:111 G7221/16000
a=fmtp:111 bitrate=16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:15 G728/8000
a=sendrecv
m=video 31074 RTP/AVP 109 34 31 32
c=IN IP4 10.55.100.53
a=rtpmap:109 H264/90000
a=fmtp:109 profile-level-id=42801e
a=rtpmap:34 H263/90000
a=fmtp:34 CIF=1 QCIF=1 MaxBR=40000
a=rtpmap:31 H261/90000
a=fmtp:31 CIF=1 QCIF=1 MaxBR=40000
a=rtpmap:32 MPEG/90000
a=sendrecv
m=video 31076 RTP/AVP 109
c=IN IP4 10.55.100.53
a=rtpmap:109 H264/90000
a=fmtp:109 profile-level-id=42801e
a=recvonly

The asterisk forwards the call to T2. However, 2 video offers are replaced by only 1 video offer. T2 accepts the call with single video offer. And the call comes up fine, the audio is good but no video is seen. The audio/video are both to be relayed through asterisk.

Upon investigation it is found that asterisk is relaying video from T2 to T1 on port 31076 which is the port corresponding to second video stream.

A simple one line change in chan_sip.c fixes the issue.I think same one line fix is applicable to m=audio and m=text lines as well. I have marked is as blocking as it blocks the use of our device with asterisk, but obviously it does not seem to block most people.

I tried to locate if this bug is already reported, if its a duplicate I apologize for taking your time.


thank you
Arun Punj

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

--- chan_sip.c  2009-06-26 06:47:09.000000000 -0400
+++ chan_sip.c.old      2009-06-26 06:46:50.000000000 -0400
@@ -6729,7 +6729,6 @@
               } else if ((sscanf(m, "video %d/%d RTP/AVP %n", &x, &numberofports, &len) == 2 && len > 0) ||
                   (sscanf(m, "video %d RTP/AVP %n", &x, &len) == 1 && len >= 0)) {
                       video = TRUE;
-                        if ( p->novideo == FALSE ) continue;
                       p->novideo = FALSE;
                       numberofmediastreams++;
                       vportno = x;
~
Comments:By: Leif Madsen (lmadsen) 2009-09-01 16:10:42

Assigned to dvossel for review. Not sure if the one line proposal is the correct way to go about this or not.
By: David Vossel (dvossel) 2009-09-02 12:02:14

your fix resolves the issue for your specific case, but I don't believe it is a proper fix for every case.  Essentially it is ignoring multiple m=video offers.

I have a good idea of what is going on here.  Is there any way you can provide a packet capture of this exchange from the Asterisk box?
By: Arun Punj (arunpunj) 2009-09-02 12:38:32

I am afraid I cannot provide you the trace right now. I can provide you the packet traces in a week or so. Essentially the traces are simple an offer with 3 m blocks, one audio and two video is converted to an offer with only 2 m blocks, the second video block overrides the first one. Which though a bug by itself is not so much an issue. The real problem is that it forward the wrong port number for video to the originator of the call.

You are right this is not the most appropriate fix, just the quickest one to get me going. Ideally there would be a way to convey more than one stream info from source side to destination side of a call, but since there is support only for single audio, single video and single text stream in the SDP this change is enough.

thanks
Arun
By: David Vossel (dvossel) 2009-09-02 13:28:18

"Upon investigation it is found that asterisk is relaying video from T2 to T1 on port 31076 which is the port corresponding to second video stream."

Why is this incorrect?  It doesn't seem to me like it should matter which video stream Asterisk chooses if it can only support one.
By: Arun Punj (arunpunj) 2009-09-02 14:32:30

This is incorrect for following reason.

First in the OK which comes back from SDP. There are only two m= lines one for audio and another for video. As per SDP spec, asterisk should have sent 3 media lines. 1 for audio and 2 for video. The second video block could be empty. Which would be fine as it would let our device know correctly which media block is not supported.

When OK is received with only a single m=video line our device makes an assumption correctly that some intermediate node does not support 2 m=video lines and hence it disables the receiver on the second video stream ( which is the one which asterisk is using to relay video). There is a label field added in the SDP by out device to identify the stream, however, that label field is also stripped by asterisk, along with any useful parameter which would let us identify the media as the second stream.

In the end there are multiple ways to get this to work. The right way is to support multiple videos through asterisk and also having the ability to pass various parameters (fmptp, labels etc) which would let the receiver and transmitter discover each others capability and setup video accordingly. But looking at the architecture it is a considerable chunk of work, which I am currently not able to put.

I also modified my own version of asterisk to actually relay the extra media block lines by embedding incoming/outgoing offers in tech_pvt fields and always by passing asterisk for those streams. I can probably dig it up and send that code to you, if you want.


thanks
Arun
By: David Vossel (dvossel) 2009-09-02 17:23:30

I understand.  So since asterisk does not support one of the two m=video lines, it should still keep that line in the SDP but indicate it is not supported by setting the port in the media stream to 0.

from rfc 3265
" To reject an offered stream, the port number in the corresponding stream in the answer MUST be set to zero. "

Does this sound like it will resolve this issue?
By: Arun Punj (arunpunj) 2009-09-03 07:41:11

Excellent. This would be a good solution. You know if you can do that, then adding support for passing fmptp parameters and other parameters not understood by asterisk will not be difficult.

thanks
Arun
By: Olle Johansson (oej) 2009-09-09 03:24:57

At this point, we only support one media stream per type - one audio, one video, one fax and one realtime text. To change that would require quite a lot of work on one hand, but also result in an even better platform.

Today I don't think there's a stream identifier in the AST_FRAMEs and there's no indication of multiple streams in the core.

Check the recent patch by Mark where us at least respond to one of each streams with a negative reply to get some understanding of what it takes to fix this.
By: frawd (frawd) 2010-08-12 18:13:59

Were there any advances or does anyone currently work on this issue?
By: Leif Madsen (lmadsen) 2011-07-26 14:57:12.891-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!