While watching a full packet dump on the asterisk node, I can see the
h263 coming in from the clients, but it never leaves (asterisk never
originates 1 h263 packet). You can see on line 123 of the pastebin
that the calls get setup without video but then h263 is renegotiated
on line 456. The second end point sets up h263 on line 313. I'm
pretty lost as to how I can get asterisk to play nice. This is
Asterisk 1.4.18.1
I just was able to test, and if the call sets up (the initial invite
contains) with h263, and isn't done with a re-invite at a later time
then it works fine.
my sip conf looks like the following:
[general]
type=friend
host=dynamic
context=incoming
srvlookup=yes
canreinvite=no
videosupport=yes
qualify=yes
nat=yes
host=dynamic ; This device registers with us
disallow=all ;better for custom-tunning codec selection
allow=ulaw
allow=alaw
allow=h263 ; H.263 is our video codec
allow=h263p ; H.263p is the enhanced video codec
dtmfmode=rfc2833 ; inband is not supported in compressed codecs like
gsm, so we better set it to rfc2833
[miles_8920_lap]
type=friend
host=dynamic
secret=*****
context=internal_devices ; the internal_devices context
controls what we can do
mailbox=8920@sixsquares
callerid= Miles Scruggs <8920>
canreinvite=no
While watching a full packet dump on the asterisk node, I can see the
h263 coming in from the clients, but it never leaves (asterisk never
originates 1 h263 packet). You can see on line 123 of the pastebin that the
calls get setup without video but then h263 is renegotiated on line 456.
The second end point sets up h263 on line 313. I'm
pretty lost as to how I can get asterisk to play nice. This is
Asterisk 1.4.18.1
I just was able to test, and if the call sets up (the initial invite
contains) with h263, and isn't done with a re-invite at a later time then it
works fine.
my sip conf looks like the following:
[general]
type=friend
host=dynamic
context=incoming
srvlookup=yes
canreinvite=no
videosupport=yes
qualify=yes
nat=yes
host=dynamic ; This device registers with us
disallow=all ;better for custom-tunning codec selection allow=ulaw
allow=alaw
allow=h263 ; H.263 is our video codec
allow=h263p ; H.263p is the enhanced video codec
dtmfmode=rfc2833 ; inband is not supported in compressed codecs like gsm, so
we better set it to rfc2833
[miles_8920_lap]
type=friend
host=dynamic
secret=*****
context=internal_devices ; the internal_devices context
controls what we can do
mailbox=8920@sixsquares
callerid= Miles Scruggs <8920>
canreinvite=no
While watching a full packet dump on the asterisk node, I can see the
h263 coming in from the clients, but it never leaves (asterisk never
originates 1 h263 packet). You can see on line 123 of the pastebin
that the
calls get setup without video but then h263 is renegotiated on line
456.
The second end point sets up h263 on line 313. I'm
pretty lost as to how I can get asterisk to play nice. This is
Asterisk 1.4.18.1
I just was able to test, and if the call sets up (the initial invite
contains) with h263, and isn't done with a re-invite at a later time
then it
works fine.
my sip conf looks like the following:
[general]
type=friend
host=dynamic
context=incoming
srvlookup=yes
canreinvite=no
videosupport=yes
qualify=yes
nat=yes
host=dynamic ; This device registers with us
disallow=all ;better for custom-tunning codec selection allow=ulaw
allow=alaw
allow=h263 ; H.263 is our video codec
allow=h263p ; H.263p is the enhanced video codec
dtmfmode=rfc2833 ; inband is not supported in compressed codecs like
gsm, so
we better set it to rfc2833
[miles_8920_lap]
type=friend
host=dynamic
secret=*****
context=internal_devices ; the internal_devices context
controls what we can do
mailbox=8920@sixsquares
callerid= Miles Scruggs <8920>
canreinvite=no
Posted: Wed May 21, 2008 8:06 pm Post subject: [Asterisk-video] h263 blackholed.
Hi, the standard asterisk do not support cleanlly the sdp negociation.
Try setting only one video codec.
Regards,
Tech from i6net
----- Message d'origine -----
De: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
Env: mercredi 21 mai 2008 19:47
À: 'Development discussion of video media support in Asterisk' <asterisk-video@lists.digium.com>
Objet: Re: [Asterisk-video] h263 blackholed.
You must use a late VIDCAPS to get any usable video support from Asterisk.
VIDCAPS adds important ability to handle SDP properly in the call setup.
While watching a full packet dump on the asterisk node, I can see the
h263 coming in from the clients, but it never leaves (asterisk never
originates 1 h263 packet). You can see on line 123 of the pastebin that the
calls get setup without video but then h263 is renegotiated on line 456.
The second end point sets up h263 on line 313. I'm
pretty lost as to how I can get asterisk to play nice. This is
Asterisk 1.4.18.1
I just was able to test, and if the call sets up (the initial invite
contains) with h263, and isn't done with a re-invite at a later time then it
works fine.
my sip conf looks like the following:
[general]
type=friend
host=dynamic
context=incoming
srvlookup=yes
canreinvite=no
videosupport=yes
qualify=yes
nat=yes
host=dynamic ; This device registers with us
disallow=all ;better for custom-tunning codec selection allow=ulaw
allow=alaw
allow=h263 ; H.263 is our video codec
allow=h263p ; H.263p is the enhanced video codec
dtmfmode=rfc2833 ; inband is not supported in compressed codecs like gsm, so
we better set it to rfc2833
[miles_8920_lap]
type=friend
host=dynamic
secret=*****
context=internal_devices ; the internal_devices context
controls what we can do
mailbox=8920@sixsquares
callerid= Miles Scruggs <8920>
canreinvite=no
Without it, asterisk does not take any consideration of what result the sdp
exchange gives.
Gunnar
-----Original Message-----
From: asterisk-video-bounces@lists.digium.com
[mailto:asterisk-video-bounces@lists.digium.com] On Behalf Of Miles Scruggs
Sent: Wednesday, May 21, 2008 10:26 PM
To: Development discussion of video media support in Asterisk
Subject: Re: [Asterisk-video] h263 blackholed.
Can you please elaborate more? Maybe a link or something would be helpful,
I'm not familiar with VIDCAPS.
On May 21, 2008, at 10:47 AM, Gunnar Hellstrom wrote:
Quote:
You must use a late VIDCAPS to get any usable video support from
Asterisk.
VIDCAPS adds important ability to handle SDP properly in the call
setup.
Gunnar
I'm trying to get asterisk to proxy h263 for a video call, but not
having any luck. I have posted a full call trace here:
While watching a full packet dump on the asterisk node, I can see the
h263 coming in from the clients, but it never leaves (asterisk never
originates 1 h263 packet). You can see on line 123 of the pastebin
that the calls get setup without video but then h263 is renegotiated
on line 456.
The second end point sets up h263 on line 313. I'm pretty lost as to
how I can get asterisk to play nice. This is Asterisk 1.4.18.1
I just was able to test, and if the call sets up (the initial invite
contains) with h263, and isn't done with a re-invite at a later time
then it works fine.
my sip conf looks like the following:
[general]
type=friend
host=dynamic
context=incoming
srvlookup=yes
canreinvite=no
videosupport=yes
qualify=yes
nat=yes
host=dynamic ; This device registers with us
disallow=all ;better for custom-tunning codec selection allow=ulaw
allow=alaw
allow=h263 ; H.263 is our video codec
allow=h263p ; H.263p is the enhanced video codec
dtmfmode=rfc2833 ; inband is not supported in compressed codecs like
gsm, so we better set it to rfc2833
[miles_8920_lap]
type=friend
host=dynamic
secret=*****
context=internal_devices ; the internal_devices context
controls what we can do
mailbox=8920@sixsquares
callerid= Miles Scruggs <8920>
canreinvite=no
Posted: Wed May 21, 2008 8:19 pm Post subject: [Asterisk-video] h263 blackholed.
Damn it looks like my pastebin has expired but we were only sending
one codec, the only thing that would make it fail was to send the
codec to asterisk after the call is setup. If we setup the call with
h263 listed then it would work out of the door, but if the call was
setup without the codec, then a second invite came down the pipe to
asterisk with the new codec (h263) asterisk would pretend to
renegotiate but never passed h263.
On May 21, 2008, at 2:00 PM, Borja Sixto wrote:
Quote:
Hi, the standard asterisk do not support cleanlly the sdp negociation.
Try setting only one video codec.
Regards,
Tech from i6net
----- Message d'origine -----
De: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
Env: mercredi 21 mai 2008 19:47
À: 'Development discussion of video media support in Asterisk' <asterisk-video@lists.digium.com
>
Objet: Re: [Asterisk-video] h263 blackholed.
You must use a late VIDCAPS to get any usable video support from
Asterisk.
VIDCAPS adds important ability to handle SDP properly in the call
setup.
While watching a full packet dump on the asterisk node, I can see the
h263 coming in from the clients, but it never leaves (asterisk never
originates 1 h263 packet). You can see on line 123 of the pastebin
that the
calls get setup without video but then h263 is renegotiated on line
456.
The second end point sets up h263 on line 313. I'm
pretty lost as to how I can get asterisk to play nice. This is
Asterisk 1.4.18.1
I just was able to test, and if the call sets up (the initial invite
contains) with h263, and isn't done with a re-invite at a later time
then it
works fine.
my sip conf looks like the following:
[general]
type=friend
host=dynamic
context=incoming
srvlookup=yes
canreinvite=no
videosupport=yes
qualify=yes
nat=yes
host=dynamic ; This device registers with us
disallow=all ;better for custom-tunning codec selection allow=ulaw
allow=alaw
allow=h263 ; H.263 is our video codec
allow=h263p ; H.263p is the enhanced video codec
dtmfmode=rfc2833 ; inband is not supported in compressed codecs like
gsm, so
we better set it to rfc2833
[miles_8920_lap]
type=friend
host=dynamic
secret=*****
context=internal_devices ; the internal_devices context
controls what we can do
mailbox=8920@sixsquares
callerid= Miles Scruggs <8920>
canreinvite=no
Posted: Wed May 21, 2008 8:31 pm Post subject: [Asterisk-video] h263 blackholed.
Hi,
Try adding videosupport=yes also to sip peers and if you're using Xlite set it to send the invite
with video at first and not re-invite latter with video offer (If i recall correctly from the pastebin).
Best regards
Sergio
Miles Scruggs escribió:
Quote:
Quote:
Damn it looks like my pastebin has expired but we were only sending
one codec, the only thing that would make it fail was to send the
codec to asterisk after the call is setup. If we setup the call with
h263 listed then it would work out of the door, but if the call was
setup without the codec, then a second invite came down the pipe to
asterisk with the new codec (h263) asterisk would pretend to
renegotiate but never passed h263.
On May 21, 2008, at 2:00 PM, Borja Sixto wrote:
Quote:
Hi, the standard asterisk do not support cleanlly the sdp negociation.
Try setting only one video codec.
Regards,
Tech from i6net
----- Message d'origine -----
De: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> (gunnar.hellstrom@omnitor.se)
Env: mercredi 21 mai 2008 19:47
À: 'Development discussion of video media support in Asterisk' <asterisk-video@lists.digium.com (asterisk-video@lists.digium.com)
Objet: Re: [Asterisk-video] h263 blackholed.
You must use a late VIDCAPS to get any usable video support from
Asterisk.
VIDCAPS adds important ability to handle SDP properly in the call
setup.
While watching a full packet dump on the asterisk node, I can see the
h263 coming in from the clients, but it never leaves (asterisk never
originates 1 h263 packet). You can see on line 123 of the pastebin
that the
calls get setup without video but then h263 is renegotiated on line
456.
The second end point sets up h263 on line 313. I'm
pretty lost as to how I can get asterisk to play nice. This is
Asterisk 1.4.18.1
I just was able to test, and if the call sets up (the initial invite
contains) with h263, and isn't done with a re-invite at a later time
then it
works fine.
my sip conf looks like the following:
[general]
type=friend
host=dynamic
context=incoming
srvlookup=yes
canreinvite=no
videosupport=yes
qualify=yes
nat=yes
host=dynamic ; This device registers with us
disallow=all ;better for custom-tunning codec selection allow=ulaw
allow=alaw
allow=h263 ; H.263 is our video codec
allow=h263p ; H.263p is the enhanced video codec
dtmfmode=rfc2833 ; inband is not supported in compressed codecs like
gsm, so
we better set it to rfc2833
[miles_8920_lap]
type=friend
host=dynamic
secret=*****
context=internal_devices ; the internal_devices context
controls what we can do
mailbox=8920@sixsquares
callerid= Miles Scruggs <8920>
canreinvite=no
Posted: Wed May 21, 2008 8:40 pm Post subject: [Asterisk-video] h263 blackholed.
Do you know of a way to get eyebeam/xlite to announce codecs right out the door?
On May 21, 2008, at 2:26 PM, Sergio Garcia Murillo wrote:
Quote:
Hi,
Try adding videosupport=yes also to sip peers and if you're using Xlite set it to send the invite
with video at first and not re-invite latter with video offer (If i recall correctly from the pastebin).
Best regards
Sergio
Miles Scruggs escribió:
Quote:
Quote:
Damn it looks like my pastebin has expired but we were only sending
one codec, the only thing that would make it fail was to send the
codec to asterisk after the call is setup. If we setup the call with
h263 listed then it would work out of the door, but if the call was
setup without the codec, then a second invite came down the pipe to
asterisk with the new codec (h263) asterisk would pretend to
renegotiate but never passed h263.
On May 21, 2008, at 2:00 PM, Borja Sixto wrote:
Quote:
Hi, the standard asterisk do not support cleanlly the sdp negociation.
Try setting only one video codec.
Regards,
Tech from i6net
----- Message d'origine -----
De: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> (gunnar.hellstrom@omnitor.se)
Env: mercredi 21 mai 2008 19:47
À: 'Development discussion of video media support in Asterisk' <asterisk-video@lists.digium.com (asterisk-video@lists.digium.com)
Objet: Re: [Asterisk-video] h263 blackholed.
You must use a late VIDCAPS to get any usable video support from
Asterisk.
VIDCAPS adds important ability to handle SDP properly in the call
setup.
While watching a full packet dump on the asterisk node, I can see the
h263 coming in from the clients, but it never leaves (asterisk never
originates 1 h263 packet). You can see on line 123 of the pastebin
that the
calls get setup without video but then h263 is renegotiated on line
456.
The second end point sets up h263 on line 313. I'm
pretty lost as to how I can get asterisk to play nice. This is
Asterisk 1.4.18.1
I just was able to test, and if the call sets up (the initial invite
contains) with h263, and isn't done with a re-invite at a later time
then it
works fine.
my sip conf looks like the following:
[general]
type=friend
host=dynamic
context=incoming
srvlookup=yes
canreinvite=no
videosupport=yes
qualify=yes
nat=yes
host=dynamic ; This device registers with us
disallow=all ;better for custom-tunning codec selection allow=ulaw
allow=alaw
allow=h263 ; H.263 is our video codec
allow=h263p ; H.263p is the enhanced video codec
dtmfmode=rfc2833 ; inband is not supported in compressed codecs like
gsm, so
we better set it to rfc2833
[miles_8920_lap]
type=friend
host=dynamic
secret=*****
context=internal_devices ; the internal_devices context
controls what we can do
mailbox=8920@sixsquares
callerid= Miles Scruggs <8920>
canreinvite=no
Posted: Thu May 22, 2008 5:29 pm Post subject: [Asterisk-video] h263 blackholed.
I think there was an option in eyebean but cannot find it in xlite. Anyway, a probably obvious tip,
have you tried to open the video screen in xlite before dialing?
Best regards
Sergio
Miles Scruggs escribió:
Quote:
Do you know of a way to get eyebeam/xlite to announce codecs right out the door?
On May 21, 2008, at 2:26 PM, Sergio Garcia Murillo wrote:
Quote:
Hi,
Try adding videosupport=yes also to sip peers and if you're using Xlite set it to send the invite
with video at first and not re-invite latter with video offer (If i recall correctly from the pastebin).
Best regards
Sergio
Miles Scruggs escribió:
Quote:
Quote:
Damn it looks like my pastebin has expired but we were only sending
one codec, the only thing that would make it fail was to send the
codec to asterisk after the call is setup. If we setup the call with
h263 listed then it would work out of the door, but if the call was
setup without the codec, then a second invite came down the pipe to
asterisk with the new codec (h263) asterisk would pretend to
renegotiate but never passed h263.
On May 21, 2008, at 2:00 PM, Borja Sixto wrote:
Quote:
Hi, the standard asterisk do not support cleanlly the sdp negociation.
Try setting only one video codec.
Regards,
Tech from i6net
----- Message d'origine -----
De: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
Env: mercredi 21 mai 2008 19:47
À: 'Development discussion of video media support in Asterisk' <asterisk-video@lists.digium.com
Objet: Re: [Asterisk-video] h263 blackholed.
You must use a late VIDCAPS to get any usable video support from
Asterisk.
VIDCAPS adds important ability to handle SDP properly in the call
setup.
While watching a full packet dump on the asterisk node, I can see the
h263 coming in from the clients, but it never leaves (asterisk never
originates 1 h263 packet). You can see on line 123 of the pastebin
that the
calls get setup without video but then h263 is renegotiated on line
456.
The second end point sets up h263 on line 313. I'm
pretty lost as to how I can get asterisk to play nice. This is
Asterisk 1.4.18.1
I just was able to test, and if the call sets up (the initial invite
contains) with h263, and isn't done with a re-invite at a later time
then it
works fine.
my sip conf looks like the following:
[general]
type=friend
host=dynamic
context=incoming
srvlookup=yes
canreinvite=no
videosupport=yes
qualify=yes
nat=yes
host=dynamic ; This device registers with us
disallow=all ;better for custom-tunning codec selection allow=ulaw
allow=alaw
allow=h263 ; H.263 is our video codec
allow=h263p ; H.263p is the enhanced video codec
dtmfmode=rfc2833 ; inband is not supported in compressed codecs like
gsm, so
we better set it to rfc2833
[miles_8920_lap]
type=friend
host=dynamic
secret=*****
context=internal_devices ; the internal_devices context
controls what we can do
mailbox=8920@sixsquares
callerid= Miles Scruggs <8920>
canreinvite=no
Posted: Thu May 22, 2008 5:38 pm Post subject: [Asterisk-video] h263 blackholed.
Yes I was able to get it to work like that, unfortunately though eyebeam doesn't want to dial with the video drawer open. Well it will work but it won't respond to a 407 which means I need to disable auth to get it to work.
On May 22, 2008, at 11:20 AM, Sergio Garcia Murillo wrote:
Quote:
I think there was an option in eyebean but cannot find it in xlite. Anyway, a probably obvious tip,
have you tried to open the video screen in xlite before dialing?
Best regards
Sergio
Miles Scruggs escribió:
Quote:
Do you know of a way to get eyebeam/xlite to announce codecs right out the door?
On May 21, 2008, at 2:26 PM, Sergio Garcia Murillo wrote:
Quote:
Hi,
Try adding videosupport=yes also to sip peers and if you're using Xlite set it to send the invite
with video at first and not re-invite latter with video offer (If i recall correctly from the pastebin).
Best regards
Sergio
Miles Scruggs escribió:
Quote:
Quote:
Damn it looks like my pastebin has expired but we were only sending
one codec, the only thing that would make it fail was to send the
codec to asterisk after the call is setup. If we setup the call with
h263 listed then it would work out of the door, but if the call was
setup without the codec, then a second invite came down the pipe to
asterisk with the new codec (h263) asterisk would pretend to
renegotiate but never passed h263.
On May 21, 2008, at 2:00 PM, Borja Sixto wrote:
Quote:
Hi, the standard asterisk do not support cleanlly the sdp negociation.
Try setting only one video codec.
Regards,
Tech from i6net
----- Message d'origine -----
De: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> (gunnar.hellstrom@omnitor.se)
Env: mercredi 21 mai 2008 19:47
À: 'Development discussion of video media support in Asterisk' <asterisk-video@lists.digium.com (asterisk-video@lists.digium.com)
Objet: Re: [Asterisk-video] h263 blackholed.
You must use a late VIDCAPS to get any usable video support from
Asterisk.
VIDCAPS adds important ability to handle SDP properly in the call
setup.
While watching a full packet dump on the asterisk node, I can see the
h263 coming in from the clients, but it never leaves (asterisk never
originates 1 h263 packet). You can see on line 123 of the pastebin
that the
calls get setup without video but then h263 is renegotiated on line
456.
The second end point sets up h263 on line 313. I'm
pretty lost as to how I can get asterisk to play nice. This is
Asterisk 1.4.18.1
I just was able to test, and if the call sets up (the initial invite
contains) with h263, and isn't done with a re-invite at a later time
then it
works fine.
my sip conf looks like the following:
[general]
type=friend
host=dynamic
context=incoming
srvlookup=yes
canreinvite=no
videosupport=yes
qualify=yes
nat=yes
host=dynamic ; This device registers with us
disallow=all ;better for custom-tunning codec selection allow=ulaw
allow=alaw
allow=h263 ; H.263 is our video codec
allow=h263p ; H.263p is the enhanced video codec
dtmfmode=rfc2833 ; inband is not supported in compressed codecs like
gsm, so
we better set it to rfc2833
[miles_8920_lap]
type=friend
host=dynamic
secret=*****
context=internal_devices ; the internal_devices context
controls what we can do
mailbox=8920@sixsquares
callerid= Miles Scruggs <8920>
canreinvite=no
Posted: Fri May 23, 2008 7:16 am Post subject: [Asterisk-video] h263 blackholed.
I see that your have the canreinivite set to no.
The xten and eyebeam made a reinvite when they toggle to the video mode
I think.
Can you check it ?
Regards,
Tech from i6net
Miles Scruggs a écrit :
Quote:
Yes I was able to get it to work like that, unfortunately though
eyebeam doesn't want to dial with the video drawer open. Well it will
work but it won't respond to a 407 which means I need to disable auth
to get it to work.
On May 22, 2008, at 11:20 AM, Sergio Garcia Murillo wrote:
> I think there was an option in eyebean but cannot find it in xlite.
> Anyway, a probably obvious tip,
> have you tried to open the video screen in xlite before dialing?
>
> Best regards
> Sergio
>
> Miles Scruggs escribió:
>> Do you know of a way to get eyebeam/xlite to announce codecs right
>> out the door?
>>
>>
>> On May 21, 2008, at 2:26 PM, Sergio Garcia Murillo wrote:
>>
>>> Hi,
>>>
>>> Try adding videosupport=yes also to sip peers and if you're using
>>> Xlite set it to send the invite
>>> with video at first and not re-invite latter with video offer (If i
>>> recall correctly from the pastebin).
>>>
>>> Best regards
>>> Sergio
>>>
>>> Miles Scruggs escribió:
>>>> Damn it looks like my pastebin has expired but we were only sending
>>>> one codec, the only thing that would make it fail was to send the
>>>> codec to asterisk after the call is setup. If we setup the call with
>>>> h263 listed then it would work out of the door, but if the call was
>>>> setup without the codec, then a second invite came down the pipe to
>>>> asterisk with the new codec (h263) asterisk would pretend to
>>>> renegotiate but never passed h263.
>>>>
>>>> On May 21, 2008, at 2:00 PM, Borja Sixto wrote:
>>>>
>>>>
>>>>> Hi, the standard asterisk do not support cleanlly the sdp negociation.
>>>>> Try setting only one video codec.
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> Tech from i6net
>>>>>
>>>>> ----- Message d'origine -----
>>>>> De: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
>>>>> Env: mercredi 21 mai 2008 19:47
>>>>> À: 'Development discussion of video media support in Asterisk' <asterisk-video@lists.digium.com
>>>>>
>>>>> Objet: Re: [Asterisk-video] h263 blackholed.
>>>>>
>>>>> You must use a late VIDCAPS to get any usable video support from
>>>>> Asterisk.
>>>>> VIDCAPS adds important ability to handle SDP properly in the call
>>>>> setup.
>>>>>
>>>>> Gunnar
>>>>>
>>>>> -----Original Message-----
>>>>> From: asterisk-video-bounces@lists.digium.com
>>>>> [mailto:asterisk-video-bounces@lists.digium.com] On Behalf Of Miles
>>>>> Scruggs
>>>>> Sent: Tuesday, May 20, 2008 11:37 PM
>>>>> To: asterisk-video@lists.digium.com
>>>>> Subject: [Asterisk-video] h263 blackholed.
>>>>>
>>>>> I'm trying to get asterisk to proxy h263 for a video call, but not
>>>>> having
>>>>> any luck. I have posted a full call trace here:
>>>>>
>>>>> http://pastebin.com/d330aecb5
>>>>>
>>>>> While watching a full packet dump on the asterisk node, I can see the
>>>>> h263 coming in from the clients, but it never leaves (asterisk never
>>>>> originates 1 h263 packet). You can see on line 123 of the pastebin
>>>>> that the
>>>>> calls get setup without video but then h263 is renegotiated on line
>>>>> 456.
>>>>> The second end point sets up h263 on line 313. I'm
>>>>> pretty lost as to how I can get asterisk to play nice. This is
>>>>> Asterisk 1.4.18.1
>>>>>
>>>>> I just was able to test, and if the call sets up (the initial invite
>>>>> contains) with h263, and isn't done with a re-invite at a later time
>>>>> then it
>>>>> works fine.
>>>>>
>>>>> my sip conf looks like the following:
>>>>>
>>>>> [general]
>>>>> type=friend
>>>>> host=dynamic
>>>>> context=incoming
>>>>> srvlookup=yes
>>>>> canreinvite=no
>>>>> videosupport=yes
>>>>> qualify=yes
>>>>> nat=yes
>>>>> host=dynamic ; This device registers with us
>>>>> disallow=all ;better for custom-tunning codec selection allow=ulaw
>>>>> allow=alaw
>>>>> allow=h263 ; H.263 is our video codec
>>>>> allow=h263p ; H.263p is the enhanced video codec
>>>>> dtmfmode=rfc2833 ; inband is not supported in compressed codecs like
>>>>> gsm, so
>>>>> we better set it to rfc2833
>>>>>
>>>>>
>>>>> [miles_8920_lap]
>>>>> type=friend
>>>>> host=dynamic
>>>>> secret=*****
>>>>> context=internal_devices ; the internal_devices context
>>>>> controls what we can do
>>>>> mailbox=8920@sixsquares
>>>>> callerid= Miles Scruggs <8920>
>>>>> canreinvite=no
>>>>>
>>>>> [jon_8926_desk]
>>>>>
>>>>> type=friend
>>>>> host=dynamic
>>>>> secret=*****
>>>>> context=internal_devices
>>>>> mailbox=8926@sixsquares
>>>>> callerid=Jonathan Larsen <8926>
>>>>> canreinvite=no
>>>>>
>>>>> _______________________________________________
>>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>>
>>>>> asterisk-video mailing list
>>>>> To UNSUBSCRIBE or update options visit:
>>>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>>>
>>>>> __________ NOD32 3114 (20080520) Information __________
>>>>>
>>>>> Detta meddelande dr genomsvkt av NOD32 Antivirus.
>>>>> http://www.nod32.com
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>>
>>>>> asterisk-video mailing list
>>>>> To UNSUBSCRIBE or update options visit:
>>>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>>
>>>>> asterisk-video mailing list
>>>>> To UNSUBSCRIBE or update options visit:
>>>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>>>
>>>> _______________________________________________
>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>
>>>> asterisk-video mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>>
>>>
>>> _______________________________________________
>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>
>>> asterisk-video mailing list
>>> To UNSUBSCRIBE or update options visit:
>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-video mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-video
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-video mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-video
Posted: Fri May 23, 2008 7:34 am Post subject: [Asterisk-video] h263 blackholed.
23 maj 2008 kl. 10.04 skrev Borja SIXTO:
Quote:
I see that your have the canreinivite set to no.
The xten and eyebeam made a reinvite when they toggle to the video
mode
I think.
Can you check it ?
>>>>
Canreinvite does not affect Asterisk's support of INCOMING re-invites,
only
whether or not we can redirect the media stream ourselves.
/O
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.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