Re: [asterisk-users] asterisk-users Digest, Vol 177, Issue 11

2019-05-28 Thread Joshua C. Colp 
On Sat, May 25, 2019, at 2:34 PM, Saint Michael wrote:
> Joshua
> Is there a way in PJSIP to send the audio between the parties always, 
> unless one of the parties is behind a NAT?
> A session refresh would work.
> That my only problem with PJSIP. This is routine in the old sip channel.

Any such functionality would be documented on the wiki[1].

[1] 
https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Configuration_res_pjsip

-- 
Joshua C. Colp
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & 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] Asterisk 13.26.0 webRTC: Asterisk not passing along video

2019-05-28 Thread Joshua C. Colp 
On Tue, May 28, 2019, at 9:56 AM, Jonas Kellens wrote:
> Hello
> 
> is this mailing list still active ?

It is still active. Video under chan_sip, however, is not something many do and 
in particular it is possible with WebRTC that something has changed and caused 
problems or there is a bug in a case. The chan_sip module is community 
supported so it does not see a lot of change.

The chan_pjsip module is maintained and in regards to video is something that 
the team at Sangoma who work on Asterisk daily use for video meetings.

-- 
Joshua C. Colp
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & 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] Asterisk 13.26.0 webRTC: Asterisk not passing along video

2019-05-28 Thread Jonas Kellens 

Hello

is this mailing list still active ?




Op 10-05-19 om 14:10 schreef Jonas Kellens:


Hello

I am trying to set up webRTC video calls from my Chrome webbrowser 
(Fedora) to my Chrome webbrowser (Windows 10).


There is local video input (I can see myself), but never video on the 
receiving side.


This is the case in both directions (so it makes no difference which 
peer is calling which peer).



Both webRTC SIP peers have opus and H264 codec in their peer definition :

  Video Support: Yes
  Prim.Transp. : WS
  Allowed.Trsp : WSS
  SIP Options  : (none)
  Codecs   : (opus|h264)
  Status   : OK (75 ms)
  Useragent    : SIP.js/0.12.0
  Reg. Contact : sip:llghjqha@192.0.2.239;transport=wss
  RTP Engine   : asterisk
  Encryption   : Yes
  RTCP Mux : Yes


  Video Support: Yes
  Prim.Transp. : WS
  Allowed.Trsp : WSS
  SIP Options  : (none)
  Codecs   : (opus|h264)
  Status   : OK (47 ms)
  Useragent    : SIP.js/0.12.0
  Reg. Contact : sip:6ltm4mqe@192.0.2.7;transport=wss
  RTP Engine   : asterisk
  Encryption   : Yes
  RTCP Mux : Yes


In general sip.conf I have :

videosupport=yes
disallow=all
allow=alaw
allow=opus
allow=h264


When one peer makes a SIP INVITE for a video call, it is clear to me 
that the necessary codec information is present (this all looks fine 
to me) :


(calling webRTC client)

SIP Debugging Enabled for IP: 99.99.255.55
[May 10 10:45:24]
[May 10 10:45:24] <--- SIP read from WS:99.99.255.55:47732 --->
[May 10 10:45:24] INVITE sip:1...@wss.mydomain.tld SIP/2.0
[May 10 10:45:24] Via: SIP/2.0/WSS 192.0.2.7;branch=z9hG4bK9220692
[May 10 10:45:24] Max-Forwards: 70
[May 10 10:45:24] To: 
[May 10 10:45:24] From: "WC User Chrome" 
;tag=sdmbqkquhe

[May 10 10:45:24] Call-ID: 3g51uvbnnioje6riokqu
[May 10 10:45:24] CSeq: 4132 INVITE
[May 10 10:45:24] Contact: 
[May 10 10:45:24] Allow: 
ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER

[May 10 10:45:24] Supported: outbound
[May 10 10:45:24] User-Agent: SIP.js/0.12.0
[May 10 10:45:24] Content-Type: application/sdp
[May 10 10:45:24] Content-Length: 5098
[May 10 10:45:24]
[May 10 10:45:24] v=0
[May 10 10:45:24] o=- 6075323372920596423 2 IN IP4 127.0.0.1
[May 10 10:45:24] s=-
[May 10 10:45:24] t=0 0
[May 10 10:45:24] a=group:BUNDLE audio video
[May 10 10:45:24] a=msid-semantic: WMS 
I46iog3EpKvlzvX9g0MMsh3ON7hT9qtZwZ4E
[May 10 10:45:24] m=audio 34197 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 
106 105 13 110 112 113 126

[May 10 10:45:24] c=IN IP4 99.99.255.55
[May 10 10:45:24] a=rtcp:9 IN IP4 0.0.0.0
[May 10 10:45:24] a=candidate:2395300328 1 udp 2122260223 
192.168.1.110 34197 typ host generation 0 network-id 1 network-cost 10
[May 10 10:45:24] a=candidate:260925276 1 udp 1686052607 99.99.255.55 
34197 typ srflx raddr 192.168.1.110 rport 34197 generation 0 
network-id 1 network-cost 10
[May 10 10:45:24] a=candidate:3225853208 1 tcp 1518280447 
192.168.1.110 9 typ host tcptype active generation 0 network-id 1 
network-cost 10

[May 10 10:45:24] a=ice-ufrag:y8md
[May 10 10:45:24] a=ice-pwd:nyjEuDKhDVeu8B+OyvuEp6le
[May 10 10:45:24] a=ice-options:trickle
[May 10 10:45:24] a=fingerprint:sha-256 
C9:33:B0:E9:7C:F4:F2:39:98:A6:5C:AE:16:7F:5E:18:99:8F:9F:EB:DC:C6:E3:D5:EA:5B:AE:CD:DE:75:79:0B

[May 10 10:45:24] a=setup:actpass
[May 10 10:45:24] a=mid:audio
[May 10 10:45:24] a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
[May 10 10:45:24] a=sendrecv
[May 10 10:45:24] a=rtcp-mux
[May 10 10:45:24] a=rtpmap:111 opus/48000/2
[May 10 10:45:24] a=rtcp-fb:111 transport-cc
[May 10 10:45:24] a=fmtp:111 minptime=10;useinbandfec=1
[May 10 10:45:24] a=rtpmap:103 ISAC/16000
[May 10 10:45:24] a=rtpmap:104 ISAC/32000
[May 10 10:45:24] a=rtpmap:9 G722/8000
[May 10 10:45:24] a=rtpmap:0 PCMU/8000
[May 10 10:45:24] a=rtpmap:8 PCMA/8000
[May 10 10:45:24] a=rtpmap:106 CN/32000
[May 10 10:45:24] a=rtpmap:105 CN/16000
[May 10 10:45:24] a=rtpmap:13 CN/8000
[May 10 10:45:24] a=rtpmap:110 telephone-event/48000
[May 10 10:45:24] a=rtpmap:112 telephone-event/32000
[May 10 10:45:24] a=rtpmap:113 telephone-event/16000
[May 10 10:45:24] a=rtpmap:126 telephone-event/8000
[May 10 10:45:24] a=ssrc:401971016 cname:cd1IocMPYzY4lNYJ
[May 10 10:45:24] a=ssrc:401971016 
msid:I46iog3EpKvlzvX9g0MMsh3ON7hT9qtZwZ4E 
f8eee8bd-dd47-4c14-866d-07069cab255f
[May 10 10:45:24] a=ssrc:401971016 
mslabel:I46iog3EpKvlzvX9g0MMsh3ON7hT9qtZwZ4E
[May 10 10:45:24] a=ssrc:401971016 
label:f8eee8bd-dd47-4c14-866d-07069cab255f
[May 10 10:45:24] m=video 48086 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 
102 123 127 122 125 107 108 109 124

[May 10 10:45:24] c=IN IP4 99.99.255.55
[May 10 10:45:24] a=rtcp:9 IN IP4 0.0.0.0
[May 10 10:45:24] a=candidate:2395300328 1 udp 2122260223 
192.168.1.110 48086 typ host generation 0 network-id 1 network-cost 10
[May 10 10:45:24] a=candidate:260925276 1 udp 1686052607 99.99.255.55 
48086 typ srflx raddr 192.168.1.110 rport 48086 generation 0 
network-id 1 network-cost 10
[May 10 10:45:24] a=candidate:3225853208 1 tcp 1518280447 
192.168.1.110 9 typ