| 00:19.52 | *** join/#asterisk juvenal (juvenal@gateway/shell/elitebnc/x-sojwaqgwdbzvhlsq) |
| 00:56.49 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 01:46.37 | *** join/#asterisk Fesuy (~Fesuy@113.11.153.53) |
| 01:47.19 | Fesuy | .clear |
| 04:13.11 | *** join/#asterisk robink (~quassel@unaffilated/robink) |
| 04:20.52 | *** join/#asterisk MrTAP (~MrT@unaffiliated/mrtap) |
| 04:51.57 | *** join/#asterisk shuishui (~chirpin-2@114.221.23.213) |
| 05:31.08 | *** join/#asterisk beachdog (~beachdog@107.72.96.187) |
| 05:33.04 | *** join/#asterisk gerhard7__ (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 05:57.09 | *** join/#asterisk evil_gordita (robert@ip70-188-41-127.rn.hr.cox.net) |
| 06:01.23 | *** join/#asterisk shuishui (~chirpin-2@114.221.23.213) |
| 06:30.26 | *** join/#asterisk Kaian (~kaian@212.81.221.228) |
| 06:40.32 | *** join/#asterisk jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 07:34.10 | *** join/#asterisk robmal (r@wporzo.pl) |
| 07:44.04 | *** join/#asterisk tzafrir (~tzafrir@local.xorcom.com) |
| 08:00.18 | *** join/#asterisk Da-Geek (~Da-Geek@212.234.170.221) |
| 08:25.35 | *** join/#asterisk pchero_work (~pchero@109.70.54.56) |
| 08:57.10 | *** join/#asterisk defsdoor (~andy@cpc120600-sutt6-2-0-cust177.19-1.cable.virginm.net) |
| 10:06.53 | *** join/#asterisk [[thufir]] (~thufir@192.157.119.2) |
| 10:31.24 | *** join/#asterisk miralin (~Thunderbi@91.237.94.13) |
| 10:47.28 | *** join/#asterisk bmg505 (~leon@196-210-200-180.dynamic.isadsl.co.za) |
| 11:00.47 | *** join/#asterisk MrMojit0 (~MrMojit0@194.171.91.248) |
| 11:19.53 | *** join/#asterisk DanB (~DanB@clt-195.192.205.171.ip-anschluss.net) |
| 11:29.05 | *** join/#asterisk lankanmon (~LKNnet@CPE64777dd7e053-CM64777dd7e050.cpe.net.cable.rogers.com) |
| 12:05.27 | *** join/#asterisk gerhard7__ (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 12:19.07 | *** join/#asterisk Blinky_ (~Blinky_@host81-136-203-112.in-addr.btopenworld.com) |
| 12:23.12 | Blinky_ | hi all, having an issue with dropped calls, happening a few times today and need some help figuring it out, here is the log for 2 of the drop outs. here is the log file - https://pastebin.com/wgfGg5ry |
| 12:39.05 | *** join/#asterisk robmal (r@wporzo.pl) |
| 13:09.21 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 13:11.13 | [TK]D-Fender | Blinky_, those logs don't show anything about the call |
| 13:12.06 | Blinky_ | [TK]D-Fender, Cheers for the reply, they show the hangup, is that not enough I can show the start of the call as well if you need it. |
| 13:12.06 | [TK]D-Fender | There is no channel level debug for the calling, or called legs of this and we don't see the called side at all. |
| 13:12.32 | [TK]D-Fender | that doesn't shwo the hangup. That shows a cleanup after a bridge ends. |
| 13:12.33 | Blinky_ | Ah |
| 13:12.49 | [TK]D-Fender | it doesn't show a side actually declaring it is aborting |
| 13:15.50 | Blinky_ | [TK]D-Fender, This is the rest of the call I think - https://pastebin.com/Mp7rpyxE |
| 13:16.15 | [TK]D-Fender | Again, we have no channel level debug |
| 13:16.24 | [TK]D-Fender | that is required to prove who ended it and why |
| 13:17.16 | Blinky_ | How do I enable the channel level debug so it adds it to the full log file? |
| 13:18.22 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 13:20.43 | [TK]D-Fender | I don't do "logs". Live CLI only |
| 13:23.03 | Blinky_ | [TK]D-Fender, ok, could you possibly give me a little information as to how I diagnose calls dropping out, I am being told about them after they have happened and there is no pattern to it. What should I be looking for? |
| 13:23.50 | [TK]D-Fender | Again channel-level debug |
| 13:23.56 | [TK]D-Fender | Which in this case is IAX2 |
| 13:29.58 | *** join/#asterisk syle (~cessna@S01060015178092dc.no.shawcable.net) |
| 13:30.06 | *** join/#asterisk evilman_work (~evilman@87.244.6.228) |
| 13:31.21 | Blinky_ | [TK]D-Fender, This is not an error but is it the correct level of debug needed? - https://pastebin.com/YfsEPtFU |
| 13:33.06 | [TK]D-Fender | No. |
| 13:33.15 | [TK]D-Fender | "iax2 set debug on" <- |
| 13:34.11 | Blinky_ | Gotcha |
| 13:46.15 | Blinky_ | [TK]D-Fender, Is this a high number of retries, I am getting a lot of these, to be fair the log file is full of these - https://pastebin.com/9pHPtfe1 |
| 13:47.46 | [TK]D-Fender | Need to see proper debug with a full call |
| 13:47.53 | [TK]D-Fender | not some random little snippit |
| 13:51.22 | Blinky_ | [TK]D-Fender, Last try - it is this or a huge file - https://pastebin.com/aunAK2ti |
| 13:52.01 | [TK]D-Fender | Where is all the OTHER call debug? |
| 13:52.07 | [TK]D-Fender | dialplan execution and all.... |
| 13:52.12 | [TK]D-Fender | we aren't looking at a complete picture |
| 13:55.49 | *** join/#asterisk u0m3 (~u0m3@86.127.131.167) |
| 14:11.43 | *** join/#asterisk wasanzy (~wasanzy@41.242.137.170) |
| 14:21.13 | *** join/#asterisk sotoz (~sotoz@095-097-255-066.static.chello.nl) |
| 14:22.18 | sotoz | Hello, do you know if it's possible to read at Asterisk a SIP header for a channel that was added on a reply from kamailio? |
| 14:22.51 | sotoz | I want to set a specific custom header on the `reply_route` in kamailio and then be able to read that header from Asterisk |
| 14:23.36 | file | in both chan_sip and chan_pjsip you can only read SIP headers from the initial INVITE |
| 14:23.57 | sotoz | dammit :( |
| 14:24.39 | sotoz | how can I transfer some metadata then? from kamailio to asterisk and then to my stasis app through ARI ? |
| 14:30.00 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 14:32.50 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 14:33.14 | sotoz | I know SIP should not be used for this but still it would be super handy if I could have access to SIP headers from asterisk other than the ones in the initial INVITE |
| 14:38.38 | *** join/#asterisk biomorph (~charles@116.115.208.46.dyn.plus.net) |
| 14:41.00 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 14:43.36 | [TK]D-Fender | Handy, yes. An option with *, no. |
| 14:46.27 | wasanzy | hello |
| 14:46.58 | file | not without someone writing and contributing such a change |
| 14:47.34 | sotoz | do you think that this will be useful for others too? |
| 14:47.50 | sotoz | I can investigate if I could contribute such a change if there is value on it |
| 14:48.17 | sotoz | maybe a question for the mailing list but anyhow |
| 14:48.34 | file | it's come up in the past so people would probably like it |
| 14:50.37 | wasanzy | I have to context (A and B), I want to forward call to context B from context A using Goto() , after the context B finished processing, it should forward call back to context A. The issue is there are so many context going to call Context B and which ever context forwards the call to context B, it should send the call back to that context |
| 14:51.04 | wasanzy | I know of ${CONTEXT} |
| 14:51.23 | file | why don't you use a Gosub then? |
| 14:51.58 | wasanzy | but that I think holds the current context which will be B |
| 14:52.02 | [TK]D-Fender | And don't call it "forward" |
| 14:52.34 | wasanzy | file: if that will do what I want, I will |
| 14:52.36 | [TK]D-Fender | and what do you mean "holds the current context"? |
| 14:52.46 | [TK]D-Fender | you are mashing the term "context everywhere there. |
| 14:52.46 | file | https://wiki.asterisk.org/wiki/display/AST/GoSub |
| 14:52.58 | wasanzy | [TK]D-Fender: what is the right term to use? |
| 14:53.34 | [TK]D-Fender | if you want to run a chunk of code in some other place and then continue processing right after the part where you jumped out, then GOSUB <- |
| 14:54.18 | [TK]D-Fender | exten => 123,1,Gosub(otherplace,s,1) |
| 14:54.44 | [TK]D-Fender | exten => 123,2,NoOp(If we're here then the Gosub RETURN'd properly) |
| 14:55.22 | wasanzy | d properly? |
| 14:55.33 | wasanzy | file: thank you |
| 14:56.30 | [TK]D-Fender | "core show application gosub" <- |
| 14:57.18 | wasanzy | ok |
| 15:01.13 | wasanzy | ok I see Return() |
| 15:01.34 | file | that only works within a Gosub, so you have to use a Gosub for it |
| 15:02.14 | Samot | sotoz: How would that work? Are you going to allow the getting of all the header? Some of the fields? Are you talking all requests/replies |
| 15:03.18 | wasanzy | file: yes. but my problem is, the return seems to be returning to the priority at which the context was called. I want to return to a different priority under the calling context |
| 15:03.43 | Samot | That's not out GoSub works |
| 15:03.58 | [TK]D-Fender | How do you determine that? |
| 15:03.58 | Samot | You do not return to another context or priority |
| 15:05.13 | wasanzy | ok |
| 15:05.20 | [TK]D-Fender | How do you determine that? <- wasanzy |
| 15:05.45 | wasanzy | [TK]D-Fender: determine that priority I want to return to? |
| 15:06.08 | [TK]D-Fender | yes |
| 15:06.40 | wasanzy | I labeled the priority |
| 15:06.52 | [TK]D-Fender | I don't care that it is labeled. |
| 15:07.06 | [TK]D-Fender | I asked how you DETERMINE that yuo want to go there.' |
| 15:07.25 | [TK]D-Fender | WHERE & WHEN is that decision made? |
| 15:07.51 | sotoz | Samot: As an initial thought I was thinking of having access to SIP headers after receiving a reply. Although that would need extra work on determining how this will actually work cause the dialplan is SIP "agnostic" if I can say so. |
| 15:07.52 | wasanzy | [TK]D-Fender: if a condition is true it should go there otherwise do something else |
| 15:08.13 | [TK]D-Fender | wasanzy, that doesn not answer either of those |
| 15:08.38 | [TK]D-Fender | At what point in your CALL FLOW is this determined? |
| 15:08.48 | Samot | sotoz: OK and what would we do with them? |
| 15:09.16 | wasanzy | [TK]D-Fender: when a user entered an invalid key for 3 times |
| 15:10.02 | Samot | So why is a gosub needed? |
| 15:10.06 | [TK]D-Fender | wasanzy, that is not helping. AT WHAT POINT IN THIS CHAIN OF CONTEXTS, GOSUBS, ETC?! |
| 15:10.13 | Samot | That sounds like a WaitExten and t extension |
| 15:10.15 | [TK]D-Fender | is it BEFORE you jump to that other place ? |
| 15:10.21 | [TK]D-Fender | Is it IN that other place? |
| 15:10.24 | Samot | er i extension |
| 15:10.55 | sotoz | Samot: For my use case, I would like to set a custom header (based on some business logic) in the SIP server that receives the reply and relays it to asterisk. Then with ARI I will have access to that SIP header and doSomething() with it. |
| 15:11.33 | sotoz | it could be accounting, logging or whatever |
| 15:12.28 | [TK]D-Fender | wasanzy, if you are using this "subroutine" and want to use it multiple places and jump back to different places based on where it was called from then just set the LABEL in a variable and jump after you come BACK. |
| 15:12.49 | Samot | sotoz: What SIP server? |
| 15:13.00 | Samot | sotoz: What custom header? Who is going to receive it? |
| 15:13.07 | Samot | sotoz: Where does it get set? |
| 15:13.17 | Samot | Custom headers are not kept by other sources |
| 15:13.23 | Samot | Or looked at |
| 15:13.58 | wasanzy | [TK]D-Fender: I don't want to keep repeating same codes under each context so I wanted to dedicate a context for checking the number of times a user enters invalid key. something like a function or method in programming languages |
| 15:14.12 | [TK]D-Fender | <[TK]D-Fender> wasanzy, if you are using this "subroutine" and want to use it multiple places and jump back to different places based on where it was called from then just set the LABEL in a variable and jump after you come BACK. |
| 15:14.30 | *** join/#asterisk dar123 (~dar@2602:306:bcbf:e750:41fd:df57:4b2a:7edb) |
| 15:14.38 | wasanzy | [TK]D-Fender: ok |
| 15:18.48 | *** join/#asterisk Yiota (~textual@199.33.115.187) |
| 15:21.00 | *** join/#asterisk davlefouAMD (~davlefouA@cantaron.reveyo.com) |
| 15:46.56 | *** join/#asterisk NotHere (~steve@master.math.upatras.gr) |
| 16:03.10 | *** join/#asterisk Yiota (~textual@199.33.115.187) |
| 16:04.23 | *** join/#asterisk gerhard7__ (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 16:08.36 | *** join/#asterisk corretico (~corretico@200.91.143.34) |
| 16:42.01 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 16:46.44 | *** join/#asterisk Yiota (~textual@199.33.115.187) |
| 16:47.32 | *** join/#asterisk dar123 (~dar@2602:306:bcbf:e750:38db:a7f5:e487:85e8) |
| 16:49.47 | *** join/#asterisk beachdog2 (~beachdog@107.72.99.29) |
| 16:55.53 | *** join/#asterisk MrTAP (~MrT@unaffiliated/mrtap) |
| 17:12.38 | *** join/#asterisk MrTAP (~MrT@unaffiliated/mrtap) |
| 17:14.20 | *** join/#asterisk Yiota (~textual@199.33.115.187) |
| 17:14.34 | *** join/#asterisk dar123 (~dar@2602:306:bcbf:e750:38db:a7f5:e487:85e8) |
| 17:30.20 | *** part/#asterisk MrTAP (~MrT@unaffiliated/mrtap) |
| 17:31.00 | *** join/#asterisk dar123 (~dar@107-203-254-117.lightspeed.sntcca.sbcglobal.net) |
| 17:31.37 | *** join/#asterisk jkroon (~jkroon@165.16.204.168) |
| 17:33.27 | *** join/#asterisk beachdog (~beachdog@107.72.96.187) |
| 17:45.19 | *** join/#asterisk Yiota (~textual@199.33.115.187) |
| 17:47.46 | sibiria | in a call file, does WaitTime apply to the entire process from the very moment asterisk picks up the call file, or does the waiting time only start once signals are going through to the called party? |
| 17:49.31 | [TK]D-Fender | There shouldn't be any real time difference in the call going out |
| 17:50.12 | sibiria | well sometimes, depending on trunk and called party's provider etc., it takes a few second to bring the call up so to speak |
| 17:50.27 | sibiria | before the phone starts ringing that is |
| 17:51.29 | [TK]D-Fender | the waittime is total |
| 17:51.44 | [TK]D-Fender | so if there is some sort of setup delay then that's included in it |
| 17:51.51 | sibiria | alright, thanks [TK]D-Fender |
| 17:58.05 | *** join/#asterisk sekil (~sekil@cable-89-216-193-59.dynamic.sbb.rs) |
| 18:02.51 | *** join/#asterisk Yiota (~textual@199.33.115.187) |
| 18:05.50 | *** join/#asterisk pchero (~pchero@109.70.54.56) |
| 18:39.41 | *** join/#asterisk windback (~windback@190.123.122.162) |
| 18:40.18 | windback | [TK]D-Fender, Hi |
| 18:40.32 | windback | [TK]D-Fender, One question related to PJSIP |
| 18:42.56 | windback | [TK]D-Fender, Is there any way to identify incoming invites when the far end sends INVITES with differents FROM headers (because he wants to puts different callers id) and not identifying by IP? |
| 18:45.18 | file | If doing outbound registration you can turn on line support and we can try to associate incoming INVITEs. |
| 18:45.33 | file | Otherwise nothing built in. |
| 19:15.12 | *** join/#asterisk Yiota (~textual@199.33.115.187) |
| 19:33.42 | *** join/#asterisk beachdog (~beachdog@107.72.99.55) |
| 19:36.18 | windback | file, there is something: "match_header" in type=identify |
| 19:36.32 | file | yes, if you control the environment then header matching can be done |
| 19:37.51 | windback | file, also I have just realize that using identify_by=auth_username in endpoint section solves my problem |
| 19:38.37 | windback | Now the far end pbx can send different numbers in FROM header and I can still match the endpoint by the authentication |
| 20:06.37 | *** join/#asterisk SpSpBy (~SpSpBy@190.111.231.108) |
| 20:21.15 | *** join/#asterisk Yiota (~textual@199.33.115.187) |
| 20:28.54 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
| 20:47.03 | *** join/#asterisk DamnADs (~wilfred@urchin.nyi.net) |
| 20:47.12 | DamnADs | happy thanks givings ;-) |
| 20:47.30 | DamnADs | :-) |
| 20:47.36 | DamnADs | happy thanks givings ;-) |
| 20:49.46 | *** join/#asterisk beachdog (~beachdog@ip68-107-111-57.sd.sd.cox.net) |
| 21:15.13 | *** join/#asterisk tzafrir (~tzafrir@62-90-199-170.barak.net.il) |
| 21:18.19 | *** join/#asterisk BBone_ (~Thunderbi@maila.fraserwoodindustries.com) |
| 21:18.50 | *** join/#asterisk beachdog2 (~beachdog@107.72.99.66) |
| 21:24.27 | *** join/#asterisk beachdog (~beachdog@ip68-107-111-57.sd.sd.cox.net) |
| 21:26.37 | *** join/#asterisk Jesterboxboy (~Thunderbi@80-109-194-26.cable.dynamic.surfer.at) |
| 21:38.44 | *** join/#asterisk beachdog (~beachdog@107.72.99.104) |
| 21:44.32 | *** join/#asterisk beachdog (~beachdog@ip68-107-111-57.sd.sd.cox.net) |
| 21:44.49 | *** join/#asterisk beachdog (~beachdog@ip68-107-111-57.sd.sd.cox.net) |
| 22:04.10 | *** join/#asterisk beachdog (~beachdog@107.72.99.54) |
| 22:10.36 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 22:15.54 | *** join/#asterisk beachdog (~beachdog@ip68-107-111-57.sd.sd.cox.net) |
| 22:28.25 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
| 22:52.31 | *** join/#asterisk Yiota (~textual@199.33.115.187) |
| 23:04.54 | *** join/#asterisk beachdog (~beachdog@ip68-107-111-57.sd.sd.cox.net) |
| 23:06.54 | *** join/#asterisk beachdog (~beachdog@ip68-107-111-57.sd.sd.cox.net) |
| 23:08.59 | *** join/#asterisk beachdog (~beachdog@ip68-107-111-57.sd.sd.cox.net) |
| 23:34.11 | *** join/#asterisk zapata (~zapata@2a02:b18:581:10:5424:c0fe:f045:93ee) |
| 23:43.58 | *** join/#asterisk beachdog (~beachdog@ip68-107-111-57.sd.sd.cox.net) |
| 23:52.52 | *** join/#asterisk beachdog (~beachdog@107.72.99.71) |
| 23:53.12 | *** join/#asterisk beachdog (~beachdog@107.72.99.71) |
| 23:53.28 | *** join/#asterisk beachdog (~beachdog@107.72.99.71) |
| 23:57.49 | *** join/#asterisk jvwjgames_ (~jvwjgames@mail.stmarguerites.org) |