Why not use SIP? They even suggest it when setting up your account.
NAT issues?
Two reasons: first, I do indeed have NAT all over the place, although I
think Luigi's recent work may make that a non-issue.
The bigger reason, though, is that I want to support IAX, which I
believe
Edwin,
You are running into a RE-INVITE glare scenario. The Asterisk boxes
facing each other are racing to send RE-INVITE to each other to drop
the RTP hairpin. The Asterisk 1.4 does not retransmit a RE-INVITE on
receving a 491 response. It is treating 491 as a permanent failure and
therefore
Does anybody knows how Josh Colp is doing with the bridging API? I
think it has been almost a year since that branch was open, but not
sure if he is actively working on it, I would love to hear about it
checking SVN
Regards
I think I can speak for Josh Colp :D
I've been
On Aug 16, 2007, at 7:37 AM, Stephen Davies wrote:
Now I'd like to fix this. But which is the best way:
1) Have the caller rearrange the codec_prefs so that the current codec
(ilbc) is moved to the top
2) Have the callee note the format and use that if its anywhere in the
allow as first
In article [EMAIL PROTECTED], Joshua Colp [EMAIL PROTECTED] wrote:
I've been working on the bridging API rather heavily over the past week
or so. It can currently handle bridging two channels together and
multi-channel bridges fine and dandy, as is demonstrated by the
BridgeTest and
Mihai Balea wrote:
The way I read the spec is that if you have a CODEC PREFS IE in your NEW
message, it takes precedence over FORMAT and CAPABILITIES. So in your
case, the caller should arrange its codec prefs list to reflect its
actual preferences (ilbc on top) and the callee should ignore
John Todd wrote:
Since the bugtracker is now deemed off-limits for submitting
feature requests, I suppose that leaves only the list as a location
for discussion of such things, though I don't quite know where to
Slight clarification: what you have offered is not a 'feature request',
it's a
Now it works.
Thanks a lot, guys.
On 8/15/07, Donny Kavanagh [EMAIL PROTECTED] wrote:
Fixes can no longer be applied to 1.2, try 1.4 and let us know what
happens.
If it crashes with 1.4 then file a bug report.
Donny
On 8/15/07, Fadil Sutomo [EMAIL PROTECTED] wrote:
I did that.
Still
Tony Mountifield wrote:
In article [EMAIL PROTECTED], Joshua Colp [EMAIL PROTECTED] wrote:
I've been working on the bridging API rather heavily over the past week
or so. It can currently handle bridging two channels together and
multi-channel bridges fine and dandy, as is demonstrated by the
Hello folks,
As has been recently discussed I've been working on a new bridging API.
What will this give us? Better control over bridges, more features, and
a general cleaner API. Now on to the good stuff...
NOTE: Some of the stuff described here is not yet written, simply on my
white board.
On 16/08/07, Mihai Balea [EMAIL PROTECTED] wrote:
Generally speaking, IAX2 codec negotiation is somewhat broken. It
allows for only one codec to be selected as THE codec for the call.
This is insufficient when trying to do video, since a video call
would need two codecs, one for video and one
On 16/08/07, Mihai Balea [EMAIL PROTECTED] wrote:
The way I read the spec is that if you have a CODEC PREFS IE in your
NEW message, it takes precedence over FORMAT and CAPABILITIES. So in
your case, the caller should arrange its codec prefs list to reflect
its actual preferences (ilbc on top)
On Aug 16, 2007, at 4:28 PM, Stephen Davies wrote:
Interestingly I know that video *used* to work with IAX because I
remember showing it off with someone long ago. Probably back when the
codec stuff was done just with the FORMAT IE rather than the prefs.
Well, we are doing video over IAX in
13 matches
Mail list logo
