I need to get hooked up with this class, I could have students doing projects for homework :) Interested in RTCP? j On 6/26/23 7:45 PM, TTT wrote:> > I’m in training, so I have to demonstrate something SIP related. I > figure it would be cool to hack a call, hanging it up while in > progress from outside Asterisk. Doing so will demonstrate > use/knowledge of ARI, AMI, SIP, route-sets, UDP, etc. > > Practical value: *zero* > > J > > Who knows, maybe this will have an actual application for someone > someday. In practical terms I think building a proxy would be the > right way to manipulate the SIP for a call in progress, but that > sounds like a huge project. I’ve got to demonstrate something by end > of week. > > *From:*asterisk-users [mailto:asterisk-users-bounces at lists.digium.com] > *On Behalf Of *Jeff LaCoursiere > *Sent:* Monday, June 26, 2023 6:20 PM > *To:* asterisk-users at lists.digium.com > *Subject:* Re: [asterisk-users] Get channel variables via ARI/AMI > > On 6/26/23 9:00 AM, Joshua C. Colp wrote: > > On Mon, Jun 26, 2023 at 10:57 AM TTT <lists at telium.io> wrote: > > I am connecting to the ARI with subscribe all, so I can see > channels being created. I now want to extract a variety of > header variables (at the moment the from and to tag). I tried > to read them from the ARI but Asterisk refuses since the > channel is not in a stasis app. > > Is there a way to read these from either the ARI or AMI ? I’m > trying not to modify the dialplan. > > ARI, No. > > AMI, Yes[1]. > > [1] > https://wiki.asterisk.org/wiki/display/AST/Asterisk+20+ManagerAction_Getvar > > I'm curious what the actual application is here - you want to connect > to AMI to pull information that you will use to pretend to be a leg, > just to send "BYE", when you could just hangup the leg with AMI (or do > just about anything else you might think of). Sometimes it is better > to fully explain what you are trying to accomplish, and some folks > here can try to steer you towards a workable solution. It almost > sounds... nefarious. > > Cheers, > > -- > Jeff LaCoursiere > StratusTalk, Inc. > 703 496 4990 x108 > 815 546 6599 cell >-- Jeff LaCoursiere StratusTalk, Inc. 703 496 4990 x108 815 546 6599 cell -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20230626/eda65dcc/attachment.html>
Jonas Kellens
2023-Jun-28 14:14 UTC
[asterisk-users] SDP a=ice-ufrag & a=ice-pwd UNSUPPORTED OR FAILED
Hello list when trying to set up webRTC communications with sipjs client package (tried 0.7.0, 0.10.0 and 0.19.0), I see in the asterisk debug log-file the following : DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP c=IN IP4 99.88.77.66... OK. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=rtcp:9 IN IP4 0.0.0.0... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=candidate:4275385644 1 udp 2122260223 192.168.0.18 57987 typ host generation 0 network-id 1... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=candidate:3686672562 1 udp 2122194687 172.21.64.1 57988 typ host generation 0 network-id 2... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=candidate:4292167434 1 udp 1686052607 99.88.77.66 57987 typ srflx raddr 192.168.0.18 rport 57987 generation 0 network-id 1... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=candidate:8380856 1 tcp 1518280447 192.168.0.18 9 typ host tcptype active generation 0 network-id 1... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=candidate:622132262 1 tcp 1518214911 172.21.64.1 9 typ host tcptype active generation 0 network-id 2... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=ice-ufrag:zBkv... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=ice-pwd:8LVdZW/AEq7hp898bLtsI/5W... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=ice-options:trickle... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=fingerprint:sha-256 92:6B:C7:79:41:B1:42:78:2B:3A:75:8B:0B:D0:C7:4C:7C:4E:4F:2D:03:A2:DA:D9:BB:CE:B2:39:5D:20:A0:EF... OK. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=setup:actpass... OK. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=mid:0... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=sendrecv... OK. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=msid:4f4db37d-65ff-4f57-8c1c-b404f976c3fb cc4a3d72-3e9d-4926-b57c-056b6e7a6d6c... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=rtcp-mux... OK. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=rtpmap:111 opus/48000/2... OK. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=rtcp-fb:111 transport-cc... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=fmtp:111 minptime=10;useinbandfec=1... OK. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=rtpmap:63 red/48000/2... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=fmtp:63 111/111... UNSUPPORTED OR FAILED. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=rtpmap:9 G722/8000... OK. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=rtpmap:0 PCMU/8000... OK. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=rtpmap:8 PCMA/8000... OK. DEBUG[30891][C-00000000] chan_sip.c: Processing media-level (audio) SDP a=rtpmap:13 CN/8000... OK in sip.conf I have : icesupport = yes in rtp.conf I have : icesupport=true stunaddr=stun.ekiga.net sip peer has everything set for webrtc : Realtime peer: Yes, cached Prim.Transp. : WS Allowed.Trsp : WSS Codecs : (alaw|g729|gsm) Useragent : SIP.js/0.10.0 Reg. Contact : sip:u79mer6v at 1u7hp86jdg67.invalid;transport=ws RTP Engine : asterisk Encryption : Yes RTCP Mux : Yes avpf = yes force_avp =yes icesupport = yes dtlsenable = yes dtlsverify = fingerprint dtlssetup = actpass dtlsfingerprint = sha-256 Why is there "UNSUPPORTED OR FAILED" in the log when processing "a=ice-ufrag" and "ice-pwd" ?? Asterisk gives no "a=ice-ufrag" and "ice-pwd" in its "SIP/2.0 200 OK" response to the INVITE and thus sipjs aborts the SIP call with a 488-"Not Acceptable Here". I read about libuuid-devel and uuid-devel are necessary, but I have these installed ! What am I missing here ?! Kind regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20230628/2ab51c2d/attachment.html>