[svn-commits] mmichelson: branch mmichelson/correct_sdp_answer r206560 - /team/mmichelson/c...

[SVN commits to the Digium repositories]

Author: mmichelson
Date: Tue Jul 14 14:03:10 2009
New Revision: 206560

URL: http://svn.asterisk.org/svn-view/asterisk?view=rev&rev=206560
Log:
First shot at recording the media types offered in an SDP.


Modified:
    team/mmichelson/correct_sdp_answer/channels/chan_sip.c

Modified: team/mmichelson/correct_sdp_answer/channels/chan_sip.c
URL: http://svn.asterisk.org/svn-view/asterisk/team/mmichelson/correct_sdp_answer/channels/chan_sip.c?view=diff&rev=206560&r1=206559&r2=206560
==============================================================================
--- team/mmichelson/correct_sdp_answer/channels/chan_sip.c (original)
+++ team/mmichelson/correct_sdp_answer/channels/chan_sip.c Tue Jul 14 14:03:10 2009
@@ -1033,6 +1033,21 @@
 	struct sip_invite_param *options;	/*!< Options for INVITE */
 	int autoframing;
 	int hangupcause;			/*!< Storage of hangupcause copied from our owner before we disconnect from the AST channel (only used at hangup) */
+	/*! When receiving an SDP offer, it is important to take note of what media types were offered.
+	 * By doing this, even if we don't want to answer a particular media stream with something meaningful, we can
+	 * still put an m= line in our answer with the port set to 0.
+	 *
+	 * The reason for the length being 3 is that in this branch of Asterisk, the only media types supported are 
+	 * image, audio, and video. Therefore we need to keep track of which types of media were offered.
+	 *
+	 * Note that if we wanted to be 100% correct, we would keep a list of all media types offered. That way we could respond
+	 * even to unknown media types, and we could respond to multiple streams of the same type. Such large-scale changes
+	 * are not a good idea for released branches, though, so we're compromising by just making sure that for the common cases:
+	 * audio and video, and audio and T.38, we give the appropriate response to both media streams.
+	 *
+	 * The large-scale changes would be a good idea for implementing during an SDP rewrite.
+	 */
+	int offered_media[3];
 } *iflist = NULL;
 
 /*! Max entires in the history list for a sip_pvt */
@@ -5147,6 +5162,7 @@
 enum media_type {
 	SDP_AUDIO,
 	SDP_VIDEO,
+	SDP_IMAGE,
 };
 
 static int get_ip_and_port_from_sdp(struct sip_request *req, const enum media_type media, struct sockaddr_in *sin)
@@ -5273,6 +5289,7 @@
 	/* Update our last rtprx when we receive an SDP, too */
 	p->lastrtprx = p->lastrtptx = time(NULL); /* XXX why both ? */
 
+	memset(p->offered_media, 0, sizeof(p->offered_media));
 
 	/* Try to find first media stream */
 	m = get_sdp(req, "m");
@@ -5316,6 +5333,7 @@
 		if ((sscanf(m, "audio %d/%d RTP/AVP %n", &x, &numberofports, &len) == 2 && len > 0) ||
 		    (sscanf(m, "audio %d RTP/AVP %n", &x, &len) == 1 && len > 0)) {
 			audio = TRUE;
+			p->offered_media[SDP_AUDIO] = 1;
 			numberofmediastreams++;
 			/* Found audio stream in this media definition */
 			portno = x;
@@ -5337,7 +5355,8 @@
 		} 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)) {
 			/* If it is not audio - is it video ? */
-			ast_clear_flag(&p->flags[0], SIP_NOVIDEO);	
+			ast_clear_flag(&p->flags[0], SIP_NOVIDEO);
+			p->offered_media[SDP_VIDEO] = 1;
 			numberofmediastreams++;
 			vportno = x;
 			/* Scan through the RTP payload types specified in a "m=" line: */
@@ -5354,6 +5373,7 @@
 		 (sscanf(m, "image %d UDPTL t38%n", &x, &len) == 1 && len >= 0) )) {
 			if (debug)
 				ast_verbose("Got T.38 offer in SDP in dialog %s\n", p->callid);
+			p->offered_media[SDP_IMAGE] = 1;
 			udptlportno = x;
 			numberofmediastreams++;