similar to: Getvar of CHANNEL not working for a couple of items

Building on my last message, I am trying to get CHANNEL data using getvar (through the AMI). And although I'm getting responses, some values returned seem illogical. For example, phone 111 calls phone 222 via the PBX. Here's the data I get back Channel A: "1688509741.112" , name: "PJSIP/111-00000064" , is originator: Y , call-Id: "u.l6kcou25cax60 at

On Tue, Jul 4, 2023 at 7:52 PM TTT <lists at telium.io> wrote: > Building on my last message, I am trying to get CHANNEL data using getvar > (through the AMI). And although I'm getting responses, some values > returned seem illogical. For example, phone 111 calls phone 222 via the > PBX. Here's the data I get back > > > > > > Channel A:

Channel A: "1688509741.112" , name: "PJSIP/111-00000064" , is originator: Y , call-Id: "u.l6kcou25cax60 at mydomain.com <mailto:u.l6kcou25cax60 at mydomain.com> " , local_uri: "<sip:222 at mydomain.com <mailto:sip%3A222 at mydomain.com> ;user=phone>" , local_tag: "1734d973-c4da-4ae8-a37d-5f7065f1fe54" , local_addr:

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-0000007d [2023-07-06 11:40:35] WARNING[935126]: func_channel.c:527 func_channel_read: Unknown or unavailable item requested: 'pjsip,local_addr' [2023-07-06 11:40:35]

On Mon, Jun 26, 2023 at 4:04 PM TTT <lists at telium.io> wrote: > It looks like if I call Getvar and pass PJSIP_HEADERS() I can get the > entire SIP header for a channel. I also read (on stackoverflow) that the > PJSIP_HEADER function will only return the headers from the INVITE of the > *inbound* channel. > > > > If that’s correct, how would I get the headers from

I think that’s getting me close. I’m trying to get (or recreate) the FROM and TO lines of the header, from a system running PJSIP. I think if I use CHANNEL to get local_uri and local_tag I can recreate a FROM line like: FROM=<URI>;tag=TAG And if I use CHANNEL to get remote_uri and remote_tag I can recreate a FROM line like: TO=<URI>;tag=TAG Would it be correct to assume

On Mon, Jun 26, 2023 at 4:35 PM TTT <lists at telium.io> wrote: > I think that’s getting me close. I’m trying to get (or recreate) the FROM > and TO lines of the header, from a system running PJSIP. I think if I use > CHANNEL to get local_uri and local_tag I can recreate a FROM line like: > > *FROM=<URI>;tag=TAG* > > > > And if I use CHANNEL to get

Hia .... i try to use the fonction Getvar of asterisk to get a variable myDNIS that i have define. i use it as follow Action: Getvar Channel: SIP... Variable: myDNIS but asterisk don't know it .i have the response as follow Response: Error Message: Invalid/unknown command does everybody meet this problem . i try all possible combination and nothing help please ..!! :-( thanks in advance

>> You use the AMI action Getvar[1] which allows channel variables and dialplan functions. >> [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+20+ManagerAction_Getvar I actually tried that, and although I get “success” I never get useful data. For example: action: Getvar actionid: act1 channel: PJSIP/Twilio-NA-W-2-In-00000025 Variable: channel(pjsip,call-id)

On Sun, Jul 2, 2023 at 4:18 PM TTT <lists at telium.io> wrote: > >> There are SOME protocol level things accessible using CHANNEL[1] but > that's it. > > >> [1] > https://wiki.asterisk.org/wiki/display/AST/Asterisk+20+Function_CHANNEL > > > > > > I am trying to use the CHANNEL function listed above from the AMI. Since > it is not an AMI

On Sun, Jul 2, 2023 at 4:39 PM TTT <lists at telium.io> wrote: > >> You use the AMI action Getvar[1] which allows channel variables and > dialplan functions. > > >> [1] > https://wiki.asterisk.org/wiki/display/AST/Asterisk+20+ManagerAction_Getvar > > > > > I actually tried that, and although I get “success” I never get useful > data. For

The uppercase command made a difference. I now get a call-id as show below. However, does the call-id look valid? The @0.0.0.0 seems strange. action: Getvar actionid: act1 channel: PJSIP/Twilio-NA-W-3-In-00000028 Variable: CHANNEL(pjsip,call-id) Response: Success ActionID: act1 Variable: CHANNEL(pjsip,call-id) Value: 4decf884e3ae74595906283a74f7154e at 0.0.0.0 As well,

From: Andy King <acking at vmware.com> ** Introduce VM Sockets *** In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the VM Sockets (VSOCK, formerly VMCI Sockets) (vmw_vsock) kernel module for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. Unlike previous

From: Andy King <acking at vmware.com> ** Introduce VM Sockets *** In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the VM Sockets (VSOCK, formerly VMCI Sockets) (vmw_vsock) kernel module for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. Unlike previous

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

On 2016?12?06? 23:41, Michael S. Tsirkin wrote: > These fields are 64 bit, using le32_to_cpu and friends > on these will not do the right thing. > Fix this up. > > Cc: stable at vger.kernel.org > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > net/vmw_vsock/virtio_transport_common.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7

On 2016?12?06? 23:41, Michael S. Tsirkin wrote: > These fields are 64 bit, using le32_to_cpu and friends > on these will not do the right thing. > Fix this up. > > Cc: stable at vger.kernel.org > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > net/vmw_vsock/virtio_transport_common.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7

Am 15.06.2020 um 21:50 schrieb Luca Bertoncello: > What do you mean now? If I can use the full available band or if I can > download exactly 50Mbs? > The answer to the first question is: YES! That's why I use a traffic > shaper... ;) > The answer to the second question is: NO. I made a speedtest right now > and I get only ~18Mbps download. And some other information, too.

Most of the patches are reviewed by Dexuan, Stefan, and Jorgen. The following patches need reviews: - [11/15] vsock: add multi-transports support - [12/15] vsock/vmci: register vmci_transport only when VMCI guest/host are active - [15/15] vhost/vsock: refuse CID assigned to the guest->host transport RFC: https://patchwork.ozlabs.org/cover/1168442/ v1: