2 Commits (6bfd4816249dadebe4513d5aeaf1cef310c29dd8)

Author	SHA1	Message	Date
Andrew Pogrebennyk	ef583e130a	MT#5971 send m= line with port=0 in SDP answer if offer had unsupported media type ... Closes issue ASTERISK-11840 / MT#5971 Also imported r197588 for this patch to apply cleanly. Revision: 207423 U branches/1.4/channels/chan_sip.c r207423 | mmichelson | 2009-07-20 14:40:01 -0500 (Mon, 20 Jul 2009) | 33 lines Answer video SDP offers properly when videosupport is not enabled. Copied from Review board: In issue 12434, the reporter describes a situation in which audio and video is offered on the call, but because videosupport is disabled in sip.conf, Asterisk gives no response at all to the video offer. According to RFC 3264, all media offers should have a corresponding answer. For offers we do not intend to actually reply to with meaningful values, we should still reply with the port for the media stream set to 0. In this patch, we take note of what types of media have been offered and save the information on the sip_pvt. The SDP in the response will take into account whether media was offered. If we are not otherwise going to answer a media offer, we will insert an appropriate m= line with the port set to 0. It is important to note that this patch is pretty much a bandage being applied to a broken bone. The patch only helps for situations where video is offered but videosupport is disabled and when udptl_pt is disabled but T.38 is offered. Asterisk is not guaranteed to respond to every media offer. Notable cases are when multiple streams of the same type are offered. The 2 media stream limit is still present with this patch, too. In trunk and the 1.6.X branches, things will be a bit different since Asterisk also supports text in SDPs as well. (closes issue ASTERISK-11840) Reported by: mnnojd ------------------------------------------------------------------------ r197588 | mmichelson | 2009-05-28 23:27:49 +0800 (Thu, 28 May 2009) | 16 lines Allow for media to arrive from an alternate source when responding to a reinvite with 491. When we receive a SIP reinvite, it is possible that we may not be able to process the reinvite immediately since we have also sent a reinvite out ourselves. The problem is that whoever sent us the reinvite may have also sent a reinvite out to another party, and that reinvite may have succeeded. As a result, even though we are not going to accept the reinvite we just received, it is important for us to not have problems if we suddenly start receiving RTP from a new source. The fix for this is to grab the media source information from the SDP of the reinvite that we receive. This information is passed to the RTP layer so that it will know about the alternate source for media. Review: https://reviewboard.asterisk.org/r/252 (cherry picked from commit 69c088172d)	12 years ago
Jon Bonilla	bd15a4cb1f	Change asterisk folders to match policy	15 years ago