[Home]

Summary:ASTERISK-11840: Handle wrong at offer/answer in sdp in media description(m=)
Reporter:Magnus Nordström (mnnojd)Labels:
Date Opened:2008-04-14 03:08:35Date Closed:2009-07-24 09:36:26
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Asterisk answering sdp is not correct in some cases.

If settings in Asterisk is to use only audio. And then if a client have audio and video. I have seen that Asterisk do not answer correct in sdp in media description (m=). If there is some medias which Asterisk can not handle it should answer with the media and set port to 0. Today Asterisk answer only with the medias this is set to use.

I have seen this problem on Asterisk 1.6.0-beta7.1.




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

If Asterisk is configured to only use audio and a client with audio, video and text call via Asterisk and switches to a client with audio, video and text, the sdp from the client looks like this(only media description m=);

CLIENT A CALL ASTERISK;

Request: INVITE
sdp...
Media Description, name and address (m): audio 35794 RTP/AVP 9 4 8 0
Media Attribute (a): rtpmap:9 G722/8000
...
...
...
Media Description, name and address (m): video 35796 RTP/AVP 34 31
Media Attribute (a): rtpmap:34 H263/90000
...
...
...
Media Description, name and address (m): text 35814 RTP/AVP 99 98
Media Attribute (a): rtpmap:99 RED/1000
...
...
...

ASTERISK CALL CLIENT B;

Request: INVITE
sdp...
Media Description, name and address (m): audio 12422 RTP/AVP 0 8
Media Attribute (a): rtpmap:0 PCMU/8000
...
...
...

CLIENT B ANSWER ASTERISK;

Status: 200 OK
sdp...
Media Description, name and address (m): audio 35816 RTP/AVP 8 0
Media Attribute (a): rtpmap:8 PCMA/8000
...
...
...

ASTERISK ANSWER CLIENT A;

Status: 200 OK
sdp...
Media Description, name and address (m): audio 17978 RTP/AVP 0 8
Media Attribute (a): rtpmap:0 PCMU/8000
...
...
...


The correct answer from Asterisk to client A should be like this;

Status: 200 OK
sdp...
Media Description, name and address (m): audio 17978 RTP/AVP 0 8
Media Attribute (a): rtpmap:0 PCMU/8000
...
...
...
Media Description, name and address (m): video 0 RTP/AVP 34 31
Media Attribute (a): rtpmap:34 H263/90000
...
...
...
Media Description, name and address (m): text 0 RTP/AVP 99 98
Media Attribute (a): rtpmap:99 RED/1000
...
...
...

In RFC 3264 about offer/answer model with the Session Description Protocol (SDP), you find;

section 6 Generating an answer.
..
  For each "m=" line in the offer, there MUST be a corresponding "m="
  line in the answer.  The answer MUST contain exactly the same number
  of "m=" lines as the offer.  This allows for streams to be matched up
  based on their order.  This implies that if the offer contained zero
  "m=" lines, the answer MUST contain zero "m=" lines.
..
 
  An offered stream MAY be rejected in the answer, for any reason.  If
  a stream is rejected, the offerer and answerer MUST NOT generate
  media (or RTCP packets) for that stream.  To reject an offered
  stream, the port number in the corresponding stream in the answer
  MUST be set to zero.  Any media formats listed are ignored.  At least
  one MUST be present, as specified by SDP.
..

Comments:By: Olle Johansson (oej) 2008-07-01 10:03:35

This is a well known issue that is hard to fix, but is on the list of "todo's". Thanks for reporting it and my apologies that no-one has responded.
By: Leif Madsen (lmadsen) 2008-12-04 15:31:40.000-0600

Is this a duplicate bug of other open issues, or is this the only issue open reporting this bug?

Thanks!
By: Christer (epicac) 2009-02-12 05:00:38.000-0600

As far as I can see this is not a duplicate of any other open issue.

Thanks!
By: Olle Johansson (oej) 2009-02-12 07:54:53.000-0600

Well, with or without a bug report, it's a well known issue. We're working on a new media handling architecture that will hopefully handle this, as to solve this we have to work ourselves down the core. THis has been the target of the work with Videocaps since more than two years and the work done on astridevcon this year.
By: Digium Subversion (svnbot) 2009-07-20 14:40:01

Repository: asterisk
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

Review: https://reviewboard.asterisk.org/r/311
Review: https://reviewboard.asterisk.org/r/313


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=207423
By: Digium Subversion (svnbot) 2009-07-20 14:48:15

Repository: asterisk
Revision: 207424

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r207424 | mmichelson | 2009-07-20 14:48:15 -0500 (Mon, 20 Jul 2009) | 39 lines

Merged revisions 207423 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r207423 | mmichelson | 2009-07-20 14:39:59 -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
 
 Review: https://reviewboard.asterisk.org/r/311
 Review: https://reviewboard.asterisk.org/r/313
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=207424
By: Digium Subversion (svnbot) 2009-07-20 14:55:32

Repository: asterisk
Revision: 207425

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_sip.c

------------------------------------------------------------------------
r207425 | mmichelson | 2009-07-20 14:55:31 -0500 (Mon, 20 Jul 2009) | 46 lines

Merged revisions 207424 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r207424 | mmichelson | 2009-07-20 14:48:12 -0500 (Mon, 20 Jul 2009) | 39 lines
 
 Merged revisions 207423 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r207423 | mmichelson | 2009-07-20 14:39:59 -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
   
   Review: https://reviewboard.asterisk.org/r/311
   Review: https://reviewboard.asterisk.org/r/313
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=207425
By: Digium Subversion (svnbot) 2009-07-20 15:02:06

Repository: asterisk
Revision: 207426

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c

------------------------------------------------------------------------
r207426 | mmichelson | 2009-07-20 15:02:06 -0500 (Mon, 20 Jul 2009) | 46 lines

Merged revisions 207424 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r207424 | mmichelson | 2009-07-20 14:48:12 -0500 (Mon, 20 Jul 2009) | 39 lines
 
 Merged revisions 207423 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r207423 | mmichelson | 2009-07-20 14:39:59 -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
   
   Review: https://reviewboard.asterisk.org/r/311
   Review: https://reviewboard.asterisk.org/r/313
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=207426
By: Digium Subversion (svnbot) 2009-07-20 17:14:12

Repository: asterisk
Revision: 207523

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r207523 | mmichelson | 2009-07-20 17:14:12 -0500 (Mon, 20 Jul 2009) | 46 lines

Merged revisions 207424 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r207424 | mmichelson | 2009-07-20 14:48:12 -0500 (Mon, 20 Jul 2009) | 39 lines
 
 Merged revisions 207423 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r207423 | mmichelson | 2009-07-20 14:39:59 -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
   
   Review: https://reviewboard.asterisk.org/r/311
   Review: https://reviewboard.asterisk.org/r/313
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=207523