Posted: Tue May 16, 2006 12:53 pm Post subject: [Asterisk-video] RE: AVTF - What's going on?
Hi All,
I know you're all a long way into video for Asterisk in some way or
other but I thought I'd outline what we're trying to do, what we've got
going and what we're still playing with. If everyone is prepared to show
and tell then perhaps we can figure out where we should be going and how
to get there... sorry if this ends up being a rather long winded mail.
So what are AuPix trying to achieve?
We have a number of customers that would like to use our video phones in
Asterisk but have been missing a way of doing the sort of things that
you would normally expect of a phone but with video tacked on. Our
phones support SIP and H.323 so that's what we've majored on. We have
customers doing regular telephony stuff and ones doing contact center
things, so we needed to address all of this in Asterisk.
So what'a working?:
Well we've been adding video things to SIP and H.323 since Asterisk
1.0.7. Initially it was simple stuff like assuming H.263, CIF, MPI=1,
that sort of thing, and building from there. In various Asterisk
releases we've found things get broken, (i.e since around 1.2.something
we found that chan->nativeformats got a bit more intelligent and so
broke a number of channel cap exchanges) so we fix and patch as we go.
As of today the following have been changed, tweaked, hacked or
generally man handled by us:
Chan_sip:
- maxcallbitrate: a basic way of telling an endpoint what bitrate it
should use (our videophones can do 2Mbps and so assuming such a rate for
a DSL connection was never going to make for great call quality, see
RTCP below). This should be superseded by a better capability mechanism.
- per peer videosupport: some carriers really barf when you send them a
video cap so we needed a way of allowing some endpoints to have video
support and some not (i.e. internal extensions have video but some
external trunks only audio).
- per peer INFO or RTCP fast update requests: again some switches don't
appreciate SIP info messages with XML in them as the Fast Update Request
mechanism, so we added a per peer support way of selecting between
sending SIP INFO with XML or by doing RTCP 192 (which is an old H.261
way of doing FUR) again see RTCP below.
- Process SDP: we have a simple way of extracting video fmtp lines from
SDP. It's a bit ugly and has little awareness of SDP scope at the moment
but it does extract fmtp for H.261, H.263 and H.264 into a common
ast_capabilities (see channel.c below).
- Build SDP: having extracted the fmtp lines and put them in a struct we
pass the struct around to the called endpoints (changes to the bridging
functions in channel.c) to limit their cap. We do a min() on confcap,
peercap and chancap to determine a maximum jointcap that an endpoint
will be allowed to generate once it gets an ack with SDP - don't get us
going on early media responses because it breaks some switches that
should know better.
- Video capability in SIP.conf: we use the h.261/3 fmtp definitions to
specify video capabilities in the conf file. i.e. you can specify lines
like:
H261=CIF=1 QCIF=2 CIF16=4 MaxBR=2024 framerate=25
H263=CIF=1 QCIF=2 CIF16=4 QVGA MaxBR=2024 A/B/C
Etc.
I know you wouldn't normally do an MPI and framerate but we support it.
We also allow for incorrectly formatted fmtp like some vendors are want
to do.
Chan_h323:
- Well we added video for a start, sounds like others have been having
similar fun too :-) . We also added the same maxcallbitrate and per peer
videosupport as for SIP.
- H.261, H.263 and nearly H.264 (I've got H.264 doing all the cap
exchanges and getting the media channels running, I'm just patching in
all the dynamic RTP stuff needed by Asterisk, h.323 is doing dynamicRTP
- I just need to let Asterisk know about it. If anyone else has got
H.264 going I'd love to see their approach).
- There's also the beginnings of the same fmtp like conf options for
H.323 in the conf file.
- Fast update requests received and transmitted.
- Fixes in H.323 for various Tandberg endpoints that don't like the way
chan_h323 used to do port reflection (this is a pain for NAT support but
most of our customers with H.323 seem to have stuck with DMZ or public
IP address as the work around for NAT on H.323).
- Video codecs are now broken out into their own files: ast_h26x.cpp and
the makefile fixed to allow the links to *.cxx to work.
- Logger support is also broken out into it's own file.
- We're currently using RFC2190 support for H.263 but I think we'll do
our own capability for that in the next few days.
Chan_local:
- it just needs a .write_video in the channel tech to get this working
(I think that was all, I'd have to do a diff to see if we fixed anything
else).
Chan_agent:
- similar to chan_local (.write_video) but I think there may have been a
bit more required.
App_echo:
- simply added a ast_indicate at the front of the app so that if you do
a playback or IVR before hitting app_echo then you don't get any
breakthrough on some endpoints.
Func_stringtoip:
- this is one of our own creations that allows a user to be registered
with chan_sip, or with a gatekeeper, and enter some arbitrary IP address
like 10*1*1*1, or 010001001001, to make a call to 10.1.1.1 (I know that
should be an internal IP address, replace with the public IP address of
your choice). This is useful when you're supporting local extensions
that want to talk to, for instance, lots of D-Link i2eyes that are all
essentially sitting in the DMZ of a CPE router and not registered. I
guess this could have been done in a set of dialplan apps but I'd rather
do in in C.
RTP.c:
Hmmmm.... lots of very good work was done on this before we shoved our
nose into it. We only added a few tweaks to RTP.c for RTCP but I think
it works now when video is involved too.
- RTP.c was seg faulting when the channel drivers shut down the RTP
layer but the RTCP timers were still going - no prizes for guessing that
the timer routine barfed when it tried to access the non-existent rtp
structs.
- Tidied up the parsing of the RTCP compound packets so that it worked.
- Generate compound RTCP packets (you should always send at least two
packets so we added a dummy SDES - it should really be filled in).
- FUR now generated from the channel drivers if they want it. Our
chan_sip decides whether to do it this way or with sip info. Some sort
of auto refelction should be possible but it may not always be reliable.
- FUR reported back to the channel drivers, thanks to Neil Stratford for
pointing out a blindingly obvious way of doing it that us mere mortals
had completely missed.
- Fixed up some report errors on seqno wraparound etc.
- A bit more of a troublesome problem for us has been seqno
resequencing. Asterisk puts it's own sequence numbers into outbound RTP
packets and ignores the inbound ones. This is generally fine for audio
but we found that the lumpy nature of high bandwidth video calls could
produce packet races (packets get swapped in transit to Asterisk)
through the internet but Ast would renumber the outbound packets. This,
of course, means that when the packet hits the target endpoint (having
passed through Asterisk) it's actually out of sequence but the endpoint
has no way of knowing that because all the seqno's are sequential
(unless there's been an Ast to target swap aswell!). We've added support
for seqno being added to ast_frame so that the RTP layer can use the
inbound seqno if it's available. This gets complex with IVR and other
file playback functions. Our solution can also cause large seqno jumps
when going from file playback to live video, which some endpoints will
crash on... the RFC says they shouldn't ;-) This fix isn't in Olle's
RTCP branch as I thought it might be a little too dangerous.
- RTCP report frequency in conf: The rtp.conf now supports an
rtcpinterval=x ms setting to set how often rtcp reports are generated.
The default 5000msecs isn't really enough to be handling video rate
control. I think the RFC recommends that 5% of packets should be RTCP
reports - that seemed a bit high to us, but sending one every 5 seconds
when you've sent over 3000 video packets in that time (0.03%) seemed too
low too :-)
- DTMF tones (not really a video one this, but I'm on a roll so bear
with me): I think there might be something very wrong with the DTMF tone
generation in Asterisk. We get a lot of complaints about it and have
tweaked what's there to improve things. We're waiting for Kevins's
variable length DTMF support 'cos I'm sure that'll be much better.
Channel.c/h
- We've come up with a struct to store all the new video caps in. It
looks like this but I'm sure there'll be lots of views on the way it
should be done and propagated around Asterisk (the codecnegociation
branch would maybe be a good start)
/*! \brief ast_video_cap: Struct holding video capabilities */ struct
ast_h2613_video_cap {
int valid;
/*!< 1 = This codec is specified, 0 = not specified */
unsigned int annexes;
/*!< Video annexes - stored as bitfield 2^(annex-ascii(A))*/
unsigned int maxframerates[MAX_VIDEO_SIZES]; /*!< Maximum
framerate (framerate = 30/mpi) */
unsigned int maxbr;
/*!< Maximum supported bitrate for this capability */
};
/*! \brief ast_h264_video_cap: Struct holding video capabilities */
struct ast_h264_video_cap {
unsigned int flags; /*!< Video flags
*/
unsigned int level; /*!< Profile
level */
unsigned int maxmbps; /*!< Maximum number of
macroblocks per second */
unsigned int minfs; /*!< Minimum
frame size in macroblocks */
unsigned int maxfs; /*!< Maximum
frame size in macroblocks */
unsigned int maxcpb; /*!< Maximum coded
picture buffer size in units of 1000 bits (1200 NAL HRD)*/
unsigned int maxdpb; /*!< Maximum decoded
picture buffer size in units of 1024 bytes */
unsigned int packet_mode; /*!< Packetisation mode */
unsigned int maxbr; /*!< Maximum
supported bitrate for this capability */
};
/*! \brief ast_video_capabilities: Struct holding all video capabilities
*/ struct ast_video_capabilities {
unsigned int maxbitrate; /*!< Max video bitrate */
struct ast_h2613_video_cap h261; /*!< H261 video capabilities
*/
struct ast_h2613_video_cap h263; /*!< H263 video capabilities
*/
struct ast_h264_video_cap h264; /*!< H264 video capabilities
*/ };
/*! \brief ast_video_capabilities: Struct holding all video capabilities
*/ struct ast_capabilities {
int maxcallbitrate;
/*!< Max allowed bitrate for this channel */
struct ast_video_capabilities videocaps; /*!< video
capabilities */ };
I think that's enough for now... if I've still got any of you with me
then perhaps the future of what we're up to can come another time....
-----Original Message-----
From: Olle E Johansson [mailto:registry@webway.se]
Sent: 16 May 2006 10:13
To: asterisk-video@edvina.net
Subject: AVTF - What's going on?
This is stuff going on that I'm aware of:
* I am working on fixes for SIP/SDP in the sdpcleanup branch.
Grandstream and Foniris generously
donated video phones for me to test with. I am implementing some
checks if we really have
video on the incoming call before we offer it on the outbound
call. Seems stupid to offer
video without a stream. If we can fix this stuff and test it
quickly, I can get it into 1.4.
* John Martin contributed some patches for FMTP support that is
needed. Will open a branch
for this hopefully this week. This is too late for 1.4, but will
have to be part of 1.6. It will require
some architectural changes, and we're beyond freeze for that.
* John Martin is also doing work on H.323 and video
What else is going on codewise or should be added to the wish list?
Posted: Tue May 16, 2006 2:19 pm Post subject: [Asterisk-video] RE: AVTF - What's going on?
Hey Sergio,
Sounds cool. We did our own H.324 stack a few years back but V.34 wasn't really up to the requirements of video back then, there's a knee in the quality/bitrate graph for H.263 at around 40kbps that 3G should be able to take advantage of and of course H.264 is made for it.
I think I've seen some posts from you in the past on the subject, where can we find out more about your work? Do you think you'll be able to match the likes of Dilithium and RadVision, they both have some interesting transcoding options.
-----Original Message-----
From: Sergio Garc?a Murillo [mailto:Sergio.Garcia@ydilo.com]
Sent: 16 May 2006 16:29
To: Olle E Johansson; asterisk-video@edvina.net
Subject: RE: AVTF - What's going on?
Olle E Johansson wrote:
Quote:
This is stuff going on that I'm aware of:
Hi everyone!
I'm currently involved in the development of an H324M video gateway over asterisk, It's currently in a very early stage, but I hope to have something to show soon.
By the way, which is the current status of video support in asterisk (channels,features,formats & codecs,transcoding,etc)?
Greetings
Sergio
--------------------------------------------------------------------------------------
This message and any files transmitted with it are confidential and intended solely
for the use of the individual or entity to whom they are addressed. No confidentiality
or privilege is waived or lost by any wrong transmission.
If you have received this message in error, please immediately destroy it and kindly
notify the sender by reply email.
You must not, directly or indirectly, use, disclose, distribute, print, or copy any
part of this message if you are not the intended recipient. Opinions, conclusions and
other information in this message that do not relate to the official business of
Ydilo Advanced Voice Solutions, S.A. shall be understood as neither given nor endorsed by it.
--------------------------------------------------------------------------------------
Posted: Tue May 16, 2006 2:43 pm Post subject: [Asterisk-video] RE: AVTF - What's going on?
Quote:
We have a number of customers that would like to use our video phones in
Asterisk but have been missing a way of doing the sort of things that
you would normally expect of a phone but with video tacked on.
To be honest with you, with that huge touch screen of yours, what
would make aupix a much more asterisk friendly phone is if it
supported easy application development, the phones are nice but if you
embedded a web browser, possibly the flash player or a nice simple and
free (as in cash) java api to an asterisk manager proxy it would take
advantage of your console for some amazing asterisk based
applications. For sure its more important to business now than video
support.
If you don't have time for something like that contact me off list,
thats something my company would enjoy collaborating with you on.
---
Shidan
On 5/16/06, John Martin <John.Martin@aupix.com> wrote:
Quote:
Hi All,
I know you're all a long way into video for Asterisk in some way or
other but I thought I'd outline what we're trying to do, what we've got
going and what we're still playing with. If everyone is prepared to show
and tell then perhaps we can figure out where we should be going and how
to get there... sorry if this ends up being a rather long winded mail.
So what are AuPix trying to achieve?
We have a number of customers that would like to use our video phones in
Asterisk but have been missing a way of doing the sort of things that
you would normally expect of a phone but with video tacked on. Our
phones support SIP and H.323 so that's what we've majored on. We have
customers doing regular telephony stuff and ones doing contact center
things, so we needed to address all of this in Asterisk.
So what'a working?:
Well we've been adding video things to SIP and H.323 since Asterisk
1.0.7. Initially it was simple stuff like assuming H.263, CIF, MPI=1,
that sort of thing, and building from there. In various Asterisk
releases we've found things get broken, (i.e since around 1.2.something
we found that chan->nativeformats got a bit more intelligent and so
broke a number of channel cap exchanges) so we fix and patch as we go.
As of today the following have been changed, tweaked, hacked or
generally man handled by us:
Chan_sip:
- maxcallbitrate: a basic way of telling an endpoint what bitrate it
should use (our videophones can do 2Mbps and so assuming such a rate for
a DSL connection was never going to make for great call quality, see
RTCP below). This should be superseded by a better capability mechanism.
- per peer videosupport: some carriers really barf when you send them a
video cap so we needed a way of allowing some endpoints to have video
support and some not (i.e. internal extensions have video but some
external trunks only audio).
- per peer INFO or RTCP fast update requests: again some switches don't
appreciate SIP info messages with XML in them as the Fast Update Request
mechanism, so we added a per peer support way of selecting between
sending SIP INFO with XML or by doing RTCP 192 (which is an old H.261
way of doing FUR) again see RTCP below.
- Process SDP: we have a simple way of extracting video fmtp lines from
SDP. It's a bit ugly and has little awareness of SDP scope at the moment
but it does extract fmtp for H.261, H.263 and H.264 into a common
ast_capabilities (see channel.c below).
- Build SDP: having extracted the fmtp lines and put them in a struct we
pass the struct around to the called endpoints (changes to the bridging
functions in channel.c) to limit their cap. We do a min() on confcap,
peercap and chancap to determine a maximum jointcap that an endpoint
will be allowed to generate once it gets an ack with SDP - don't get us
going on early media responses because it breaks some switches that
should know better.
- Video capability in SIP.conf: we use the h.261/3 fmtp definitions to
specify video capabilities in the conf file. i.e. you can specify lines
like:
H261=CIF=1 QCIF=2 CIF16=4 MaxBR=2024 framerate=25
H263=CIF=1 QCIF=2 CIF16=4 QVGA MaxBR=2024 A/B/C
Etc.
I know you wouldn't normally do an MPI and framerate but we support it.
We also allow for incorrectly formatted fmtp like some vendors are want
to do.
Chan_h323:
- Well we added video for a start, sounds like others have been having
similar fun too :-) . We also added the same maxcallbitrate and per peer
videosupport as for SIP.
- H.261, H.263 and nearly H.264 (I've got H.264 doing all the cap
exchanges and getting the media channels running, I'm just patching in
all the dynamic RTP stuff needed by Asterisk, h.323 is doing dynamicRTP
- I just need to let Asterisk know about it. If anyone else has got
H.264 going I'd love to see their approach).
- There's also the beginnings of the same fmtp like conf options for
H.323 in the conf file.
- Fast update requests received and transmitted.
- Fixes in H.323 for various Tandberg endpoints that don't like the way
chan_h323 used to do port reflection (this is a pain for NAT support but
most of our customers with H.323 seem to have stuck with DMZ or public
IP address as the work around for NAT on H.323).
- Video codecs are now broken out into their own files: ast_h26x.cpp and
the makefile fixed to allow the links to *.cxx to work.
- Logger support is also broken out into it's own file.
- We're currently using RFC2190 support for H.263 but I think we'll do
our own capability for that in the next few days.
Chan_local:
- it just needs a .write_video in the channel tech to get this working
(I think that was all, I'd have to do a diff to see if we fixed anything
else).
Chan_agent:
- similar to chan_local (.write_video) but I think there may have been a
bit more required.
App_echo:
- simply added a ast_indicate at the front of the app so that if you do
a playback or IVR before hitting app_echo then you don't get any
breakthrough on some endpoints.
Func_stringtoip:
- this is one of our own creations that allows a user to be registered
with chan_sip, or with a gatekeeper, and enter some arbitrary IP address
like 10*1*1*1, or 010001001001, to make a call to 10.1.1.1 (I know that
should be an internal IP address, replace with the public IP address of
your choice). This is useful when you're supporting local extensions
that want to talk to, for instance, lots of D-Link i2eyes that are all
essentially sitting in the DMZ of a CPE router and not registered. I
guess this could have been done in a set of dialplan apps but I'd rather
do in in C.
RTP.c:
Hmmmm.... lots of very good work was done on this before we shoved our
nose into it. We only added a few tweaks to RTP.c for RTCP but I think
it works now when video is involved too.
- RTP.c was seg faulting when the channel drivers shut down the RTP
layer but the RTCP timers were still going - no prizes for guessing that
the timer routine barfed when it tried to access the non-existent rtp
structs.
- Tidied up the parsing of the RTCP compound packets so that it worked.
- Generate compound RTCP packets (you should always send at least two
packets so we added a dummy SDES - it should really be filled in).
- FUR now generated from the channel drivers if they want it. Our
chan_sip decides whether to do it this way or with sip info. Some sort
of auto refelction should be possible but it may not always be reliable.
- FUR reported back to the channel drivers, thanks to Neil Stratford for
pointing out a blindingly obvious way of doing it that us mere mortals
had completely missed.
- Fixed up some report errors on seqno wraparound etc.
- A bit more of a troublesome problem for us has been seqno
resequencing. Asterisk puts it's own sequence numbers into outbound RTP
packets and ignores the inbound ones. This is generally fine for audio
but we found that the lumpy nature of high bandwidth video calls could
produce packet races (packets get swapped in transit to Asterisk)
through the internet but Ast would renumber the outbound packets. This,
of course, means that when the packet hits the target endpoint (having
passed through Asterisk) it's actually out of sequence but the endpoint
has no way of knowing that because all the seqno's are sequential
(unless there's been an Ast to target swap aswell!). We've added support
for seqno being added to ast_frame so that the RTP layer can use the
inbound seqno if it's available. This gets complex with IVR and other
file playback functions. Our solution can also cause large seqno jumps
when going from file playback to live video, which some endpoints will
crash on... the RFC says they shouldn't ;-) This fix isn't in Olle's
RTCP branch as I thought it might be a little too dangerous.
- RTCP report frequency in conf: The rtp.conf now supports an
rtcpinterval=x ms setting to set how often rtcp reports are generated.
The default 5000msecs isn't really enough to be handling video rate
control. I think the RFC recommends that 5% of packets should be RTCP
reports - that seemed a bit high to us, but sending one every 5 seconds
when you've sent over 3000 video packets in that time (0.03%) seemed too
low too :-)
- DTMF tones (not really a video one this, but I'm on a roll so bear
with me): I think there might be something very wrong with the DTMF tone
generation in Asterisk. We get a lot of complaints about it and have
tweaked what's there to improve things. We're waiting for Kevins's
variable length DTMF support 'cos I'm sure that'll be much better.
Channel.c/h
- We've come up with a struct to store all the new video caps in. It
looks like this but I'm sure there'll be lots of views on the way it
should be done and propagated around Asterisk (the codecnegociation
branch would maybe be a good start)
/*! \brief ast_video_cap: Struct holding video capabilities */ struct
ast_h2613_video_cap {
int valid;
/*!< 1 = This codec is specified, 0 = not specified */
unsigned int annexes;
/*!< Video annexes - stored as bitfield 2^(annex-ascii(A))*/
unsigned int maxframerates[MAX_VIDEO_SIZES]; /*!< Maximum
framerate (framerate = 30/mpi) */
unsigned int maxbr;
/*!< Maximum supported bitrate for this capability */
};
/*! \brief ast_h264_video_cap: Struct holding video capabilities */
struct ast_h264_video_cap {
unsigned int flags; /*!< Video flags
*/
unsigned int level; /*!< Profile
level */
unsigned int maxmbps; /*!< Maximum number of
macroblocks per second */
unsigned int minfs; /*!< Minimum
frame size in macroblocks */
unsigned int maxfs; /*!< Maximum
frame size in macroblocks */
unsigned int maxcpb; /*!< Maximum coded
picture buffer size in units of 1000 bits (1200 NAL HRD)*/
unsigned int maxdpb; /*!< Maximum decoded
picture buffer size in units of 1024 bytes */
unsigned int packet_mode; /*!< Packetisation mode */
unsigned int maxbr; /*!< Maximum
supported bitrate for this capability */
};
/*! \brief ast_video_capabilities: Struct holding all video capabilities
*/ struct ast_video_capabilities {
unsigned int maxbitrate; /*!< Max video bitrate */
struct ast_h2613_video_cap h261; /*!< H261 video capabilities
*/
struct ast_h2613_video_cap h263; /*!< H263 video capabilities
*/
struct ast_h264_video_cap h264; /*!< H264 video capabilities
*/ };
/*! \brief ast_video_capabilities: Struct holding all video capabilities
*/ struct ast_capabilities {
int maxcallbitrate;
/*!< Max allowed bitrate for this channel */
struct ast_video_capabilities videocaps; /*!< video
capabilities */ };
I think that's enough for now... if I've still got any of you with me
then perhaps the future of what we're up to can come another time....
-----Original Message-----
From: Olle E Johansson [mailto:registry@webway.se]
Sent: 16 May 2006 10:13
To: asterisk-video@edvina.net
Subject: AVTF - What's going on?
This is stuff going on that I'm aware of:
* I am working on fixes for SIP/SDP in the sdpcleanup branch.
Grandstream and Foniris generously
donated video phones for me to test with. I am implementing some
checks if we really have
video on the incoming call before we offer it on the outbound
call. Seems stupid to offer
video without a stream. If we can fix this stuff and test it
quickly, I can get it into 1.4.
* John Martin contributed some patches for FMTP support that is
needed. Will open a branch
for this hopefully this week. This is too late for 1.4, but will
have to be part of 1.6. It will require
some architectural changes, and we're beyond freeze for that.
* John Martin is also doing work on H.323 and video
What else is going on codewise or should be added to the wish list?
/Olle
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Posted: Tue May 16, 2006 2:45 pm Post subject: [Asterisk-video] RE: AVTF - What's going on?
Sorry about my off topic post everyone, I meant it just for the
original poster and sent it to the list by accident.
----
Shidan
On 5/16/06, Shidan <shidan@gmail.com> wrote:
Quote:
>We have a number of customers that would like to use our video phones in
> Asterisk but have been missing a way of doing the sort of things that
> you would normally expect of a phone but with video tacked on.
To be honest with you, with that huge touch screen of yours, what
would make aupix a much more asterisk friendly phone is if it
supported easy application development, the phones are nice but if you
embedded a web browser, possibly the flash player or a nice simple and
free (as in cash) java api to an asterisk manager proxy it would take
advantage of your console for some amazing asterisk based
applications. For sure its more important to business now than video
support.
If you don't have time for something like that contact me off list,
thats something my company would enjoy collaborating with you on.
---
Shidan
On 5/16/06, John Martin <John.Martin@aupix.com> wrote:
> Hi All,
> I know you're all a long way into video for Asterisk in some way or
> other but I thought I'd outline what we're trying to do, what we've got
> going and what we're still playing with. If everyone is prepared to show
> and tell then perhaps we can figure out where we should be going and how
> to get there... sorry if this ends up being a rather long winded mail.
>
> So what are AuPix trying to achieve?
>
> We have a number of customers that would like to use our video phones in
> Asterisk but have been missing a way of doing the sort of things that
> you would normally expect of a phone but with video tacked on. Our
> phones support SIP and H.323 so that's what we've majored on. We have
> customers doing regular telephony stuff and ones doing contact center
> things, so we needed to address all of this in Asterisk.
>
> So what'a working?:
> Well we've been adding video things to SIP and H.323 since Asterisk
> 1.0.7. Initially it was simple stuff like assuming H.263, CIF, MPI=1,
> that sort of thing, and building from there. In various Asterisk
> releases we've found things get broken, (i.e since around 1.2.something
> we found that chan->nativeformats got a bit more intelligent and so
> broke a number of channel cap exchanges) so we fix and patch as we go.
>
> As of today the following have been changed, tweaked, hacked or
> generally man handled by us:
>
> Chan_sip:
> - maxcallbitrate: a basic way of telling an endpoint what bitrate it
> should use (our videophones can do 2Mbps and so assuming such a rate for
> a DSL connection was never going to make for great call quality, see
> RTCP below). This should be superseded by a better capability mechanism.
>
> - per peer videosupport: some carriers really barf when you send them a
> video cap so we needed a way of allowing some endpoints to have video
> support and some not (i.e. internal extensions have video but some
> external trunks only audio).
> - per peer INFO or RTCP fast update requests: again some switches don't
> appreciate SIP info messages with XML in them as the Fast Update Request
> mechanism, so we added a per peer support way of selecting between
> sending SIP INFO with XML or by doing RTCP 192 (which is an old H.261
> way of doing FUR) again see RTCP below.
> - Process SDP: we have a simple way of extracting video fmtp lines from
> SDP. It's a bit ugly and has little awareness of SDP scope at the moment
> but it does extract fmtp for H.261, H.263 and H.264 into a common
> ast_capabilities (see channel.c below).
> - Build SDP: having extracted the fmtp lines and put them in a struct we
> pass the struct around to the called endpoints (changes to the bridging
> functions in channel.c) to limit their cap. We do a min() on confcap,
> peercap and chancap to determine a maximum jointcap that an endpoint
> will be allowed to generate once it gets an ack with SDP - don't get us
> going on early media responses because it breaks some switches that
> should know better.
> - Video capability in SIP.conf: we use the h.261/3 fmtp definitions to
> specify video capabilities in the conf file. i.e. you can specify lines
> like:
> H261=CIF=1 QCIF=2 CIF16=4 MaxBR=2024 framerate=25
> H263=CIF=1 QCIF=2 CIF16=4 QVGA MaxBR=2024 A/B/C
> Etc.
> I know you wouldn't normally do an MPI and framerate but we support it.
> We also allow for incorrectly formatted fmtp like some vendors are want
> to do.
>
> Chan_h323:
> - Well we added video for a start, sounds like others have been having
> similar fun too :-) . We also added the same maxcallbitrate and per peer
> videosupport as for SIP.
> - H.261, H.263 and nearly H.264 (I've got H.264 doing all the cap
> exchanges and getting the media channels running, I'm just patching in
> all the dynamic RTP stuff needed by Asterisk, h.323 is doing dynamicRTP
> - I just need to let Asterisk know about it. If anyone else has got
> H.264 going I'd love to see their approach).
> - There's also the beginnings of the same fmtp like conf options for
> H.323 in the conf file.
> - Fast update requests received and transmitted.
> - Fixes in H.323 for various Tandberg endpoints that don't like the way
> chan_h323 used to do port reflection (this is a pain for NAT support but
> most of our customers with H.323 seem to have stuck with DMZ or public
> IP address as the work around for NAT on H.323).
> - Video codecs are now broken out into their own files: ast_h26x.cpp and
> the makefile fixed to allow the links to *.cxx to work.
> - Logger support is also broken out into it's own file.
> - We're currently using RFC2190 support for H.263 but I think we'll do
> our own capability for that in the next few days.
>
> Chan_local:
> - it just needs a .write_video in the channel tech to get this working
> (I think that was all, I'd have to do a diff to see if we fixed anything
> else).
>
> Chan_agent:
> - similar to chan_local (.write_video) but I think there may have been a
> bit more required.
>
> App_echo:
> - simply added a ast_indicate at the front of the app so that if you do
> a playback or IVR before hitting app_echo then you don't get any
> breakthrough on some endpoints.
>
> Func_stringtoip:
> - this is one of our own creations that allows a user to be registered
> with chan_sip, or with a gatekeeper, and enter some arbitrary IP address
> like 10*1*1*1, or 010001001001, to make a call to 10.1.1.1 (I know that
> should be an internal IP address, replace with the public IP address of
> your choice). This is useful when you're supporting local extensions
> that want to talk to, for instance, lots of D-Link i2eyes that are all
> essentially sitting in the DMZ of a CPE router and not registered. I
> guess this could have been done in a set of dialplan apps but I'd rather
> do in in C.
>
> RTP.c:
> Hmmmm.... lots of very good work was done on this before we shoved our
> nose into it. We only added a few tweaks to RTP.c for RTCP but I think
> it works now when video is involved too.
> - RTP.c was seg faulting when the channel drivers shut down the RTP
> layer but the RTCP timers were still going - no prizes for guessing that
> the timer routine barfed when it tried to access the non-existent rtp
> structs.
> - Tidied up the parsing of the RTCP compound packets so that it worked.
> - Generate compound RTCP packets (you should always send at least two
> packets so we added a dummy SDES - it should really be filled in).
> - FUR now generated from the channel drivers if they want it. Our
> chan_sip decides whether to do it this way or with sip info. Some sort
> of auto refelction should be possible but it may not always be reliable.
> - FUR reported back to the channel drivers, thanks to Neil Stratford for
> pointing out a blindingly obvious way of doing it that us mere mortals
> had completely missed.
> - Fixed up some report errors on seqno wraparound etc.
> - A bit more of a troublesome problem for us has been seqno
> resequencing. Asterisk puts it's own sequence numbers into outbound RTP
> packets and ignores the inbound ones. This is generally fine for audio
> but we found that the lumpy nature of high bandwidth video calls could
> produce packet races (packets get swapped in transit to Asterisk)
> through the internet but Ast would renumber the outbound packets. This,
> of course, means that when the packet hits the target endpoint (having
> passed through Asterisk) it's actually out of sequence but the endpoint
> has no way of knowing that because all the seqno's are sequential
> (unless there's been an Ast to target swap aswell!). We've added support
> for seqno being added to ast_frame so that the RTP layer can use the
> inbound seqno if it's available. This gets complex with IVR and other
> file playback functions. Our solution can also cause large seqno jumps
> when going from file playback to live video, which some endpoints will
> crash on... the RFC says they shouldn't ;-) This fix isn't in Olle's
> RTCP branch as I thought it might be a little too dangerous.
> - RTCP report frequency in conf: The rtp.conf now supports an
> rtcpinterval=x ms setting to set how often rtcp reports are generated.
> The default 5000msecs isn't really enough to be handling video rate
> control. I think the RFC recommends that 5% of packets should be RTCP
> reports - that seemed a bit high to us, but sending one every 5 seconds
> when you've sent over 3000 video packets in that time (0.03%) seemed too
> low too :-)
> - DTMF tones (not really a video one this, but I'm on a roll so bear
> with me): I think there might be something very wrong with the DTMF tone
> generation in Asterisk. We get a lot of complaints about it and have
> tweaked what's there to improve things. We're waiting for Kevins's
> variable length DTMF support 'cos I'm sure that'll be much better.
>
> Channel.c/h
> - We've come up with a struct to store all the new video caps in. It
> looks like this but I'm sure there'll be lots of views on the way it
> should be done and propagated around Asterisk (the codecnegociation
> branch would maybe be a good start)
>
> #define AST_VIDEO_SQCIF (1)
> #define AST_VIDEO_QSIF (2)
> #define AST_VIDEO_QCIF (3)
> #define AST_VIDEO_QVGA (4)
> #define AST_VIDEO_SIF (5)
> #define AST_VIDEO_CIF (6)
> #define AST_VIDEO_VGA (7)
> #define AST_VIDEO_4CIF (8)
> #define AST_VIDEO_SVGA (9)
> #define AST_VIDEO_XGA (10)
> #define AST_VIDEO_16CIF (11)
>
> #define AST_VIDEO_LEVEL_BASELINE (1 << 0)
> #define AST_VIDEO_LEVEL_MAIN (1 << 1)
> #define AST_VIDEO_LEVEL_EXTENDED (1 << 2)
>
> #define MAX_VIDEO_SIZES 11
>
> /* The following array defines the video sizes we know about */
> struct videoSize{
> char* type;
> unsigned int num_mbs;
> unsigned int maxframterate;
> };
>
> static struct videoSize videoSizes[MAX_VIDEO_SIZES] = {
> {"SQCIF", 48, 0},
> {"QSIF", 75, 0},
> {"QCIF", 99, 0},
> {"QVGA", 300, 0},
> {"SIF", 300, 0},
> {"CIF", 396, 0},
> {"VGA", 1200, 0},
> {"CIF4", 1584, 0},
> {"SVGA", 1875, 0},
> {"XGA", 2304, 0},
> {"CIF16", 6336, 0},
> };
>
> /*! \brief ast_video_cap: Struct holding video capabilities */ struct
> ast_h2613_video_cap {
> int valid;
> /*!< 1 = This codec is specified, 0 = not specified */
> unsigned int annexes;
> /*!< Video annexes - stored as bitfield 2^(annex-ascii(A))*/
> unsigned int maxframerates[MAX_VIDEO_SIZES]; /*!< Maximum
> framerate (framerate = 30/mpi) */
> unsigned int maxbr;
> /*!< Maximum supported bitrate for this capability */
> };
>
> /*! \brief ast_h264_video_cap: Struct holding video capabilities */
> struct ast_h264_video_cap {
> unsigned int flags; /*!< Video flags
> */
> unsigned int level; /*!< Profile
> level */
> unsigned int maxmbps; /*!< Maximum number of
> macroblocks per second */
> unsigned int minfs; /*!< Minimum
> frame size in macroblocks */
> unsigned int maxfs; /*!< Maximum
> frame size in macroblocks */
> unsigned int maxcpb; /*!< Maximum coded
> picture buffer size in units of 1000 bits (1200 NAL HRD)*/
> unsigned int maxdpb; /*!< Maximum decoded
> picture buffer size in units of 1024 bytes */
> unsigned int packet_mode; /*!< Packetisation mode */
> unsigned int maxbr; /*!< Maximum
> supported bitrate for this capability */
> };
>
> /*! \brief ast_video_capabilities: Struct holding all video capabilities
> */ struct ast_video_capabilities {
> unsigned int maxbitrate; /*!< Max video bitrate */
> struct ast_h2613_video_cap h261; /*!< H261 video capabilities
> */
> struct ast_h2613_video_cap h263; /*!< H263 video capabilities
> */
> struct ast_h264_video_cap h264; /*!< H264 video capabilities
> */ };
>
> /*! \brief ast_video_capabilities: Struct holding all video capabilities
> */ struct ast_capabilities {
> int maxcallbitrate;
> /*!< Max allowed bitrate for this channel */
> struct ast_video_capabilities videocaps; /*!< video
> capabilities */ };
>
> I think that's enough for now... if I've still got any of you with me
> then perhaps the future of what we're up to can come another time....
>
> John
>
>
> John Martin
> John.Martin@AuPix.com
> http://www.AuPix.com
>
> -----Original Message-----
> From: Olle E Johansson [mailto:registry@webway.se]
> Sent: 16 May 2006 10:13
> To: asterisk-video@edvina.net
> Subject: AVTF - What's going on?
>
> This is stuff going on that I'm aware of:
>
> * I am working on fixes for SIP/SDP in the sdpcleanup branch.
> Grandstream and Foniris generously
> donated video phones for me to test with. I am implementing some
> checks if we really have
> video on the incoming call before we offer it on the outbound
> call. Seems stupid to offer
> video without a stream. If we can fix this stuff and test it
> quickly, I can get it into 1.4.
>
> * John Martin contributed some patches for FMTP support that is
> needed. Will open a branch
> for this hopefully this week. This is too late for 1.4, but will
> have to be part of 1.6. It will require
> some architectural changes, and we're beyond freeze for that.
>
> * John Martin is also doing work on H.323 and video
>
> What else is going on codewise or should be added to the wish list?
>
> /Olle
>
>
> _______________________________________________
> --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
>
Posted: Tue May 16, 2006 3:01 pm Post subject: [Asterisk-video] Re: AVTF - What's going on?
H.323 hardly depends on the transport so using it with IPV6 won't
change much. As far as I know H.323 implicitly defines transport specs
only for H.225 and H.245.
On 5/16/06, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
Quote:
Le 06-05-16 ? 12:34, Shidan a ?crit :
> IPV6 would only affect the code for H.225 and H.245, I don't even know
> how far in supporting video asterisk goes for H.323.
thanks for answering. do you know if the spec was updated for IPv6
transport? (the context of this question is that I'm converting
asterisk to Ipv6 and I have specs for SIP over Ipv6, (somewhat) IAX
over IPv6, but don't have access to ITU documents that might or might
not have been updated for IPv6).
Any pointers would be useful for me.
Regards, Marc.
>
> ----
> Shidan
>
> On 5/16/06, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
>> question: is h.323 defined for IPv6 transport?
>>
>> marc.
>>
>> Le 06-05-16 ? 05:13, Olle E Johansson a ?crit :
>>
>> > This is stuff going on that I'm aware of:
>> >
>> > * I am working on fixes for SIP/SDP in the sdpcleanup branch.
>> > Grandstream and Foniris generously
>> > donated video phones for me to test with. I am implementing some
>> > checks if we really have
>> > video on the incoming call before we offer it on the outbound
>> > call. Seems stupid to offer
>> > video without a stream. If we can fix this stuff and test it
>> > quickly, I can get it into 1.4.
>> >
>> > * John Martin contributed some patches for FMTP support that is
>> > needed. Will open a branch
>> > for this hopefully this week. This is too late for 1.4, but will
>> > have to be part of 1.6. It will require
>> > some architectural changes, and we're beyond freeze for that.
>> >
>> > * John Martin is also doing work on H.323 and video
>> >
>> > What else is going on codewise or should be added to the wish list?
>> >
>> > /Olle
>>
>>
>>
>> =========
>> IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca
>>
>>
>>
>>
Posted: Tue May 16, 2006 5:45 pm Post subject: [Asterisk-video] RE: AVTF - What's going on?
Hi,
John Martin wrote:
[skipped]
Quote:
App_echo:
- simply added a ast_indicate at the front of the app so that if you do
a playback or IVR before hitting app_echo then you don't get any
breakthrough on some endpoints.
That should be fixed at channel/core level just because app_echo is simplest application so you could have problems with
other applications too.
[skipped]
Quote:
Channel.c/h
- We've come up with a struct to store all the new video caps in. It
looks like this but I'm sure there'll be lots of views on the way it
should be done and propagated around Asterisk (the codecnegociation
branch would maybe be a good start)
Is it better to have fmtp passing as strings between channels? At least it would guarantee a compatibility for other
non-standard/etc. implementations. Conversions of text representations into H.323 binary data could be done at chan_h323
level locally or at core level.
Posted: Tue May 16, 2006 9:32 pm Post subject: [Asterisk-video] RE: AVTF - What's going on?
Hi Paul,
I also played with fixing app_echo in a more "core" way with the
bridging functions. You're right that's probably the best place to do
it, but it's a quick fix in app_echo and I didn't know a lot about
Asterisk core at the time.
I've thought about passing the fmtp stuff around as strings but not
all protocols use fmtp. In H.323 you have to have the broken down data
as I think you have to in skinny. H.320 (we might have some aspirations
in that area) and H.324(M) would also need fmtp broken down. I don't
know what IAX does, maybe it uses fmtp? It would probably make sense to
condense down my proposed ast_capablities structures so they don't take
up as much memory.
-----Original Message-----
From: asterisk-video-bounces@lists.digium.com
[mailto:asterisk-video-bounces@lists.digium.com] On Behalf Of Paul
Cadach
Sent: 17 May 2006 03:46
To: Discussion of video media support in Asterisk
Subject: Re: [Asterisk-video] RE: AVTF - What's going on?
Hi,
John Martin wrote:
[skipped]
Quote:
App_echo:
- simply added a ast_indicate at the front of the app so that if you
do
Quote:
a playback or IVR before hitting app_echo then you don't get any
breakthrough on some endpoints.
That should be fixed at channel/core level just because app_echo is
simplest application so you could have problems with
other applications too.
[skipped]
Quote:
Channel.c/h
- We've come up with a struct to store all the new video caps in. It
looks like this but I'm sure there'll be lots of views on the way it
should be done and propagated around Asterisk (the codecnegociation
branch would maybe be a good start)
Is it better to have fmtp passing as strings between channels? At least
it would guarantee a compatibility for other
non-standard/etc. implementations. Conversions of text representations
into H.323 binary data could be done at chan_h323
level locally or at core level.
WBR,
Paul.
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Posted: Tue May 16, 2006 9:38 pm Post subject: [Asterisk-video] RE: AVTF - What's going on?
John Martin wrote:
Quote:
Hey Sergio,
Sounds cool. We did our own H.324 stack a few years back but V.34
wasn't really up to the requirements of video back then, there's a
knee in the quality/bitrate graph for H.263 at around 40kbps that 3G
should be able to take advantage of and of course H.264 is made for
it.
Which specifications/annexes did you implement? Could we see something of it?
Quote:
I think I've seen some posts from you in the past on the subject,
where can we find out more about your work? Do you think you'll be
able to match the likes of Dilithium and RadVision, they both have
some interesting transcoding options.
Of course not! :)
In the first stage I'm not planning to implement any transcoding yet (anyone is invited to join).
I haven't integrated anything yet into asterisk, as I still haven't got the hardware running. But you'll see something more as soon as I get it (if you're interested in anything in particullar just ask)
Greetings
Sergio
--------------------------------------------------------------------------------------
This message and any files transmitted with it are confidential and intended solely
for the use of the individual or entity to whom they are addressed. No confidentiality
or privilege is waived or lost by any wrong transmission.
If you have received this message in error, please immediately destroy it and kindly
notify the sender by reply email.
You must not, directly or indirectly, use, disclose, distribute, print, or copy any
part of this message if you are not the intended recipient. Opinions, conclusions and
other information in this message that do not relate to the official business of
Ydilo Advanced Voice Solutions, S.A. shall be understood as neither given nor endorsed by it.
--------------------------------------------------------------------------------------
Posted: Tue May 16, 2006 9:41 pm Post subject: [Asterisk-video] RE: AVTF - What's going on?
17 maj 2006 kl. 08.32 skrev John Martin:
Quote:
Hi Paul,
I also played with fixing app_echo in a more "core" way with the
bridging functions. You're right that's probably the best place to do
it, but it's a quick fix in app_echo and I didn't know a lot about
Asterisk core at the time.
I've thought about passing the fmtp stuff around as strings but not
all protocols use fmtp. In H.323 you have to have the broken down data
as I think you have to in skinny. H.320 (we might have some
aspirations
in that area) and H.324(M) would also need fmtp broken down. I don't
know what IAX does, maybe it uses fmtp? It would probably make
sense to
condense down my proposed ast_capablities structures so they don't
take
up as much memory.
...don't forget the format drivers. I think an internal binary format
is better,
otherwise we would have to parse the same strings many times.
Posted: Tue May 16, 2006 9:52 pm Post subject: [Asterisk-video] RE: AVTF - What's going on?
Hi Sergio,
We wouldn't be able to donate any of our H.324 work. I'll have a look at the code soon and let you know what we did, it was nearly 10 years ago!
Hardware for H.324M... what hardware are you doing? I thought the Dilithiums of this world were bridging at the ISDN level, seeing as an H.324M video call is essentially 64k ISDN B-channel and the carriers will terminate to ISDN when you call off net. Makes sense to come in on an E1 or else you'd have a lot of antennas if you wanted to do a couple of hundred call terminations :-)
Hasn't Junghanns already got a GSM card, they were talking of quad band, maybe there's a 3G version on the way?
-----Original Message-----
From: asterisk-video-bounces@lists.digium.com [mailto:asterisk-video-bounces@lists.digium.com] On Behalf Of Sergio Garc?a Murillo
Sent: 17 May 2006 07:38
To: Discussion of video media support in Asterisk
Subject: RE: [Asterisk-video] RE: AVTF - What's going on?
John Martin wrote:
Quote:
Hey Sergio,
Sounds cool. We did our own H.324 stack a few years back but V.34
wasn't really up to the requirements of video back then, there's a
knee in the quality/bitrate graph for H.263 at around 40kbps that 3G
should be able to take advantage of and of course H.264 is made for
it.
Which specifications/annexes did you implement? Could we see something of it?
Quote:
I think I've seen some posts from you in the past on the subject,
where can we find out more about your work? Do you think you'll be
able to match the likes of Dilithium and RadVision, they both have
some interesting transcoding options.
Of course not! :)
In the first stage I'm not planning to implement any transcoding yet (anyone is invited to join).
I haven't integrated anything yet into asterisk, as I still haven't got the hardware running. But you'll see something more as soon as I get it (if you're interested in anything in particullar just ask)
Greetings
Sergio
--------------------------------------------------------------------------------------
This message and any files transmitted with it are confidential and intended solely
for the use of the individual or entity to whom they are addressed. No confidentiality
or privilege is waived or lost by any wrong transmission.
If you have received this message in error, please immediately destroy it and kindly
notify the sender by reply email.
You must not, directly or indirectly, use, disclose, distribute, print, or copy any
part of this message if you are not the intended recipient. Opinions, conclusions and
other information in this message that do not relate to the official business of
Ydilo Advanced Voice Solutions, S.A. shall be understood as neither given nor endorsed by it.
--------------------------------------------------------------------------------------
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Posted: Tue May 16, 2006 10:25 pm Post subject: [Asterisk-video] RE: AVTF - What's going on?
Quote:
Hardware for H.324M... what hardware are you doing?
A TE411P, a server and some E1 from my company pbx, you know, bureaucracy can be exhausting... :)
And regarding video transcoding, it would be great to have some capabilities integrated within asterisk so we could use the error correction mechanism defined in AL3 to provide a much better video quality.
Does asterisk offer any capability? How it's handled in audio? Any possibility of integrating libavocdec/ffmpeg or similar library?
Greetings
Sergio
--------------------------------------------------------------------------------------
This message and any files transmitted with it are confidential and intended solely
for the use of the individual or entity to whom they are addressed. No confidentiality
or privilege is waived or lost by any wrong transmission.
If you have received this message in error, please immediately destroy it and kindly
notify the sender by reply email.
You must not, directly or indirectly, use, disclose, distribute, print, or copy any
part of this message if you are not the intended recipient. Opinions, conclusions and
other information in this message that do not relate to the official business of
Ydilo Advanced Voice Solutions, S.A. shall be understood as neither given nor endorsed by it.
--------------------------------------------------------------------------------------
Posted: Tue May 16, 2006 11:57 pm Post subject: [Asterisk-video] RE: AVTF - What's going on?
Hi everyone,
It's great to see so much activity around video.
Here are some projects that we've been working on:
- Videoswitch: (thanks to support from AuPix)
A multi-party video conference module based on app_conference. Each
participant gets to see a single video stream at a time, which can be
switched using either DTMF input from the user or Manager interface
commands. You can use it for things like video conferencing, distance
learning and video broadcast. There is usually a test version running at
400@sip.vipadia.com if you would like to play with it. We'll be making
the code available soon.
- Fast Updates / RTCP / etc etc:
Various patches for fast updates and tweaks to RTCP for different
Asterisk versions.
- GStreamer & Asterisk:
Modules for GStreamer (www.gstreamer.net) which allow it to generate
Asterisk format h263 files. With a GStreamer command line you can
convert video files from other formats into h263 and wav files for
playback using Asterisk. I believe that the modules are now maintained
in the GStreamer CVS.
Other stuff:
I've volunteered to talk about Asterisk and Video at the London
Astricon. I'm intending to talk about what you can do today (what works)
and what is missing (or broken), both at a high level and the technical
details.
Neil
Quote:
-----Original Message-----
From: Olle E Johansson [mailto:registry@webway.se]
Sent: 16 May 2006 10:13
To: asterisk-video@edvina.net
Subject: AVTF - What's going on?
This is stuff going on that I'm aware of:
* I am working on fixes for SIP/SDP in the sdpcleanup branch.
Grandstream and Foniris generously
donated video phones for me to test with. I am implementing some
checks if we really have
video on the incoming call before we offer it on the outbound
call. Seems stupid to offer
video without a stream. If we can fix this stuff and test it
quickly, I can get it into 1.4.
* John Martin contributed some patches for FMTP support that is
needed. Will open a branch
for this hopefully this week. This is too late for 1.4, but will
have to be part of 1.6. It will require
some architectural changes, and we're beyond freeze for that.
* John Martin is also doing work on H.323 and video
What else is going on codewise or should be added to the wish list?
/Olle
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Posted: Wed May 17, 2006 12:04 am Post subject: [Asterisk-video] RE: AVTF - What's going on?
Hi,
John Martin wrote:
Quote:
I've thought about passing the fmtp stuff around as strings but not
all protocols use fmtp. In H.323 you have to have the broken down data
as I think you have to in skinny. H.320 (we might have some aspirations
in that area) and H.324(M) would also need fmtp broken down. I don't
know what IAX does, maybe it uses fmtp? It would probably make sense to
condense down my proposed ast_capablities structures so they don't take
up as much memory.
Probably better is to have special "unknown/unsupported" option for fmtp and
bring text/binary version of data along with it to make transparency at least
within calling protocol (SIP<->SIP calls or H.323<->H.323 calls).
Posted: Wed May 17, 2006 12:07 am Post subject: [Asterisk-video] RE: AVTF - What's going on?
17 maj 2006 kl. 10.57 skrev Neil Stratford:
Quote:
Hi everyone,
It's great to see so much activity around video.
Here are some projects that we've been working on:
- Videoswitch: (thanks to support from AuPix)
A multi-party video conference module based on app_conference. Each
participant gets to see a single video stream at a time, which can
be switched using either DTMF input from the user or Manager
interface commands. You can use it for things like video
conferencing, distance learning and video broadcast. There is
usually a test version running at 400@sip.vipadia.com if you would
like to play with it. We'll be making the code available soon.
Would it be possible to take this code to app_meetme?
Quote:
- Fast Updates / RTCP / etc etc:
Various patches for fast updates and tweaks to RTCP for different
Asterisk versions.
Can we get those. I'll happily open a branch for it and make sure it
is moved forward.
Any feedback on the current rtcp branch/patch?
Quote:
- GStreamer & Asterisk:
Modules for GStreamer (www.gstreamer.net) which allow it to
generate Asterisk format h263 files. With a GStreamer command line
you can convert video files from other formats into h263 and wav
files for playback using Asterisk. I believe that the modules are
now maintained in the GStreamer CVS.
That is really cool. I'll look at it. Does it divide the video into
Posted: Wed May 17, 2006 12:10 am Post subject: [Asterisk-video] RE: AVTF - What's going on?
Maybe we could move video transcoding outside of asterisk to make it
easier to pass it to a cluster for the real processing ?
Does somebody have a list of related ITU specs for video over ip ?
Zoa.
Olle E Johansson wrote:
Quote:
17 maj 2006 kl. 10.57 skrev Neil Stratford:
> Hi everyone,
>
> It's great to see so much activity around video.
>
> Here are some projects that we've been working on:
>
> - Videoswitch: (thanks to support from AuPix)
> A multi-party video conference module based on app_conference. Each
> participant gets to see a single video stream at a time, which can
> be switched using either DTMF input from the user or Manager
> interface commands. You can use it for things like video
> conferencing, distance learning and video broadcast. There is
> usually a test version running at 400@sip.vipadia.com if you would
> like to play with it. We'll be making the code available soon.
Would it be possible to take this code to app_meetme?
>
> - Fast Updates / RTCP / etc etc:
> Various patches for fast updates and tweaks to RTCP for different
> Asterisk versions.
>
Can we get those. I'll happily open a branch for it and make sure it
is moved forward.
Any feedback on the current rtcp branch/patch?
> - GStreamer & Asterisk:
> Modules for GStreamer (www.gstreamer.net) which allow it to generate
> Asterisk format h263 files. With a GStreamer command line you can
> convert video files from other formats into h263 and wav files for
> playback using Asterisk. I believe that the modules are now
> maintained in the GStreamer CVS.
>
That is really cool. I'll look at it. Does it divide the video into
one audio and one video file?
/Olle
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum