[asterisk-bugs] [Asterisk 0015407]: Multiple m=video or m=audio lines cause a ip port number mismatch.

Wed Sep 2 14:32:30 CDT 2009

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15407 
====================================================================== 
Reported By:                arunpunj
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   15407
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-06-26 10:04 CDT
Last Modified:              2009-09-02 14:32 CDT
====================================================================== 
Summary:                    Multiple m=video or m=audio lines cause a ip port
number mismatch.
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 at 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
====================================================================== 

---------------------------------------------------------------------- 
 (0110072) arunpunj (reporter) - 2009-09-02 14:32
 https://issues.asterisk.org/view.php?id=15407#c110072 
---------------------------------------------------------------------- 
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 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-09-02 14:32 arunpunj       Note Added: 0110072                          
======================================================================