[Asterisk-video] Broken scenarios audio/video

John Martin John.Martin at AuPix.com
Thu Jun 1 15:57:47 MST 2006


Hi Olle (folks),
 To get us going on this tomorrow here's a patch to the sdpcleanup
(31495) branch that I think will help. I'm not completely sure I've got
a full set of changes that are required but it's a proposal for
discussion at least. 
These changes don't fix any scenarios where the called endpoint has a
lower capability than the calling endpoint, (i.e. it will not fix Lisa
calling any of the other endpoints in Olle's scenarios. To fix this you
need to add a reverse capability from the called endpoint back to the
calling endpoint... and that's a whole other story).

John

So some notes on the changes are, broadly speaking:
chan_sip.c:
----------
sip_call() - I don't think we should blindly overwrite the
jointcapability without considering if jointcapability already has
something meaningful in it. Sip_call() can be called with a channel that
already has a meaningful capabilities set, so use them.
The SLINEAR clause is needed because there are lots of places where
calls are instigated with a SLINEAR cap that could get through to the
endpoint unless filtered out (thanks to Neil(fenlander) for helping with
this one). This can happen, for instance, when a CLI or Manager
ORIGINATE is made.

sip_new() - I'd done a similar thing to Olle to decide if we needvideo
(my video variable below) but I think we need to go further in deciding
which video capability to use.

Channel.c:
----------
ast_request() needs to pass on video capabilities to a channel driver
when making a call. ast_translator_best_choice() should only return with
an audio codec (see points on translate.h below) so we would lose the
video cap without this fix.

Translate.h
-----------
MAX_FORMAT. As far as I can see the functions that use MAX_FORMAT (and
probably all the functions in translate.c) are concerned with
translating audio codecs. Therefore, since chan->nativeformats will more
likely have a video part to it, MAX_FORMAT should be set to the bit
position of the highest audio codec, not the MSB of an int. In the
versions of Ast that I've been running (and I haven't tried this against
the very latest trunk yet) if ast_translate_best_codec is presented with
a chan->nativeformat that contains a video cap it would return a video
codec (because they're in the higher bit positions of
chan->nativeformat) and so the translation processes later on in a call
would fail saying something like - no translation path... I think this
fix is otherwise benign.

John

Index: channel.c
===================================================================
--- channel.c	(revision 31495)
+++ channel.c	(working copy)
@@ -2634,6 +2634,9 @@
 			AST_LIST_UNLOCK(&channels);
 			return NULL;
 		}
+
+		capabilities = capabilities | (format &
AST_FORMAT_VIDEO_MASK);
+
 		AST_LIST_UNLOCK(&channels);
 		if (!chan->tech->requester)
 			return NULL;
Index: channels/chan_sip.c
===================================================================
--- channels/chan_sip.c	(revision 31495)
+++ channels/chan_sip.c	(working copy)
@@ -2440,7 +2440,13 @@
 	res = update_call_counter(p, INC_CALL_RINGING);
 	if ( res != -1 ) {
 		p->callingpres = ast->cid.cid_pres;
-		p->jointcapability = p->capability;
+		/* Do a quick capability check to see if we're
compatible */
+		if (p->jointcapability == AST_FORMAT_SLINEAR)	{
+			ast_verbose("Assuming Originate. Formats we're
not goint to resolve, so fallback to conf caps\n");
+			ast_log(LOG_DEBUG, "Assuming Originate. Formats
we're not goint to resolve, so fallback to conf caps\n");
+			p->jointcapability = p->capability;
+		} else if(!((p->jointcapability & p->capability) &
AST_FORMAT_AUDIO_MASK))
+			p->jointcapability = p->capability;
 		transmit_invite(p, SIP_INVITE, 1, 2);
 		if (p->maxtime) {
 			/* Initialize auto-congest time */
@@ -3258,6 +3264,7 @@
 	int fmt;
 	int what;
 	int needvideo = 0;
+	int video = 0;
 	
 	ast_mutex_unlock(&i->lock);
 	/* Don't hold a sip pvt lock while we allocate a channel */
@@ -3272,13 +3279,25 @@
 	/* Select our native format based on codec preference until we
receive
 	   something from another device to the contrary. */
 	if (i->jointcapability)
+	{
 		what = i->jointcapability;
+		video = i->jointcapability & AST_FORMAT_VIDEO_MASK;
+  	ast_verbose("SIP: joint->sip_new what is %08x, video is %08x\n",
what, video);
+	}
 	else if (i->capability)
+	{
 		what = i->capability;
+		video = i->capability & AST_FORMAT_VIDEO_MASK;
+  	ast_verbose("SIP: cap->sip_new what is %08x, video is %08x\n",
what, video);
+	}
 	else
+	{
 		what = global_capability;
+		video = global_capability & AST_FORMAT_VIDEO_MASK;
+  	ast_verbose("SIP: global->sip_new what is %08x, video is
%08x\n", what, video);
+	}
+	tmp->nativeformats = ast_codec_choose(&i->prefs, what, 1) |
video;
 
-	tmp->nativeformats = ast_codec_choose(&i->prefs, what, 1) |
(i->jointcapability & AST_FORMAT_VIDEO_MASK);
 	if (option_debug) {
 		char buf[BUFSIZ];
 		ast_log(LOG_DEBUG, "*** Our native formats are %s \n",
ast_getformatname_multiple(buf, BUFSIZ, tmp->nativeformats));
Index: include/asterisk/translate.h
===================================================================
--- include/asterisk/translate.h	(revision 31495)
+++ include/asterisk/translate.h	(working copy)
@@ -23,7 +23,7 @@
 #ifndef _ASTERISK_TRANSLATE_H
 #define _ASTERISK_TRANSLATE_H
 
-#define MAX_FORMAT 32
+#define MAX_FORMAT 15
 
 #if defined(__cplusplus) || defined(c_plusplus)
 extern "C" {


-----Original Message-----
From: asterisk-video-bounces at lists.digium.com
[mailto:asterisk-video-bounces at lists.digium.com] On Behalf Of Olle E
Johansson
Sent: 01 June 2006 17:01
To: Discussion in Asterisk of video media support
Subject: [Asterisk-video] Broken scenarios audio/video

John and I talked about broken scenarios with Asterisk and video  
today. These are ones we
came up with:

A. Audio only phone - peer Gustav with no video support
B. Video phone with H.263 - peer Anna with video support enabled
C. Video phone with H.264 - peer Laban with video support enabled and  
H.264 codec added
D. Video phone with H.263 and H.264 - peer Lisa with video support  
enabled and H.264 codec added

1. Audio phone Gustav calls peer Anna
    Asterisk will offer video to Anna

2. Video phone Anna calls gustav
    Will Asterisk properly deny video?

3. Video phone Anna calls Laban, Lisa and Gustav
     If Laban answers - will Asterisk offer transcoding services?
     If Lisa answers - which codec will be offered in the 200 OK to Anna
     If Gustav answers - will the 200 OK refuse the video m= stream  
properly?

4. Video phone Anna calls Lisa
     Will Asterisk only offer H.263 to Lisa?

We will try working on this tomorrow and see if there are easy fixes  
for obvious bugs
that can be fixed in 1.4. If anyone has additional failure scenarios  
you are welcome to add,
test and help out!

/O


_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-video mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-video




More information about the asterisk-video mailing list