IRC log for #asterisk on 20210504

00:02.39*** join/#asterisk simplydrew_ (~simplydre@unaffiliated/simplydrew)
00:56.11Samotmicdud: I don't run power save wifi modes. It impacts calls.
00:56.27Samotmicdud: I don't even use it for wifi hardphones.
00:56.57*** join/#asterisk sinaowolabi (~Sina@102.134.114.1)
00:58.21SamotWifi power save is outside the scope of softphones.
01:09.15micdudhow would you (run or not) power save for wifi on unrooted phone since you do not unroot?
01:11.04micdudit impacts icomming calls , since wifi powrersave on androids  checks in with AP 1 to every 20 seconds
01:11.23SamotI wouldnt
01:11.45SamotThat made causes problems. Plus battery drain isn't an issue
01:12.14SamotMode*
01:13.23micdudit does on some phones (it seems )  but on some older android 4 phones i found  battery drain seems to be ok
01:14.32SamotI really cant speak to your issues. I provide business solutions.
01:15.41SamotMy end users have current phones and pay for working solutions. So I spend the money to make that happen.
01:16.25SamotAnd since it is more business driven, 90% of the phones are iphones.
01:17.25micdudlike kyocera c5170 running android 4.04  can run for 3-4 days with wifi powerave off ( meaning , incomming calls and pings will be instant) while something like samsung s4 s5 will drain battery if rooted and set to same wifi powersave off
01:17.44SamotAgain, I cant speak to that.
01:18.00micdudyou did speak to  samsung s8 9 and 19
01:18.07SamotI don't have users with old phones or ones that root or hack their phones.
01:18.08micdudweeks ago
01:18.16SamotI don't have problems.
01:18.25SamotMy users don't have problems.
01:18.41SamotNo one complains about battery drain
01:19.17micdudi asked you speciicaly , can you call your new nonshitty phones and get an instant response , and you sand yes
01:19.35SamotInstant is subjective
01:19.48micdudinstant to me is sub seccond
01:19.57SamotWithin a couple of seconds sure.
01:20.31micdudcouple  is 1- to 20 ?
01:20.36SamotNo
01:20.43SamotA couple is a couple
01:20.44Samot2
01:21.34micdudso you say you can ping your non shitty phone with screen off and every time get a ping less then 2 sec ? on wifi
01:21.56SamotPing?
01:22.15SamotNow that's getting into networks
01:22.40micdud:) ohh shit that too much for non shitty phone guy
01:22.51SamotNot the topic here
01:24.07micdudthen do no try to help by recommending people buy new phones every year and pay for apps just to make voip calls , please
01:24.26SamotI in no way said that.
01:24.33micdudcheck your logs
01:24.35SamotYou inferred
01:24.48micdud2 weegs . about
01:24.52micdudweeks
01:24.56SamotLook man
01:25.04SamotI don't run power save mode
01:25.18SamotSo if that is what you are doing and having problems. Don't do it.
01:25.25micdudbut you did jump in to my question about it
01:25.35SamotIf the problem goes away. Boom found the issue
01:28.49micdudyou said your new phones past samsung s8 and paid voip clients (softphones) had no problems whatsoever,  and i keep pointing out that incomming calls  have a major delay on android unless rooted and turned to wifi powersave off (which seems to drain battery on newer phones in 12 hrs or so )
01:29.31SamotI have an LG Velvet. I don't have wifi power save on.
01:29.57micdudyou could not , as it does not exist on newer androis peiod ....
01:30.00SamotIt has been off the charger most of the day and is at like 75%
01:30.09SamotIve never used it
01:30.46micdudand if you call you phone  , on airoplane mode with only wifi on , and screen off does it recieve the call instantly ?
01:30.48SamotYou know that some IP phones that do wifi have this feature. Causes the same problem.
01:31.26micdudbut why does it no cause the problem on my old kyocera running android 4
01:31.33SamotSo in this case, power save can cause major delays
01:31.40SamotI don't know
01:32.14micdudbut  your case ? can you call your clients instantly ?
01:32.35SamotSure
01:33.00micdudwhat phone? what os version ? what client ?
01:33.12micdudi will test
01:33.18SamotVariety
01:33.32micdudlist them please
01:33.35SamotNo
01:35.10micdudi want to get to the bottom of using a smartphone as a voip wifi  client , to replace cordless phone with an ata , so please give me your input
01:37.28SamotDo you mean with a softphone app or the native app?
01:37.45micdudspecify the difference please
01:39.23micdudnative app , which i have tried a few times on android , does work , but is very limited and  is hidden on most android phones
01:39.50micdudso i do not even bother with it
01:55.24*** join/#asterisk tsal (~tsal@i59F52966.versanet.de)
02:05.47*** join/#asterisk mr44er (~mr44er@x52716aab.dyn.telefonica.de)
03:48.39*** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br)
06:27.08*** join/#asterisk JAunis (~jean@lputeaux-658-1-51-39.w92-154.abo.wanadoo.fr)
07:07.33*** join/#asterisk JAunis (~jean@lputeaux-658-1-51-39.w92-154.abo.wanadoo.fr)
07:40.01*** join/#asterisk bmg505 (~leon@41.144.137.30)
07:54.59*** join/#asterisk guerby (~guerby@april/board/guerby)
08:15.05*** join/#asterisk sinaowolabi (~Sina@102.134.114.1)
08:19.14*** join/#asterisk sinaowolabi (~Sina@102.134.114.1)
08:23.20*** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt)
10:07.33*** join/#asterisk life_of_e (~life_of_e@108-95-189-245.lightspeed.irvnca.sbcglobal.net)
10:10.37JAunisHi !
10:10.43JAunisI'm trying to send a SIP MESSAGE to a PJSIP endpoint, while specifying a destination number.
10:10.43JAunisWith chan_sip, I used the MessageSend action with a To header in the following format:
10:10.43JAunisAction: MessageSend
10:10.43JAunisTo: sip:12345@thepeer
10:10.43JAunis"thepeer" being my SIP endpoint and "12345" the destination number.
10:10.43JAunisWhen using the same method for PJSIP, id doesn't work. PJSIP uses "12345" instead of "thepeer" as the endpoint name.
10:10.43JAunisThen I tried the following format : "pjsip:thepeer/sip:12345@thepeer". Did not work either: "thepeer" is used as an FQDN instead of "just" a peer name.
10:10.57JAunisIs there a way to do this with PJSIP ?
10:15.30*** join/#asterisk puzzola (~puzzola@unaffiliated/puzzola)
10:16.43*** join/#asterisk sibiria (~sibiria@unaffiliated/sibiria)
10:23.18*** join/#asterisk rpifan (~rpifan@p200300d2672b5d002a3b45b75f5498c9.dip0.t-ipconnect.de)
10:36.12*** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net)
10:44.18*** join/#asterisk orn (~orn@2a01:6f00:2:a517:cceb:bc6a:4460:3ace)
10:47.50*** join/#asterisk HannaM (~quassel@p54849510.dip0.t-ipconnect.de)
11:14.51Samothttps://community.asterisk.org/t/messagesend-to-all-pjsip-contacts/75485
11:17.52*** join/#asterisk sibiria (~sibiria@unaffiliated/sibiria)
11:23.22*** join/#asterisk ghoti (~paul@dynamic-64-118-28-81.wtccommunications.ca)
11:25.08JAunisThanks for the hint. So it implies retrieving the URI of the endpoint. That's something I would prefer avoiding: it gets quite complicated when working with ARI and AMI.
11:26.28SamotWell if they have just one contact, pjsip:<endpoint> works just fine too
11:28.16JAunisBut it does not allow specifying the destination number.
11:32.21SamotUhm.
11:32.22SamotWhat?
11:33.12SamotIf you send a message to pjsip:1000 it will use the AOR for that endpoint and send the message to the first contact in the list for the AOR.
11:35.24filehttps://issues.asterisk.org/jira/browse/ASTERISK-28513 https://issues.asterisk.org/jira/browse/ASTERISK-29404
11:35.54filethere's issues open for stuff in that area, and reviews up
11:42.53*** join/#asterisk sinaowolabi (~Sina@102.134.114.1)
12:02.42JAunisI saw these issues, I'm not sure the ongoing review will fix my problem. In my use case I have a kind of SIP trunk with several users to whom I will send messages through this trunk.
12:02.52*** join/#asterisk LiuYan (~NiHola@unaffiliated/liuyan)
12:03.14SamotAnd another Asterisk box on the other side?
12:04.53JAunisNo it's a SIP provider
12:05.12filehttps://gerrit.asterisk.org/c/asterisk/+/15828/2/res/res_pjsip_messaging.c makes it sound as though it would work?
12:07.01*** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt)
12:08.05SamotJAunis: they accept SIP MESSAGE?
12:09.56JAunisSamot: yes they do
12:11.25JAunisfile: looks like I will have to specify a complete URI including the endpoint's hostname.
12:12.45JAuniswhich implies looping through PJSIP_DIAL_CONTACTS... not so diffcult with dialplan but it becomes more difficult with AMI/ARI
12:13.21SamotYou just need pjsip:PJSIP/endpoint/sip:${EXTEN}@sipuri
12:14.05SamotIt is not like the trunk has multiple contacts
12:20.00JAunisIndeed. But the contact may change over time. So for each message I have to execute "PJSIPShowEndpoint" and retrieve the contact.Since I will have to send large amounts of messages this will be a lot of overhead.
12:20.28SamotHow can the contact change over time? It's a SIP trunk.
12:20.57JAunisNot so simple. There are backups.
12:21.19SamotThen you're going to have to check the message status and try again.
12:21.40SamotBut then again, it actually can't tell you if it was delivered or not. Just that it sent properly.
12:21.50SamotNo validation that the other side actually got it.
12:22.12JAunisIndeed
12:22.42SamotPlus if this was something with backup, wouldn't they be using SRV records?
12:23.06JAunisI will probably stick to chan_sip, it makes things easier with messaging
12:23.15SamotI mean sure.
12:23.33SamotIt's dead. Not supported and going to be removed in the next few releases.
12:24.01*** join/#asterisk rpifan (~rpifan@p200300d2672b5d000eca5315f0c25a76.dip0.t-ipconnect.de)
12:24.06SamotDon't they have an HTTP API?
12:25.37SamotThey do offer a RESTful API for SMS/MMS, right?
12:26.18JAunisThat's why I'm experimenting with PJSIP. I really would prefer using PJSIP but for the moment it still lacks some features.
12:26.53SamotSo is that a no?
12:26.58SamotDoesn't really answer the question.
12:27.01JAunisNo it is purely based on SIP
12:27.26SamotSo they are doing it the hard way.
12:28.31gtjosephJAunis Samot  If I'm reading the chat history correctly, I think the current reviews up in Gerrit will do what you want.  A third parameter was added to MessageSend to allow you to specify how to construct the request uri and specify the from and to headers separately
12:28.47SamotI don't want anything.
12:28.55SamotI was just providing options to a question.
12:29.09gtjosephMessageSend(pjsip:PJSIP/endpoint, fromuri, touri)
12:29.41gtjosephSamot: yeah I know and thanks.  You were both involved in the conversation though. :)
12:29.42SamotYes but that still leaves us with the PJSIP contact problem.
12:29.43*** join/#asterisk sinaowolabi (~Sina@105.112.25.68)
12:29.55gtjosephyes and no
12:29.57Samotpjsip:PJSIP/endpoint will take the first contact.
12:30.08SamotIf there are 5 contacts, it will not take them.
12:30.33SamotIf the contact is a static contact like sip:sip.domain.com:5060
12:30.40SamotIt doesn't add the user portition.
12:31.11SamotSo we're right back to where we were before, the building of the RURI's for custom/multiple contacts.
12:31.22gtjosephyeah true, so JAunis wants to fork the message?
12:31.42SamotIt's something being delivered to the provider.
12:31.53SamotSo the user can be random and change like a normal outbound call.
12:32.07JAunisgtjospeh: No, I just would like to send it the same way chan_sip did
12:32.09gtjosephI understand.  I also use a provider that accespts SMS via SIP MESSAGE.
12:32.22JAunissomething like MessageSend(sip:1000@mypeer)
12:32.33SamotYou can do that
12:32.37SamotThe format is just different.
12:32.41SamotI gave you the format.
12:33.20gtjoseph1000@mypeer becomes the request uiri or the to header?
12:33.40SamotWhich chan_SIP, both.
12:33.45SamotWith.
12:34.00SamotI believe.
12:34.02JAuniswith chan_sip "1000@mypeer" would translate to "sip:1000@12.0.0.1" for instance
12:34.11JAunisif the peer registered with 12.0.0.1
12:34.26SamotYes and Chan_SIP only has the concept of a single contact per AOR
12:34.45SamotChan_PJSIP acts like a normal SIP stack allowing multiple contacts per AOR
12:36.46gtjosephJAunis: Post in the asterisk-dev list.   It's easier to document and easier for me to give examples.
12:37.33JAunisAll right
12:42.10SamotSo the proper format I gave earlier to solve this wasn't the right answer?
12:43.21JAunisWith this format you hace to provide the domain name. Unless I misunderstood something.
12:43.22gtjosephIt may have been but I just woke up and am having trouble following. :)
12:44.27SamotJAunis: I didn't say a domain.
12:44.39SamotJAunis: You need to format a proper SIP URI.
12:44.57SamotSince you already have that details for your trunk, how is this hard?
12:45.43SamotIf provider IP is 1.1.1.1 then this is pjsip:PJSIP/endpoint/sip:${EXTEN}@1.1.1.1:5060
12:45.56gtjosephhttps://pastebin.com/RxaPiNsY has all the combinations of destinations that will be supported with the commits currently up on gerrit
12:46.23SamotOh look don't even need the PJSIP part.
12:46.56Samotpjsip:pstn-trunk/sip:${EXTEN}@12.0.0.1:5060
12:48.10JAunisBecause the contact may change over time. So 1.1.1.1 may be a good guess for one time but may become invalid mater.
12:48.25SamotOK and? Change it.
12:48.43SamotHow would you address this in chan_SIP?
12:48.50filethis conversation is in a circular loop
12:48.54SamotIt is.
12:49.01SamotThe solution was presented. It will work.
12:49.26SamotAnd since Chan_SIP would require multiple Chan_SIP peers for multiple IPs...this is pointless.
12:49.42SamotBecause it would also mean the peer would have to be changed regularly for this "failover"
12:50.59gtjosephJust fyi...  this is the dialplan context I used for testing... https://pastebin.com/r65Vm3YY
12:51.44filegtjoseph: do we allow the request user to be specified, without specifying an IP or domain?
12:52.33gtjosephjust the user portion of the request uri?  and get the rest of the uri from the first contact on the endpoint?
12:52.38fileyes
12:52.41filejust like dialing
12:52.47JAunisyes that's what I'm looking for
12:54.01gtjosephno but we could easily.  the problem is that we allow so many format combinations that we can't reliably tell that this is a user and not an aor name.
12:54.14gtjosephlet me see if i can come up with something.
12:54.46gtjosephJAunis: your provider routes the message based on request uri and not the to header?
12:56.33JAunisyes based on the request uri
12:56.49gtjosephok, let me see what I can do.
13:01.00*** join/#asterisk lbazan (~LoKoMurdo@fedora/LoKoMurdoK)
13:09.39*** join/#asterisk sinaowolabi (~Sina@105.112.25.68)
13:31.48*** join/#asterisk Enitin (enitin@gateway/vpn/privateinternetaccess/enitin)
13:32.12*** join/#asterisk orn (~orn@nova-078-040-250-100.corp.novanet.is)
13:32.22*** join/#asterisk x5eb (~seb@seb-hpws2.w1.tele.crt1.net)
13:33.00*** join/#asterisk _0x5eb_- (~seb@69.63.121.78.rev.sfr.net)
13:37.31*** join/#asterisk x5eb (~seb@69.63.121.78.rev.sfr.net)
13:38.34*** join/#asterisk orn (~orn@2a01:6f00:2:a51d:468a:5bff:fea5:bf9d)
13:40.34*** join/#asterisk sinaowolabi (~Sina@105.112.25.68)
13:42.49*** join/#asterisk waldo323 (~waldo323@d149-67-45-83.clv.wideopenwest.com)
13:55.31gtjosephJAunis: how about if we just make MessageSend take a return from PJSIP_DIAL_CONTACTS(endpoint,1000)?
13:56.02gtjosephIf more than 1 dial string is returned, youcould use CUT to senect th eone you want, otherwise, MessageSend would use the first one.
14:00.08JAunisgtjoseph: from the dialplan, it would be a good solution. But what about sending messages from AMI / ARI ?
14:01.10*** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net)
14:01.21gtjosephYou could construct a similar string... PJSIP/1000@endpoint/sip:10.10.10.10:5060
14:01.21JAunisIt would mean retrieving the contact information with an AMI request... or maybe there is another way with ARI
14:02.37gtjosephwell, we could just ignore the host:port part of the input uri and grab the current first contact from the endpoint's aor
14:03.06*** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-qakmnfiqgpwqjvnq)
14:03.06*** mode/#asterisk [+o kharwell] by ChanServ
14:07.08gtjosephWe _could_ also allow the format user@endpoint but it would require a test to see if user is really a user and not an endpoint itself.
14:07.12SamotBut pjsip:<endpoint> does that.
14:07.22SamotGrabs the first contact in the aor.
14:07.36gtjosephyeah but doesn't allow the specification of user
14:08.01gtjosephunless the user happend to be specified in the contact uri on the aor.
14:08.12SamotYes, I understand that.
14:08.41gtjosephok so ho would you use  pjsip:<endpoint> then?
14:08.46SamotThe problem so far is that if you do pjsip:user@endpoint it parses it as user@host
14:09.30SamotI don't have multiple contacts to AORs for PJSIP because I have Kamailio.
14:09.33gtjosephi know that's why we'd have to test both before and after the @s
14:10.00SamotSo all my PJSIP AORs have a single, static contact that routes to the user@domain on Kamailio.
14:10.01gtjosephMessageSend already does that so its fairly easy.
14:11.20gtjosephyeah that's why we added the ability to specify the To: header.  The requestURI sets the destination and To sets the ultimate recipient.
14:11.51SamotWell for me the RURI is the ultimate recipient.
14:11.54gtjosephThat's exactly how To is defined...  the ultimate recipient.
14:12.27gtjosephok so iun your case of user@domain...   what's the "user" part?
14:12.36SamotThe actual user.
14:12.43Samot100@domain.com
14:12.54SamotThe endpoint is academic.
14:13.09SamotThe AOR points to sip:100@sip.domain.com:5060
14:13.26SamotWhen it hits Kamailio, Kamailio loads all the contacts registered for 100@sip.domain.com
14:13.34SamotAnd the sends the message to all of them.
14:13.43gtjosephright.  so how do you send to 101@sip.domain.com?
14:13.53SamotI send to the endpoint for 101
14:14.31gtjosephhow do you specify a number to call?
14:14.46SamotWhat do you mean? I don't do SMS over SIP MESSAGE.
14:14.59SamotI send SIP MESSAGEs over SIP MESSAGE to internal endpoints for alerts.
14:15.10SamotMy users have a GUI for SMS/MMS because I do MMS.
14:15.22SamotAnd I also can do multiple recipients for group messages.
14:15.38SamotSo doing this over SIP MESSAGE is pointless as a SMS/MMS solution for my end users.
14:15.46SamotIt lacks a lot of features and abilities.
14:15.52gtjosephright but in JAunis's case he has to send to <telnumber>@sip.domain.com
14:16.05SamotI gave my answer.
14:16.20Samotpjsip:endpoint/${EXTEN}@provider
14:16.37Samotpjsip:endpoint/${EXTEN}@12.0.0.1:5060 more specifically
14:17.31SamotAnd since messagesend actually just tells you if the transport/protocol being used was a success or not...
14:17.47SamotIt doesn't actually inform you if the message was received by the far end or not. Let alone delivered.
14:18.35gtjosephiot can't really since that's all done asynchronously.
14:18.56SamotYes but if my RESTful call timesout, I know.
14:19.03SamotThen I can use a backup, if offered.
14:19.14*** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-tyuxgzlnexpyiwsn)
14:19.14*** mode/#asterisk [+o bford] by ChanServ
14:19.19SamotAnd I also get delivery notifications.
14:20.17JAunisgtjoseph: isn't it possible to "just" apply the same parsing logic as PJSIP dialstrings ?
14:20.43gtjosephholding up any call for a reponse from a remote UAS is very dangerous.  Now if we sent an event on the reponse from the server that would work.
14:20.53gtjosephJAunis: yes, that's what I'm proposing.
14:21.04SamotI'm not sure what you mean by holding up a call
14:21.28gtjosephyou could either use the output from PJSIP_DIAL_CONTACTS from the dialplan or construct your own string in the same format for the APOOI calls.
14:21.39*** join/#asterisk sibiria (~sibiria@unaffiliated/sibiria)
14:22.17JAunissounds like a good solution
14:22.25Samot.....
14:22.27seanbrightmessagesend waiting around for a response is "holding up a call"
14:22.31gtjosephSamot: we can't have MessageSend or the API calls block until there's a response from the server.
14:22.35seanbrightit currently just fires and forgets
14:22.48SamotRight, I know that. But it would be holding up a channel not a call.
14:23.03seanbrightsix of one...
14:23.06gtjosephsorry.  i meant "call" in terms of a function call.
14:23.46SamotOK I was just pointing out how I prefer a RESFful solution for SMS/MMS to/from the PSTN.
14:24.01SamotBecause messagesend lacks functions and features.
14:24.12SamotIt's great for things like sending room details for hotels on 911 calls.
14:24.28SamotUse the hell of it for that. Or other alerts they want on the front desk phones.
14:26.04seanbrightyeah, REST is nice
14:26.09SamotAnd I just want to be clear here. I said to construct a string using the endpoint/uri for this and I was given reasons as to why it wouldn't be a viable solution.
14:26.24SamotNow, 20 minutes later it is suggested by someone else and the response is "good solution"
14:28.31gtjosephIf by solution you still mean pjsip:endpoint/exten@domain, it doesn't work because JAunis doesn't always know what the "domain" is.
14:28.48SamotHow can he NOt?
14:28.54SamotHe's sending calls to the provider.
14:29.02SamotIn SIP the domain is the part after @
14:29.08SamotIt could be an IP or a FQDN
14:29.26SamotI even updated with an example IP.
14:29.41SamotSo I'm being told right now, the destination IP/domain of the provider is unknown.
14:29.55seanbrightmaybe it is unknown in dialplan?
14:30.03gtjosephthis is why i wanted to move this discussion to the asterisk-dev mailing list.
14:30.07SamotHe's saying he wants to do this ARI/AMI
14:30.09SamotSo...
14:30.15SamotConstruct it properly.
14:31.49gtjosephhe'd have to retrieve the endpoint, then retrieve the aor(s) from named on the endpoint, then retrieve the contact from the aor.
14:31.56SamotStop.
14:32.01SamotPlease stop.
14:32.11SamotLet's try this for a calm, logical point of view.
14:32.21SamotI have a provider. I need to accept/send calls from them.
14:32.24SamotHow would I do that?
14:32.33SamotOh they would give me FQDNs or IPs to use.
14:33.04SamotSo my PJSIP endpoint used as a trunk for said provider would have an AOR with a static contact.
14:33.22Samotsip:sip.domain.com:5060
14:33.31Samotor sip:12.0.0.10:5060
14:34.31SamotSo I already have these details. So what is stopping me from saying pjsip:pstn-trunk/sip:${EXTEN}@12.0.0.10:5060
14:35.06SamotThis isn't some rando user REGISTERing to Asterisk you need to dig their dynamic contact up for.
14:36.38gtjosephI can't answer your question because only JAunis knows what his specific scenario is.  I'd like him to describe the issue in full on the asterisk-dev mailing list and we can find a proper solution for him.
14:37.14SamotThere already are proper solutions.
14:38.36fileSamot: just stop.
14:38.49SamotSure.
14:39.04filelet gtjoseph work this out as he needs, he's spent an absurd amount of time in this area lately
14:39.22SamotI'm not against the idea of being able to make it work like Dial()
14:39.43filecease.
14:44.07JAunisi'm gonna post on asterisk-dev. Thanks everybody for your time.
14:52.35*** join/#asterisk dupondje (~dupondje@artemis.dupie.be)
15:09.43*** join/#asterisk sinaowolabi (~Sina@105.112.25.68)
15:19.04*** join/#asterisk sinaowolabi (~Sina@105.112.25.68)
15:40.14*** join/#asterisk rpifan (~rpifan@p200300d2672b5d00b0071e362c0a8cec.dip0.t-ipconnect.de)
16:02.29*** join/#asterisk waldo323_ (~waldo323@d149-67-45-83.clv.wideopenwest.com)
16:44.07kerouac[m]When I add speakerphone to confbridge with Originate, enter conference and then leave, what is the best way to destroy conference with the only speakerphone? If it exists, I can't invite speakerphone into new conferences
17:07.26*** join/#asterisk rpifan (~rpifan@p200300d2672b5d00863ac4fc95bc9fc6.dip0.t-ipconnect.de)
17:38.17ornkerouac[m]: Could you clarify a bit? Do you mean if everyone has left the conference except for the speakerphone? Then you want the speakerphone to hang up?
17:38.37*** join/#asterisk sinaowolabi (~Sina@102.134.114.1)
17:43.40kerouac[m]orn: I want to destroy conference if I hang up from it, even if there are speakerphone in it. Or I want to destroy conference if I call speakerphone that is alone in session.
17:48.37*** join/#asterisk mmlj4 (~mmlj4@ip68-230-228-233.no.no.cox.net)
18:02.55*** join/#asterisk hardwire (sid415742@gateway/web/irccloud.com/x-txndyixtnfirhuhg)
18:27.44*** join/#asterisk sinaowolabi (~Sina@105.112.150.66)
18:49.06*** join/#asterisk mmlj4 (~mmlj4@ip68-230-228-233.no.no.cox.net)
18:51.57*** join/#asterisk yuljk (~yuljk@86.11.178.103)
19:31.47*** join/#asterisk rpifan (~rpifan@p200300d2672b5d00b0600f4e787ab8bf.dip0.t-ipconnect.de)
20:20.35*** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br)
20:39.30*** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt)
20:45.00*** join/#asterisk akp55_ (~akp55@c-73-148-15-31.hsd1.va.comcast.net)
21:24.59*** join/#asterisk simplydrew_ (~simplydre@unaffiliated/simplydrew)
21:41.44*** join/#asterisk Kobaz (~kobaz@its.kobaz.net)
22:03.41*** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at)
22:15.02*** join/#asterisk yuljk (~yuljk@86.11.178.103)
23:06.33*** join/#asterisk simplydrew_ (~simplydre@unaffiliated/simplydrew)
23:31.08*** join/#asterisk yuljk (~yuljk@unaffiliated/yuljk)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.