date:20211013

Re: [asterisk-users] recording not working to NFS

2021-10-13 Thread Telium Technical Support

If unmounting makes your files appear on the NFS mount, then there may be some 
caching going on, or files not being closed (by Asterisk).  Unmounting will 
force files to close and could make them appear.

Try restarting Asterisk (with NFS still mounted).  Do the files then appear?  

-Original Message-
From: asterisk-users [mailto:asterisk-users-boun...@lists.digium.com] On Behalf 
Of cio-al...@playerschool.edu
Sent: Wednesday, October 13, 2021 1:37 PM
To: asterisk-users@lists.digium.com
Subject: [asterisk-users] recording not working to NFS

I have an NFS mount and I am trying to record to it. The mount works fine, I 
create a directory and it shows on the server, I delete it and it gets deleted 
at the server, but Asterisk 16-latest is always recording to the local drive, 
it ignores the NFS mount.
Once I unmount the directory, the recordings show up in the drive.
Is this by design?

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] recording not working to NFS

2021-10-13 Thread cio-alves

I have an NFS mount and I am trying to record to it. The mount works 
fine, I create a directory and it shows on the server, I delete it and 
it gets deleted at the server, but Asterisk 16-latest is always 
recording to the local drive, it ignores the NFS mount.

Once I unmount the directory, the recordings show up in the drive.
Is this by design?

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] [External] Re: Question on ExternalMedia and the codec

2021-10-13 Thread Dan Cropp

Thank you George.

Using slin16 instead of generic slin resolved the issue.

Have a good day!
Dan


From: asterisk-users  On Behalf Of 
George Joseph
Sent: Wednesday, October 13, 2021 8:22 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion 

Subject: [External] Re: [asterisk-users] Question on ExternalMedia and the codec



On Tue, Oct 12, 2021 at 2:54 PM Dan Cropp 
mailto:d...@amtelco.com>> wrote:
We tell asterisk to use the slin format for ExternalMedia.  However, the 
unicast channel is selecting ulaw formatand the RTP data is indicating it’s 
ulaw format.

Anyone know why ulaw format would be on chosen?

What do your ARI requests look like?  Are you just requesting "slin" or one of 
the specific variants?




[10/12 16:13:39.396] DEBUG[1665] http.c: HTTP Request URI is 
/ari/channels/externalMedia?app=a2519b4b-4d90-4d18-906b-717d02f8d569_host=192.168.32.148:8080=slin
[10/12 16:13:39.396] DEBUG[1665] http.c: match request 
[ari/channels/externalMedia] with handler [static] len 6
[10/12 16:13:39.396] DEBUG[1665] http.c: match request 
[ari/channels/externalMedia] with handler [ari] len 3
[10/12 16:13:39.396] DEBUG[1665] http.c: Match made with [ari]
[10/12 16:13:39.396] DEBUG[1665] res_ari.c: Finding handler for 
channels/externalMedia
[10/12 16:13:39.396] DEBUG[1665] res_ari.c:   Finding handler for channels
[10/12 16:13:39.396] DEBUG[1665] res_ari.c: Checking ari deviceStates:  
Didn't match channels
[10/12 16:13:39.396] DEBUG[1665] res_ari.c: Checking ari applications:  
Didn't match channels
[10/12 16:13:39.396] DEBUG[1665] res_ari.c: Checking ari channels:  
Explicit match with channels
[10/12 16:13:39.396] DEBUG[1665] res_ari.c:   Finding handler for externalMedia
[10/12 16:13:39.396] DEBUG[1665] res_ari.c: Checking channels create:  
Didn't match externalMedia
[10/12 16:13:39.396] DEBUG[1665] res_ari.c: Checking channels 
channelId:  Matched wildcard.
[10/12 16:13:39.396] DEBUG[1665] res_ari.c: Checking channels 
externalMedia:  Explicit match with externalMedia
[10/12 16:13:39.396] DEBUG[1665] acl.c: For destination '192.168.32.148', our 
source address is '192.168.33.34'.
[10/12 16:13:39.396] DEBUG[1665] rtp_engine.c: Using engine 'asterisk' for RTP 
instance '0x7fef60018320'
[10/12 16:13:39.396] DEBUG[1665] res_rtp_asterisk.c: (0x7fef60018320) RTP 
allocated port 12226
[10/12 16:13:39.396] DEBUG[1665] res_rtp_asterisk.c: (0x7fef60018320) ICE 
creating session 192.168.33.34:12226 (12226)
[10/12 16:13:39.396] DEBUG[1665] res_rtp_asterisk.c: (0x7fef60018320) ICE create
[10/12 16:13:39.396] DEBUG[1665] res_rtp_asterisk.c: (0x7fef60018320) ICE add 
system candidates
[10/12 16:13:39.396] DEBUG[1665] res_rtp_asterisk.c: (0x7fef60018320) ICE add 
candidate: 192.168.33.34:12226, 2130706431
[10/12 16:13:39.396] DEBUG[1665] rtp_engine.c: RTP instance '0x7fef60018320' is 
setup and ready to go
[10/12 16:13:39.396] DEBUG[1665] channel_internal_api.c:  : 
Formats: (none)
[10/12 16:13:39.396] DEBUG[1665] channel_internal_api.c:  Channel is being 
initialized or destroyed
[10/12 16:13:39.396] DEBUG[1665] stasis.c: Creating topic. name: 
channel:1634055219.4, detail:
[10/12 16:13:39.396] DEBUG[1665] stasis.c: Topic 'channel:1634055219.4': 
0x7fef6008d170 created
[10/12 16:13:39.396] DEBUG[1665] channel.c: Channel 0x7fef6008a910 
'UnicastRTP/192.168.32.148:8080-0x7fef60018320' allocated
[10/12 16:13:39.396] DEBUG[1665] acl.c: For destination '192.168.32.148', our 
source address is '192.168.33.34'.
[10/12 16:13:39.396] DEBUG[1665] channel_internal_api.c:  
UnicastRTP/192.168.32.148:8080-0x7fef60018320: Formats: (ulaw)
[10/12 16:13:39.396] DEBUG[1665] channel_internal_api.c:  New topology set
[10/12 16:13:39.396] DEBUG[1665] res_stasis.c: 
a2519b4b-4d90-4d18-906b-717d02f8d569: Subscribing to 1634055219.4
[10/12 16:13:39.396] DEBUG[1665] stasis/app.c: Channel '1634055219.4' is 1 
interested in a2519b4b-4d90-4d18-906b-717d02f8d569
[10/12 16:13:39.396] DEBUG[1665] http.c: HTTP keeping session open.  
status_code:200
[10/12 16:13:39.396] DEBUG[1666] stasis/app.c: Channel '1634055219.4' is 2 
interested in a2519b4b-4d90-4d18-906b-717d02f8d569

Have a good day!
Dan

This email is intended only for the use of the party to which it is addressed 
and may contain information that is privileged, confidential, or protected by 
law. If you are not the intended recipient you are hereby notified that any 
dissemination, copying or distribution of this email or its contents is 
strictly prohibited. If you have received this message in error, please notify 
us immediately by replying to the message and deleting it from your computer.
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:

Re: [asterisk-users] Question on ExternalMedia and the codec

2021-10-13 Thread George Joseph

On Tue, Oct 12, 2021 at 2:54 PM Dan Cropp  wrote:

> We tell asterisk to use the slin format for ExternalMedia.  However, the
> unicast channel is selecting ulaw formatand the RTP data is indicating it’s
> ulaw format.
>
>
>
> Anyone know why ulaw format would be on chosen?
>

What do your ARI requests look like?  Are you just requesting "slin" or one
of the specific variants?



>
>
>
>
> [10/12 16:13:39.396] DEBUG[1665] http.c: HTTP Request URI is
> /ari/channels/externalMedia?app=a2519b4b-4d90-4d18-906b-717d02f8d569_host=192.168.32.148:8080
> =slin
>
> [10/12 16:13:39.396] DEBUG[1665] http.c: match request
> [ari/channels/externalMedia] with handler [static] len 6
>
> [10/12 16:13:39.396] DEBUG[1665] http.c: match request
> [ari/channels/externalMedia] with handler [ari] len 3
>
> [10/12 16:13:39.396] DEBUG[1665] http.c: Match made with [ari]
>
> [10/12 16:13:39.396] DEBUG[1665] res_ari.c: Finding handler for
> channels/externalMedia
>
> [10/12 16:13:39.396] DEBUG[1665] res_ari.c:   Finding handler for channels
>
> [10/12 16:13:39.396] DEBUG[1665] res_ari.c: Checking ari
> deviceStates:  Didn't match channels
>
> [10/12 16:13:39.396] DEBUG[1665] res_ari.c: Checking ari
> applications:  Didn't match channels
>
> [10/12 16:13:39.396] DEBUG[1665] res_ari.c: Checking ari
> channels:  Explicit match with channels
>
> [10/12 16:13:39.396] DEBUG[1665] res_ari.c:   Finding handler for
> externalMedia
>
> [10/12 16:13:39.396] DEBUG[1665] res_ari.c: Checking channels
> create:  Didn't match externalMedia
>
> [10/12 16:13:39.396] DEBUG[1665] res_ari.c: Checking channels
> channelId:  Matched wildcard.
>
> [10/12 16:13:39.396] DEBUG[1665] res_ari.c: Checking channels
> externalMedia:  Explicit match with externalMedia
>
> [10/12 16:13:39.396] DEBUG[1665] acl.c: For destination '192.168.32.148',
> our source address is '192.168.33.34'.
>
> [10/12 16:13:39.396] DEBUG[1665] rtp_engine.c: Using engine 'asterisk' for
> RTP instance '0x7fef60018320'
>
> [10/12 16:13:39.396] DEBUG[1665] res_rtp_asterisk.c: (0x7fef60018320) RTP
> allocated port 12226
>
> [10/12 16:13:39.396] DEBUG[1665] res_rtp_asterisk.c: (0x7fef60018320) ICE
> creating session 192.168.33.34:12226 (12226)
>
> [10/12 16:13:39.396] DEBUG[1665] res_rtp_asterisk.c: (0x7fef60018320) ICE
> create
>
> [10/12 16:13:39.396] DEBUG[1665] res_rtp_asterisk.c: (0x7fef60018320) ICE
> add system candidates
>
> [10/12 16:13:39.396] DEBUG[1665] res_rtp_asterisk.c: (0x7fef60018320) ICE
> add candidate: 192.168.33.34:12226, 2130706431
>
> [10/12 16:13:39.396] DEBUG[1665] rtp_engine.c: RTP instance
> '0x7fef60018320' is setup and ready to go
>
> [10/12 16:13:39.396] DEBUG[1665] channel_internal_api.c:  :
> Formats: (none)
>
> [10/12 16:13:39.396] DEBUG[1665] channel_internal_api.c:  Channel is being
> initialized or destroyed
>
> [10/12 16:13:39.396] DEBUG[1665] stasis.c: Creating topic. name:
> channel:1634055219.4, detail:
>
> [10/12 16:13:39.396] DEBUG[1665] stasis.c: Topic 'channel:1634055219.4':
> 0x7fef6008d170 created
>
> [10/12 16:13:39.396] DEBUG[1665] channel.c: Channel 0x7fef6008a910
> 'UnicastRTP/192.168.32.148:8080-0x7fef60018320' allocated
>
> [10/12 16:13:39.396] DEBUG[1665] acl.c: For destination '192.168.32.148',
> our source address is '192.168.33.34'.
>
> [10/12 16:13:39.396] DEBUG[1665] channel_internal_api.c:
> UnicastRTP/192.168.32.148:8080-0x7fef60018320: Formats: (ulaw)
>
> [10/12 16:13:39.396] DEBUG[1665] channel_internal_api.c:  New topology set
>
> [10/12 16:13:39.396] DEBUG[1665] res_stasis.c:
> a2519b4b-4d90-4d18-906b-717d02f8d569: Subscribing to 1634055219.4
>
> [10/12 16:13:39.396] DEBUG[1665] stasis/app.c: Channel '1634055219.4' is 1
> interested in a2519b4b-4d90-4d18-906b-717d02f8d569
>
> [10/12 16:13:39.396] DEBUG[1665] http.c: HTTP keeping session open.
> status_code:200
>
> [10/12 16:13:39.396] DEBUG[1666] stasis/app.c: Channel '1634055219.4' is 2
> interested in a2519b4b-4d90-4d18-906b-717d02f8d569
>
>
>
> Have a good day!
>
> Dan
>
> This email is intended only for the use of the party to which it is
> addressed and may contain information that is privileged, confidential, or
> protected by law. If you are not the intended recipient you are hereby
> notified that any dissemination, copying or distribution of this email or
> its contents is strictly prohibited. If you have received this message in
> error, please notify us immediately by replying to the message and deleting
> it from your computer.
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users
--

Re: [asterisk-users] [External] Re: SIP INFO messages with Content-Type: application/media_control+xml

2021-10-13 Thread Floimair Florian

Thanks Josh!

I was already suspecting something like this.

FLORIAN FLOIMAIR



Von: asterisk-users  im Auftrag von 
"Joshua C. Colp" 
Antworten an: Asterisk Users Mailing List - Non-Commercial Discussion 

Datum: Mittwoch, 13. Oktober 2021 um 15:12
An: Asterisk Users Mailing List - Non-Commercial Discussion 

Betreff: [External] Re: [asterisk-users] SIP INFO messages with Content-Type: 
application/media_control+xml


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.
On Wed, Oct 13, 2021 at 10:05 AM Floimair Florian 
mailto:f.floim...@commend.com>> wrote:
Hi all!

We have a WebRTC user-agent (using sip.js) that is giving me headache.

When a different user-agent calls this user-agent, we frequently see Asterisk 
generating SIP INFO messages with

Content-Type: application/media_control+xml
Content-Length: 178



  
   

  



In the payload, that is sent from Asterisk to the caller UA (the WebRTC client 
is the callee).

While this does not do any harm usually, I have no clue yet what causes 
Asterisk to generate these INFO messages.
I do know what they are for 
(https://datatracker.ietf.org/doc/html/rfc5168),
 but not why Asterisk is generating those or what might be the trigger.

Anyone have any hint?

They will occur as a result of a video client requesting a full frame, and 
there's a few places in Asterisk where it will generate one in certain 
scenarios. Generally it comes from another client though. It can be received 
either using an incoming INFO request, or via RTCP through a PLI or FIR. If 
using PJSIP then the INFO request is only used for the H.264 codec if the 
WebRTC option is not enabled.

--
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at 
www.sangoma.com
 and 
www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] SIP INFO messages with Content-Type: application/media_control+xml

2021-10-13 Thread Joshua C. Colp

On Wed, Oct 13, 2021 at 10:05 AM Floimair Florian 
wrote:

> Hi all!
>
>
>
> We have a WebRTC user-agent (using sip.js) that is giving me headache.
>
>
>
> When a different user-agent calls this user-agent, we frequently see
> Asterisk generating SIP INFO messages with
>
>
>
> Content-Type: application/media_control+xml
>
> Content-Length: 178
>
>
>
> 
>
> 
>
>   
>
>
>
> 
>
>   
>
> 
>
> 
>
>
>
> In the payload, that is sent from Asterisk to the caller UA (the WebRTC
> client is the callee).
>
>
>
> While this does not do any harm usually, I have no clue yet what causes
> Asterisk to generate these INFO messages.
> I do know what they are for (https://datatracker.ietf.org/doc/html/rfc5168),
> but not why Asterisk is generating those or what might be the trigger.
>
>
>
> Anyone have any hint?
>

They will occur as a result of a video client requesting a full frame, and
there's a few places in Asterisk where it will generate one in certain
scenarios. Generally it comes from another client though. It can be
received either using an incoming INFO request, or via RTCP through a PLI
or FIR. If using PJSIP then the INFO request is only used for the H.264
codec if the WebRTC option is not enabled.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] SIP INFO messages with Content-Type: application/media_control+xml

2021-10-13 Thread Floimair Florian

Hi all!

We have a WebRTC user-agent (using sip.js) that is giving me headache.

When a different user-agent calls this user-agent, we frequently see Asterisk 
generating SIP INFO messages with

Content-Type: application/media_control+xml
Content-Length: 178



  
   

  



In the payload, that is sent from Asterisk to the caller UA (the WebRTC client 
is the callee).

While this does not do any harm usually, I have no clue yet what causes 
Asterisk to generate these INFO messages.
I do know what they are for (https://datatracker.ietf.org/doc/html/rfc5168), 
but not why Asterisk is generating those or what might be the trigger.

Anyone have any hint?

Thanks and best regards


FLORIAN FLOIMAIR
Symphony Cloud Services (1568)

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] recording not working to NFS

[asterisk-users] recording not working to NFS

Re: [asterisk-users] [External] Re: Question on ExternalMedia and the codec

Re: [asterisk-users] Question on ExternalMedia and the codec

Re: [asterisk-users] [External] Re: SIP INFO messages with Content-Type: application/media_control+xml

Re: [asterisk-users] SIP INFO messages with Content-Type: application/media_control+xml

[asterisk-users] SIP INFO messages with Content-Type: application/media_control+xml

7 matches

Site Navigation

Mail list logo

Footer information