On 7/6/2023 7:08 PM, John Covici wrote:
Hi. I have run into a problem compiling dahdi-linux in kernel
6.1.0-10. Apparently there was a change, so I found a patch to fix
stdbool.h but now I have an implicit declaration of
pci_alloc_consistent in drivers/dahdi/wct4xxp/base.c I don't see any
Hi. I have run into a problem compiling dahdi-linux in kernel
6.1.0-10. Apparently there was a change, so I found a patch to fix
stdbool.h but now I have an implicit declaration of
pci_alloc_consistent in drivers/dahdi/wct4xxp/base.c I don't see any
other references to that name anywhere. I am
FYI: i've created a feature request to add SIP_CODEC_INBOUND equivalent
functionality to chan_pjsip:
https://github.com/asterisk/asterisk-feature-requests/issues/9
Let's see where it goes
*Michael Ulitskiy*
Ace Innovative Networks, Inc.
Main/SMS: 212-868-2366
Direct/SMS: 212-812-1203
On Thu, Jul 6, 2023 at 2:22 PM Michael Ulitskiy
wrote:
> Oh, that's great. It wasn't clear from that page, at least not for me. :-(
>
> Having it clearly stated on the document would save me (and probably
> others) lots of time.
>
The wiki is read-only now and documentation has moved to
Oh, that's great. It wasn't clear from that page, at least not for me. :-(
Having it clearly stated on the document would save me (and probably
others) lots of time.
Thanks for clarifying it. Any idea on the timeframe of implementation?
*Michael Ulitskiy*
Ace Innovative Networks, Inc.
On Thu, Jul 6, 2023 at 1:43 PM Michael Ulitskiy
wrote:
> Hello,
>
> After I have re-read the "PJSIP Advanced Codec negotiation" document, it
> occurred to me that the desired behavior should actually happen
> automatically, just due to the codec negotiation logic, but it looks like
> asterisk
I suspect most people simply don't care. Transcoding between ulaw and
g722 is not CPU intensive and Direct Media doesn't work when NAT is
involved (which would the case for most people).
On 7/5/23 17:22, Michael Ulitskiy wrote:
Well, I'm trying to migrate to chan_pjsip so that I don't have
Hello,
After I have re-read the "PJSIP Advanced Codec negotiation" document, it
occurred to me that the desired behavior should actually happen
automatically, just due to the codec negotiation logic, but it looks
like asterisk doesn't actually follow the described logic which is
likely a
I found a clue as to why the second leg is not returning a local or remote
address:
[2023-07-06 11:40:35] WARNING[253072]: pjsip/dialplan_functions.c:903
channel_read_pjsip: No transport information for channel PJSIP/222-007d
[2023-07-06 11:40:35] WARNING[935126]: func_channel.c:527
