00:02.39 | *** join/#asterisk simplydrew_ (~simplydre@unaffiliated/simplydrew) |
00:56.11 | Samot | micdud: I don't run power save wifi modes. It impacts calls. |
00:56.27 | Samot | micdud: I don't even use it for wifi hardphones. |
00:56.57 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
00:58.21 | Samot | Wifi power save is outside the scope of softphones. |
01:09.15 | micdud | how would you (run or not) power save for wifi on unrooted phone since you do not unroot? |
01:11.04 | micdud | it impacts icomming calls , since wifi powrersave on androids checks in with AP 1 to every 20 seconds |
01:11.23 | Samot | I wouldnt |
01:11.45 | Samot | That made causes problems. Plus battery drain isn't an issue |
01:12.14 | Samot | Mode* |
01:13.23 | micdud | it does on some phones (it seems ) but on some older android 4 phones i found battery drain seems to be ok |
01:14.32 | Samot | I really cant speak to your issues. I provide business solutions. |
01:15.41 | Samot | My end users have current phones and pay for working solutions. So I spend the money to make that happen. |
01:16.25 | Samot | And since it is more business driven, 90% of the phones are iphones. |
01:17.25 | micdud | like 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.44 | Samot | Again, I cant speak to that. |
01:18.00 | micdud | you did speak to samsung s8 9 and 19 |
01:18.07 | Samot | I don't have users with old phones or ones that root or hack their phones. |
01:18.08 | micdud | weeks ago |
01:18.16 | Samot | I don't have problems. |
01:18.25 | Samot | My users don't have problems. |
01:18.41 | Samot | No one complains about battery drain |
01:19.17 | micdud | i asked you speciicaly , can you call your new nonshitty phones and get an instant response , and you sand yes |
01:19.35 | Samot | Instant is subjective |
01:19.48 | micdud | instant to me is sub seccond |
01:19.57 | Samot | Within a couple of seconds sure. |
01:20.31 | micdud | couple is 1- to 20 ? |
01:20.36 | Samot | No |
01:20.43 | Samot | A couple is a couple |
01:20.44 | Samot | 2 |
01:21.34 | micdud | so 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.56 | Samot | Ping? |
01:22.15 | Samot | Now that's getting into networks |
01:22.40 | micdud | :) ohh shit that too much for non shitty phone guy |
01:22.51 | Samot | Not the topic here |
01:24.07 | micdud | then 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.26 | Samot | I in no way said that. |
01:24.33 | micdud | check your logs |
01:24.35 | Samot | You inferred |
01:24.48 | micdud | 2 weegs . about |
01:24.52 | micdud | weeks |
01:24.56 | Samot | Look man |
01:25.04 | Samot | I don't run power save mode |
01:25.18 | Samot | So if that is what you are doing and having problems. Don't do it. |
01:25.25 | micdud | but you did jump in to my question about it |
01:25.35 | Samot | If the problem goes away. Boom found the issue |
01:28.49 | micdud | you 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.31 | Samot | I have an LG Velvet. I don't have wifi power save on. |
01:29.57 | micdud | you could not , as it does not exist on newer androis peiod .... |
01:30.00 | Samot | It has been off the charger most of the day and is at like 75% |
01:30.09 | Samot | Ive never used it |
01:30.46 | micdud | and if you call you phone , on airoplane mode with only wifi on , and screen off does it recieve the call instantly ? |
01:30.48 | Samot | You know that some IP phones that do wifi have this feature. Causes the same problem. |
01:31.26 | micdud | but why does it no cause the problem on my old kyocera running android 4 |
01:31.33 | Samot | So in this case, power save can cause major delays |
01:31.40 | Samot | I don't know |
01:32.14 | micdud | but your case ? can you call your clients instantly ? |
01:32.35 | Samot | Sure |
01:33.00 | micdud | what phone? what os version ? what client ? |
01:33.12 | micdud | i will test |
01:33.18 | Samot | Variety |
01:33.32 | micdud | list them please |
01:33.35 | Samot | No |
01:35.10 | micdud | i 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.28 | Samot | Do you mean with a softphone app or the native app? |
01:37.45 | micdud | specify the difference please |
01:39.23 | micdud | native 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.50 | micdud | so 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.37 | JAunis | Hi ! |
10:10.43 | JAunis | I'm trying to send a SIP MESSAGE to a PJSIP endpoint, while specifying a destination number. |
10:10.43 | JAunis | With chan_sip, I used the MessageSend action with a To header in the following format: |
10:10.43 | JAunis | Action: MessageSend |
10:10.43 | JAunis | To: sip:12345@thepeer |
10:10.43 | JAunis | "thepeer" being my SIP endpoint and "12345" the destination number. |
10:10.43 | JAunis | When using the same method for PJSIP, id doesn't work. PJSIP uses "12345" instead of "thepeer" as the endpoint name. |
10:10.43 | JAunis | Then 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.57 | JAunis | Is 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.51 | Samot | https://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.08 | JAunis | Thanks 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.28 | Samot | Well if they have just one contact, pjsip:<endpoint> works just fine too |
11:28.16 | JAunis | But it does not allow specifying the destination number. |
11:32.21 | Samot | Uhm. |
11:32.22 | Samot | What? |
11:33.12 | Samot | If 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.24 | file | https://issues.asterisk.org/jira/browse/ASTERISK-28513 https://issues.asterisk.org/jira/browse/ASTERISK-29404 |
11:35.54 | file | there's issues open for stuff in that area, and reviews up |
11:42.53 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
12:02.42 | JAunis | I 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.14 | Samot | And another Asterisk box on the other side? |
12:04.53 | JAunis | No it's a SIP provider |
12:05.12 | file | https://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.05 | Samot | JAunis: they accept SIP MESSAGE? |
12:09.56 | JAunis | Samot: yes they do |
12:11.25 | JAunis | file: looks like I will have to specify a complete URI including the endpoint's hostname. |
12:12.45 | JAunis | which implies looping through PJSIP_DIAL_CONTACTS... not so diffcult with dialplan but it becomes more difficult with AMI/ARI |
12:13.21 | Samot | You just need pjsip:PJSIP/endpoint/sip:${EXTEN}@sipuri |
12:14.05 | Samot | It is not like the trunk has multiple contacts |
12:20.00 | JAunis | Indeed. 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.28 | Samot | How can the contact change over time? It's a SIP trunk. |
12:20.57 | JAunis | Not so simple. There are backups. |
12:21.19 | Samot | Then you're going to have to check the message status and try again. |
12:21.40 | Samot | But then again, it actually can't tell you if it was delivered or not. Just that it sent properly. |
12:21.50 | Samot | No validation that the other side actually got it. |
12:22.12 | JAunis | Indeed |
12:22.42 | Samot | Plus if this was something with backup, wouldn't they be using SRV records? |
12:23.06 | JAunis | I will probably stick to chan_sip, it makes things easier with messaging |
12:23.15 | Samot | I mean sure. |
12:23.33 | Samot | It'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.06 | Samot | Don't they have an HTTP API? |
12:25.37 | Samot | They do offer a RESTful API for SMS/MMS, right? |
12:26.18 | JAunis | That's why I'm experimenting with PJSIP. I really would prefer using PJSIP but for the moment it still lacks some features. |
12:26.53 | Samot | So is that a no? |
12:26.58 | Samot | Doesn't really answer the question. |
12:27.01 | JAunis | No it is purely based on SIP |
12:27.26 | Samot | So they are doing it the hard way. |
12:28.31 | gtjoseph | JAunis 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.47 | Samot | I don't want anything. |
12:28.55 | Samot | I was just providing options to a question. |
12:29.09 | gtjoseph | MessageSend(pjsip:PJSIP/endpoint, fromuri, touri) |
12:29.41 | gtjoseph | Samot: yeah I know and thanks. You were both involved in the conversation though. :) |
12:29.42 | Samot | Yes but that still leaves us with the PJSIP contact problem. |
12:29.43 | *** join/#asterisk sinaowolabi (~Sina@105.112.25.68) |
12:29.55 | gtjoseph | yes and no |
12:29.57 | Samot | pjsip:PJSIP/endpoint will take the first contact. |
12:30.08 | Samot | If there are 5 contacts, it will not take them. |
12:30.33 | Samot | If the contact is a static contact like sip:sip.domain.com:5060 |
12:30.40 | Samot | It doesn't add the user portition. |
12:31.11 | Samot | So we're right back to where we were before, the building of the RURI's for custom/multiple contacts. |
12:31.22 | gtjoseph | yeah true, so JAunis wants to fork the message? |
12:31.42 | Samot | It's something being delivered to the provider. |
12:31.53 | Samot | So the user can be random and change like a normal outbound call. |
12:32.07 | JAunis | gtjospeh: No, I just would like to send it the same way chan_sip did |
12:32.09 | gtjoseph | I understand. I also use a provider that accespts SMS via SIP MESSAGE. |
12:32.22 | JAunis | something like MessageSend(sip:1000@mypeer) |
12:32.33 | Samot | You can do that |
12:32.37 | Samot | The format is just different. |
12:32.41 | Samot | I gave you the format. |
12:33.20 | gtjoseph | 1000@mypeer becomes the request uiri or the to header? |
12:33.40 | Samot | Which chan_SIP, both. |
12:33.45 | Samot | With. |
12:34.00 | Samot | I believe. |
12:34.02 | JAunis | with chan_sip "1000@mypeer" would translate to "sip:1000@12.0.0.1" for instance |
12:34.11 | JAunis | if the peer registered with 12.0.0.1 |
12:34.26 | Samot | Yes and Chan_SIP only has the concept of a single contact per AOR |
12:34.45 | Samot | Chan_PJSIP acts like a normal SIP stack allowing multiple contacts per AOR |
12:36.46 | gtjoseph | JAunis: Post in the asterisk-dev list. It's easier to document and easier for me to give examples. |
12:37.33 | JAunis | All right |
12:42.10 | Samot | So the proper format I gave earlier to solve this wasn't the right answer? |
12:43.21 | JAunis | With this format you hace to provide the domain name. Unless I misunderstood something. |
12:43.22 | gtjoseph | It may have been but I just woke up and am having trouble following. :) |
12:44.27 | Samot | JAunis: I didn't say a domain. |
12:44.39 | Samot | JAunis: You need to format a proper SIP URI. |
12:44.57 | Samot | Since you already have that details for your trunk, how is this hard? |
12:45.43 | Samot | If provider IP is 1.1.1.1 then this is pjsip:PJSIP/endpoint/sip:${EXTEN}@1.1.1.1:5060 |
12:45.56 | gtjoseph | https://pastebin.com/RxaPiNsY has all the combinations of destinations that will be supported with the commits currently up on gerrit |
12:46.23 | Samot | Oh look don't even need the PJSIP part. |
12:46.56 | Samot | pjsip:pstn-trunk/sip:${EXTEN}@12.0.0.1:5060 |
12:48.10 | JAunis | Because 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.25 | Samot | OK and? Change it. |
12:48.43 | Samot | How would you address this in chan_SIP? |
12:48.50 | file | this conversation is in a circular loop |
12:48.54 | Samot | It is. |
12:49.01 | Samot | The solution was presented. It will work. |
12:49.26 | Samot | And since Chan_SIP would require multiple Chan_SIP peers for multiple IPs...this is pointless. |
12:49.42 | Samot | Because it would also mean the peer would have to be changed regularly for this "failover" |
12:50.59 | gtjoseph | Just fyi... this is the dialplan context I used for testing... https://pastebin.com/r65Vm3YY |
12:51.44 | file | gtjoseph: do we allow the request user to be specified, without specifying an IP or domain? |
12:52.33 | gtjoseph | just the user portion of the request uri? and get the rest of the uri from the first contact on the endpoint? |
12:52.38 | file | yes |
12:52.41 | file | just like dialing |
12:52.47 | JAunis | yes that's what I'm looking for |
12:54.01 | gtjoseph | no 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.14 | gtjoseph | let me see if i can come up with something. |
12:54.46 | gtjoseph | JAunis: your provider routes the message based on request uri and not the to header? |
12:56.33 | JAunis | yes based on the request uri |
12:56.49 | gtjoseph | ok, 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.31 | gtjoseph | JAunis: how about if we just make MessageSend take a return from PJSIP_DIAL_CONTACTS(endpoint,1000)? |
13:56.02 | gtjoseph | If 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.08 | JAunis | gtjoseph: 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.21 | gtjoseph | You could construct a similar string... PJSIP/1000@endpoint/sip:10.10.10.10:5060 |
14:01.21 | JAunis | It would mean retrieving the contact information with an AMI request... or maybe there is another way with ARI |
14:02.37 | gtjoseph | well, 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.08 | gtjoseph | We _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.12 | Samot | But pjsip:<endpoint> does that. |
14:07.22 | Samot | Grabs the first contact in the aor. |
14:07.36 | gtjoseph | yeah but doesn't allow the specification of user |
14:08.01 | gtjoseph | unless the user happend to be specified in the contact uri on the aor. |
14:08.12 | Samot | Yes, I understand that. |
14:08.41 | gtjoseph | ok so ho would you use pjsip:<endpoint> then? |
14:08.46 | Samot | The problem so far is that if you do pjsip:user@endpoint it parses it as user@host |
14:09.30 | Samot | I don't have multiple contacts to AORs for PJSIP because I have Kamailio. |
14:09.33 | gtjoseph | i know that's why we'd have to test both before and after the @s |
14:10.00 | Samot | So all my PJSIP AORs have a single, static contact that routes to the user@domain on Kamailio. |
14:10.01 | gtjoseph | MessageSend already does that so its fairly easy. |
14:11.20 | gtjoseph | yeah 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.51 | Samot | Well for me the RURI is the ultimate recipient. |
14:11.54 | gtjoseph | That's exactly how To is defined... the ultimate recipient. |
14:12.27 | gtjoseph | ok so iun your case of user@domain... what's the "user" part? |
14:12.36 | Samot | The actual user. |
14:12.43 | Samot | 100@domain.com |
14:12.54 | Samot | The endpoint is academic. |
14:13.09 | Samot | The AOR points to sip:100@sip.domain.com:5060 |
14:13.26 | Samot | When it hits Kamailio, Kamailio loads all the contacts registered for 100@sip.domain.com |
14:13.34 | Samot | And the sends the message to all of them. |
14:13.43 | gtjoseph | right. so how do you send to 101@sip.domain.com? |
14:13.53 | Samot | I send to the endpoint for 101 |
14:14.31 | gtjoseph | how do you specify a number to call? |
14:14.46 | Samot | What do you mean? I don't do SMS over SIP MESSAGE. |
14:14.59 | Samot | I send SIP MESSAGEs over SIP MESSAGE to internal endpoints for alerts. |
14:15.10 | Samot | My users have a GUI for SMS/MMS because I do MMS. |
14:15.22 | Samot | And I also can do multiple recipients for group messages. |
14:15.38 | Samot | So doing this over SIP MESSAGE is pointless as a SMS/MMS solution for my end users. |
14:15.46 | Samot | It lacks a lot of features and abilities. |
14:15.52 | gtjoseph | right but in JAunis's case he has to send to <telnumber>@sip.domain.com |
14:16.05 | Samot | I gave my answer. |
14:16.20 | Samot | pjsip:endpoint/${EXTEN}@provider |
14:16.37 | Samot | pjsip:endpoint/${EXTEN}@12.0.0.1:5060 more specifically |
14:17.31 | Samot | And since messagesend actually just tells you if the transport/protocol being used was a success or not... |
14:17.47 | Samot | It doesn't actually inform you if the message was received by the far end or not. Let alone delivered. |
14:18.35 | gtjoseph | iot can't really since that's all done asynchronously. |
14:18.56 | Samot | Yes but if my RESTful call timesout, I know. |
14:19.03 | Samot | Then 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.19 | Samot | And I also get delivery notifications. |
14:20.17 | JAunis | gtjoseph: isn't it possible to "just" apply the same parsing logic as PJSIP dialstrings ? |
14:20.43 | gtjoseph | holding 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.53 | gtjoseph | JAunis: yes, that's what I'm proposing. |
14:21.04 | Samot | I'm not sure what you mean by holding up a call |
14:21.28 | gtjoseph | you 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.17 | JAunis | sounds like a good solution |
14:22.25 | Samot | ..... |
14:22.27 | seanbright | messagesend waiting around for a response is "holding up a call" |
14:22.31 | gtjoseph | Samot: we can't have MessageSend or the API calls block until there's a response from the server. |
14:22.35 | seanbright | it currently just fires and forgets |
14:22.48 | Samot | Right, I know that. But it would be holding up a channel not a call. |
14:23.03 | seanbright | six of one... |
14:23.06 | gtjoseph | sorry. i meant "call" in terms of a function call. |
14:23.46 | Samot | OK I was just pointing out how I prefer a RESFful solution for SMS/MMS to/from the PSTN. |
14:24.01 | Samot | Because messagesend lacks functions and features. |
14:24.12 | Samot | It's great for things like sending room details for hotels on 911 calls. |
14:24.28 | Samot | Use the hell of it for that. Or other alerts they want on the front desk phones. |
14:26.04 | seanbright | yeah, REST is nice |
14:26.09 | Samot | And 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.24 | Samot | Now, 20 minutes later it is suggested by someone else and the response is "good solution" |
14:28.31 | gtjoseph | If 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.48 | Samot | How can he NOt? |
14:28.54 | Samot | He's sending calls to the provider. |
14:29.02 | Samot | In SIP the domain is the part after @ |
14:29.08 | Samot | It could be an IP or a FQDN |
14:29.26 | Samot | I even updated with an example IP. |
14:29.41 | Samot | So I'm being told right now, the destination IP/domain of the provider is unknown. |
14:29.55 | seanbright | maybe it is unknown in dialplan? |
14:30.03 | gtjoseph | this is why i wanted to move this discussion to the asterisk-dev mailing list. |
14:30.07 | Samot | He's saying he wants to do this ARI/AMI |
14:30.09 | Samot | So... |
14:30.15 | Samot | Construct it properly. |
14:31.49 | gtjoseph | he'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.56 | Samot | Stop. |
14:32.01 | Samot | Please stop. |
14:32.11 | Samot | Let's try this for a calm, logical point of view. |
14:32.21 | Samot | I have a provider. I need to accept/send calls from them. |
14:32.24 | Samot | How would I do that? |
14:32.33 | Samot | Oh they would give me FQDNs or IPs to use. |
14:33.04 | Samot | So my PJSIP endpoint used as a trunk for said provider would have an AOR with a static contact. |
14:33.22 | Samot | sip:sip.domain.com:5060 |
14:33.31 | Samot | or sip:12.0.0.10:5060 |
14:34.31 | Samot | So I already have these details. So what is stopping me from saying pjsip:pstn-trunk/sip:${EXTEN}@12.0.0.10:5060 |
14:35.06 | Samot | This isn't some rando user REGISTERing to Asterisk you need to dig their dynamic contact up for. |
14:36.38 | gtjoseph | I 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.14 | Samot | There already are proper solutions. |
14:38.36 | file | Samot: just stop. |
14:38.49 | Samot | Sure. |
14:39.04 | file | let gtjoseph work this out as he needs, he's spent an absurd amount of time in this area lately |
14:39.22 | Samot | I'm not against the idea of being able to make it work like Dial() |
14:39.43 | file | cease. |
14:44.07 | JAunis | i'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.07 | kerouac[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.17 | orn | kerouac[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.40 | kerouac[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) |