00:26.04 | *** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |
00:34.27 | *** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |
00:52.19 | *** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |
02:07.03 | *** join/#asterisk jkroon (~jkroon@165.16.204.99) |
02:08.04 | *** join/#asterisk tsal_ (~tsal@i59F4D9F0.versanet.de) |
07:52.23 | *** join/#asterisk fling (~fling@fsf/member/fling) |
07:56.45 | *** join/#asterisk BakaKuna (~Thunderbi@2a02-a446-ae46-1-f564-1908-e9e4-28b4.fixed6.kpn.net) |
08:21.44 | *** join/#asterisk mahafyi (6ac600e5@106.198.0.229) |
08:42.08 | *** join/#asterisk lankanmon (~LKNnet@cpeb4fbe4e331bd-cm64777d632380.cpe.net.cable.rogers.com) |
09:33.05 | *** join/#asterisk jkroon (~jkroon@165.16.204.99) |
09:39.14 | *** join/#asterisk jkroon (~jkroon@165.16.204.99) |
09:53.42 | *** join/#asterisk sekil (~sekil@79-101-146-239.dynamic.isp.telekom.rs) |
09:54.11 | kerouac[m] | Guys, I don't get basic concept of asterisk and sip. Am I right, saying: asterisk is the only point of meeting of two clients and then when call is connected, they communicate p2p? |
10:12.12 | sekil | yes and no |
10:13.18 | kerouac[m] | sekil: can you link some stuff that could explain that? |
10:16.04 | sekil | usually sip messages go via sip server and rtp goes in between endpoints |
10:16.54 | sekil | but with b2bua server and RTP media serve such as * RTP can go through * as well |
10:17.46 | kerouac[m] | So, protocol used between endpoints is rtp? |
10:17.46 | kerouac[m] | And what about situation when one client is connected by udp and other one by webRTC? Or i'm missing something |
10:18.32 | sekil | no |
10:18.39 | sekil | rtp is for media |
10:18.50 | sekil | sip is signalling |
10:20.12 | sekil | webrtc is just a http thing to provide communication of endpoints |
10:20.16 | sekil | not even signalling proto |
10:20.50 | sekil | if you need to bridge sip and webrtc clients..than * or FreeSWITCH come in |
10:21.19 | kerouac[m] | does it matters if I use rtp or rtsp? |
10:22.32 | sekil | rtsp is protocol for streaming media |
10:22.47 | sekil | rtp is for interactive media so to speak |
10:23.01 | sekil | rtp stack is embedded with sip clients |
10:24.33 | kerouac[m] | Thank you |
12:18.57 | kerouac[m] | I have asterisk behind vpn, and two linphones, on laptop and pc. When I call, the sound is only on answering side. If I call from laptop to pc, then only PC listens sound, and PC's sound doesn't goes to laptop even though linphone shows PC's microphone live indicator. And if I call from PC, I see the same, but sound is only on laptop, and PC doesn't hear laptop. |
12:19.05 | kerouac[m] | What could be the reason? |
12:28.06 | sekil | probably nat/vpn/rtp |
12:33.45 | kerouac[m] | as I know rtp :7078 is opened in NAT for both in and out. |
13:07.15 | *** join/#asterisk paulgrmn (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
13:33.40 | *** part/#asterisk sekil (~sekil@79-101-146-239.dynamic.isp.telekom.rs) |
13:55.43 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
13:56.58 | *** join/#asterisk gtjoseph (~gtjoseph@unaffiliated/gtj) |
13:56.58 | *** mode/#asterisk [+o gtjoseph] by ChanServ |
14:03.51 | *** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt) |
14:05.16 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda00b2cb896f33bd8139.dip0.t-ipconnect.de) |
14:12.14 | *** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt) |
14:16.33 | *** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt) |
14:53.38 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-csxwkorrzpzsbrcj) |
14:53.38 | *** mode/#asterisk [+o bford] by ChanServ |
15:07.44 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
15:42.15 | *** join/#asterisk stux|work (stux@endurance.xzibition.com) |
16:05.37 | *** join/#asterisk Janos (~textual@201.204.94.76) |
17:08.45 | *** join/#asterisk BakaKuna1 (~Thunderbi@2a02-a446-ae46-1-f564-1908-e9e4-28b4.fixed6.kpn.net) |
17:09.21 | *** join/#asterisk Gugge_ (gugge@guggemand.dk) |
17:09.40 | *** join/#asterisk koltrast_ (21615e77@h77-53-57-114.cust.a3fiber.se) |
17:12.14 | *** join/#asterisk jwpierce3 (jwpierce3@mail.zero.svr.trnkmstr.com) |
17:13.20 | *** join/#asterisk john2gb (~john2gb@94-225-47-8.access.telenet.be) |
17:14.43 | *** join/#asterisk ttys000 (~ttys000@50.92.212.41) |
17:54.39 | *** join/#asterisk retentiveboy (~retentive@2601:cf:4500:5ea3:4e79:3a73:a83d:6a44) |
18:05.12 | *** join/#asterisk kerouac[m] (kerouacmat@gateway/shell/matrix.org/x-kdmxdjlxpjxqkvae) |
18:08.51 | *** join/#asterisk tsal (~tsal@i59F4D9F0.versanet.de) |
18:16.00 | *** join/#asterisk MLC (~MLC@63.249.40.11) |
18:17.02 | MLC | It seems that "voicemail reload" will not handle a new voicemail context. Is there a way to introduce a new voicemail context without restart? |
18:28.11 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda00bbbb301530e8c325.dip0.t-ipconnect.de) |
18:34.25 | MLC | maybe it did after all. I was expecting it to create all of the voicemail boxes in the file system, but maybe it only does that when they are needed. |
18:39.18 | igcewieling | MLC correct. mailboxes are created when first accessed |
18:39.34 | igcewieling | the files/dirs. the config applies on reload. |
18:40.01 | MLC | good. thanks. |
18:46.46 | *** join/#asterisk sinaowolabi (~Sina@105.112.145.121) |
19:10.48 | *** join/#asterisk gschanuel2 (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
19:13.09 | *** join/#asterisk fstd (~fstd@unaffiliated/fisted) |
19:20.14 | igcewieling | 3rd Verizon dispatch and still service is not working as ordered. |
19:20.33 | *** part/#asterisk MLC (~MLC@63.249.40.11) |
19:21.59 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
19:31.25 | *** join/#asterisk themayor (~themayor@unaffiliated/themayor) |
19:49.57 | *** join/#asterisk gtjoseph (~gtjoseph@unaffiliated/gtj) |
19:49.58 | *** mode/#asterisk [+o gtjoseph] by ChanServ |
19:54.14 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
20:04.25 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
20:49.42 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
20:57.17 | *** join/#asterisk Posterdati (~posterdat@host-87-21-221-219.retail.telecomitalia.it) |
20:57.18 | *** join/#asterisk Maxxed (~Maxxed@nrgt.net) |
20:57.19 | *** join/#asterisk void09 (~void@revinin5minute.com) |
20:57.47 | *** join/#asterisk john2gb (~john2gb@94-225-47-8.access.telenet.be) |
21:23.26 | Kobaz | anyone know how to get a polycom phone to send rport in their invites? |
21:23.52 | Kobaz | it might be voIpProt.SIP.rport |
21:24.53 | Samot | It is. |
21:25.26 | Kobaz | nice, making sure i found the right option |
21:28.13 | *** join/#asterisk Maliuta (maliutamat@gateway/shell/matrix.org/x-gvhujehkqqbuyjpn) |
21:28.44 | *** join/#asterisk Janos (~textual@201.204.94.76) |
21:31.20 | igcewieling | What are your trying to solve? |
21:32.05 | Kobaz | Oh, well I turned off allow_reload in pjsip, so I can't change local_net... or at least I don't think I can... Haven't tried it honestly, after i turned off allow_reload |
21:32.24 | Kobaz | so rport fixes that |
21:40.03 | igcewieling | Wouldn't switching to TCP remove any need for rport? |
21:40.14 | Kobaz | possibly |
21:40.17 | igcewieling | would not help with your lack of reloading transports, but still... |
21:44.54 | Samot | Wait. |
21:45.11 | Samot | How does allow_reload being off stop you from changing local_net settings? |
21:45.30 | Kobaz | I have no idea |
21:45.35 | Samot | It doesn't. |
21:45.41 | Kobaz | I don't know what's restricted on reload |
21:45.59 | Samot | It just means when PJSIP is reloaded it doesn't reload transports. You need to restart Asterisk. |
21:46.22 | Samot | How often are you adding local networks? |
21:46.34 | Kobaz | can be frequently depending on the site? |
21:46.57 | Samot | A site has multiple voice networks? |
21:47.18 | Kobaz | Yeah typically |
21:47.33 | Samot | Why? |
21:49.06 | Kobaz | Depends on the customer |
21:49.17 | Kobaz | they might spin up a new site and then they say here's a new ip range |
21:49.42 | Samot | That's a secondary site. |
21:49.53 | Kobaz | some people have something pretty like all voice is on 10.100.0.0/16 |
21:50.12 | Samot | Let's try this, how often do you need to add local_net updates? |
21:50.16 | Samot | Regardless of how many customers. |
21:50.20 | Samot | Are you doing it daily? |
21:50.24 | Samot | 5 x a day? |
21:50.33 | Kobaz | Oh, not daily typically |
21:50.33 | Samot | 3 x a week? |
21:50.41 | Kobaz | Few times a month |
21:50.50 | Samot | Wow, so you can actually plan this. |
21:50.54 | Kobaz | Haha |
21:50.59 | Samot | Restart when needed. |
21:51.24 | Kobaz | And customers with 24/7 operations? |
21:51.34 | Samot | You mean like hotels? |
21:51.42 | Samot | Places that what, can't be updated ever? |
21:51.44 | Kobaz | Why should I have to flip servers or do anything like that to make what should be a basic change |
21:51.55 | Samot | That can't handle a few minutes of possible downtime in off hours? |
21:52.02 | Samot | Because it's a TRANSPORT |
21:52.20 | Samot | It's not really something that needs to be reloaded on the reg. |
21:52.32 | Kobaz | No but, chan_sip does not have this limitation |
21:52.40 | Kobaz | Just, extra complexity, you know |
21:52.41 | Samot | You're right. |
21:52.52 | Samot | It doesn't allow you to have multiple bind IPs |
21:52.53 | Samot | ports |
21:52.58 | Samot | For UDP |
21:52.59 | Kobaz | Sure |
21:53.03 | Kobaz | It's got limits |
21:53.15 | Samot | Chan_SIP didn't have this option because of Chan_SIP's limitations. |
21:53.38 | Samot | In the grand scheme of SIP stacks, Chan_SIP was found wanting. |
21:54.02 | Samot | It lacked basic things that other SIP stacks could do. |
21:55.23 | Samot | Are these premises systems? Or are they connecting back to you with a VPN? |
21:55.55 | Kobaz | It's a mix |
21:56.45 | Samot | Do they each get their own system? |
21:58.35 | igcewieling | don't your clients failover to another server if the primary server is down? |
21:58.54 | Kobaz | Yeah |
21:59.20 | Kobaz | I would rather not have to shut down the entire server for 30 seconds? If I can avoid it |
22:00.45 | Kobaz | And so. What I'm going to do, is adjust pjsip to allow reload on local_net... problem solved |
22:02.25 | Samot | Oh yeah, you're faux real time delay |
22:02.40 | Samot | s/you're/your/ |
22:03.28 | *** join/#asterisk sibiria (~sibiria@unaffiliated/sibiria) |
22:03.58 | *** join/#asterisk SSlater (~simon@203.214.65.15) |
22:04.01 | Samot | I forgot you gots some silly amount of delay on your reloads. |
22:05.28 | *** join/#asterisk kerouac[m] (kerouacmat@gateway/shell/matrix.org/x-lgyynhghmufifoyz) |
22:06.36 | Kobaz | Oh, not any more |
22:07.23 | Samot | And a restart takes 30 seconds? |
22:07.29 | Kobaz | well nah |
22:07.39 | Samot | Because I never said "shut down the entire server" |
22:07.40 | Kobaz | i'm over estimating that for sure |
22:07.45 | Samot | I said "restart asterisk" |
22:08.50 | Kobaz | I know |
22:10.31 | Samot | So if I'm following this right, you're going to customize chan_pjsip so that on a reload of the module it will reload the local_net part of the transport objects. |
22:11.11 | Samot | Because perhaps up to 3 times a month you have to add local_net's and can't have a few seconds of downtime for restarting in off hours. |
22:14.14 | Samot | Kobaz: OK, serious question. Do your customers use BLF and pickup, etc? |
23:08.21 | *** join/#asterisk mbecroft (mb@ak2.becroft.co.nz) |
23:11.28 | Kobaz | Samot: yeah |
23:11.43 | Kobaz | Samot: it's just something that bugs me |
23:11.47 | Kobaz | i like flexability |
23:14.20 | Kobaz | Samot: yes to blf and ringing pickup |
23:15.20 | Samot | OK then maybe you want to tackle the RFC4235 support issue of Chan_PJSIP. |
23:15.36 | Samot | It doesn't have full XML body support in the NOTIFY |
23:33.42 | *** join/#asterisk mahlon (~mahlon@martini.nu) |
23:44.22 | Kobaz | ah k cool |
23:46.59 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda00a9088778ef5a949e.dip0.t-ipconnect.de) |
23:50.19 | Kobaz | Samot: see the reason why i'll spend 5-8 hours (or maybe less, who knows) on something like making sure i can reload local_net in pjsip safely... is because I'm a huge fan of being well prepared for anything. And I can see something like that seriously biting me in the ass down the line. Where someone's got 150 calls going on their switch and needs a new local net. I want to be able to handle that situation. And if it makes sense development wise... |
23:50.19 | Kobaz | ie: I don't have to spend like 40 hours on this, then... why not? |
23:50.50 | Samot | OK. |
23:51.10 | Samot | But if someone needs a new local_net and is updating their network, they can plan for when there isn't a 150 calls on the system at once. |
23:51.16 | Kobaz | Sure |
23:51.46 | Kobaz | But sometimes a new vpn pops up on the radar, and it's like hey you need to make this work. I would rather say okay... it's in. And be done with it |
23:52.18 | Kobaz | But then again that's a goood excuse for charging after-hours rates and trigging a planning meeting to get extra billable time, but... I just want things to be easy |
23:52.37 | Samot | Sure. |
23:52.55 | Samot | I don't agree with the method but I can understand the setitment. |
23:53.01 | Samot | I don't agree with the method but I can understand the sentiment. |