| 00:30.40 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 00:34.14 | Kobaz | endpoint_identifier_order is not per endpoint |
| 00:34.15 | Kobaz | which makes sense |
| 00:49.57 | Kobaz | okay so... endpoint_identifier_order : username,ip,anonymous |
| 00:50.36 | Kobaz | and then pjsip stops checking once it hits an ip |
| 00:50.37 | Kobaz | which seems wrong |
| 00:54.18 | Kobaz | In theory this should be straight-forward... to check users first and then ips |
| 00:55.51 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 00:56.46 | Kobaz | https://asterisk-dev.digium.narkive.com/6fdd5kVj/pjsip-identify-idea |
| 00:56.58 | Kobaz | Yeah basically... the same thing i'm running into. the identifier is quite limited |
| 00:57.15 | Samot | Kobaz: Sorry, there is a per endpoint option. |
| 00:57.32 | Kobaz | Samot: are the docs wrong? |
| 00:57.49 | Samot | No, I was. |
| 00:58.02 | Samot | Yes, there is a global setting for that and yes there is a per endpoint setting for it. |
| 00:58.53 | Kobaz | ....One of the identifiers is "auth_username" which |
| 00:58.58 | Kobaz | https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Configuration_res_pjsip#Asterisk16Configuration_res_pjsip-global_endpoint_identifier_order |
| 00:59.42 | Kobaz | that's just talking about the identifiers though? |
| 00:59.50 | Kobaz | not an option to endpoint_identifier_order? |
| 00:59.57 | Kobaz | or is it |
| 01:00.02 | Kobaz | trys something |
| 01:00.39 | Kobaz | <PROTECTED> |
| 01:02.17 | Kobaz | asterisk still sending a 404 not found |
| 01:02.54 | Kobaz | What happens is... core debug, pjsip is showing that it's trying to match identifiers, which by definition is by IP |
| 01:03.23 | Kobaz | there's nothing in the logs saying it's trying any username auth, but maybe there's no logging for that (it could still be trying, but it doesn't look like it) |
| 01:03.45 | Kobaz | i may have to dig and add debugging |
| 01:04.22 | Kobaz | and ideally, it should continue searching for an identifier if it matches an ip but the rest of it fails |
| 01:04.48 | Samot | Kobaz: What do you want to match against? |
| 01:04.50 | Kobaz | because i have many, many situations where there's more than one endpoint with the same ip |
| 01:04.59 | Kobaz | I want to match against username and then fall back to ip |
| 01:05.17 | Kobaz | so it has to match the ip AND username |
| 01:05.40 | Samot | username,ip |
| 01:05.46 | Kobaz | that doesn't work |
| 01:06.13 | Samot | Then you need to do ip |
| 01:06.19 | Samot | And use the match_header option |
| 01:06.33 | Kobaz | matching by ip is not an option |
| 01:06.41 | Samot | Christ. |
| 01:06.44 | Kobaz | it needs to register to a username, like it can in chan_sip |
| 01:06.48 | Samot | IP makes the identity happen. |
| 01:06.56 | Samot | I just said username,ip |
| 01:06.59 | Samot | You said that doesn't work |
| 01:07.00 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 01:07.03 | Kobaz | I don't have an identity yet... it's not registered |
| 01:07.07 | Kobaz | Right, it doesn't work |
| 01:07.14 | Samot | So it doesn't work why? |
| 01:07.18 | Samot | It's not matching a username? |
| 01:07.27 | Kobaz | Device at 1.2.3.4 is registering to the endpoint called 'foo' |
| 01:07.34 | Samot | OK. |
| 01:07.40 | Kobaz | Well it just so happens that 1.2.3.4 is also an identity for something entirely different |
| 01:07.47 | Kobaz | an endpoint called 'bar' |
| 01:07.59 | Samot | So which endpoint should this device use? |
| 01:08.12 | Samot | Kobaz: I have thousands of users coming from Kamailio. |
| 01:08.14 | Samot | 1 IP |
| 01:08.18 | Kobaz | if there's a registration from 1.2.3.4 to endpoint 'foo' and it matches the password, it should use 'foo' |
| 01:08.21 | Samot | I use the username to auth against. |
| 01:08.33 | Kobaz | Okay, are there other options that need to be turned on? |
| 01:08.41 | Samot | Yes |
| 01:08.42 | Kobaz | other than username,ip? |
| 01:08.48 | Samot | No. |
| 01:08.55 | Samot | I have the order username,ip |
| 01:08.55 | Kobaz | Okay, then it's not working |
| 01:09.05 | Samot | All the requests come from the same IP |
| 01:09.09 | Samot | thousands of users |
| 01:09.14 | Samot | All matching is against the username |
| 01:09.18 | Kobaz | Okay |
| 01:09.25 | Samot | So show what you have. |
| 01:09.27 | Kobaz | Do you also have a 'static' endpoint also pointing to the same username |
| 01:09.38 | Samot | What do you mean a static endpoint? |
| 01:09.46 | Kobaz | I have accepts_registrations endpoints... AND an endpoint with hosts= |
| 01:09.48 | Samot | I have static contacts in AORs for sending requests |
| 01:10.01 | Kobaz | remote_hosts=, sorry |
| 01:10.03 | Samot | There is no host= setting in PJSIP |
| 01:10.23 | Kobaz | what is happening here, is the matching is stopping at the endpoint that has remote_hosts=1.2.3.4 |
| 01:10.26 | Samot | SEnding requests to a contact is done via AORs. |
| 01:10.37 | Kobaz | I don't have an AOR yet, the device cannot register |
| 01:11.01 | Kobaz | I don't have a contact... the device cannot register... i don't have an identify... the device.... you see where this is going |
| 01:11.01 | file | the From username based identifier is littered with log messages, and if you changed the identifier order a restart has to occur for it to apply |
| 01:11.01 | Samot | No AOR, no registration |
| 01:11.12 | Samot | No. |
| 01:11.13 | Samot | JFC. |
| 01:11.18 | Samot | You need to create an endpoint |
| 01:11.22 | Samot | You need to create an AOR |
| 01:11.22 | Kobaz | Correct |
| 01:11.24 | Kobaz | No |
| 01:11.28 | Samot | YES |
| 01:11.32 | Samot | You need an AOR section |
| 01:11.35 | Kobaz | registration creates the AOR on successful registration |
| 01:11.35 | Samot | For the endpoint to use |
| 01:11.39 | Samot | No. |
| 01:11.44 | Samot | You need an AOR section |
| 01:11.53 | Samot | It will create a CONTACT upon registration |
| 01:12.04 | Samot | The endpoint has an aors= setting |
| 01:12.12 | Samot | That needs to point to the AOR section that you create |
| 01:12.26 | Samot | That tells it how many contacts can be registered |
| 01:12.35 | Samot | If it should remove existing contacts |
| 01:12.41 | Samot | What the qualifier is |
| 01:12.45 | Samot | What mailboxes to subscriber to |
| 01:12.46 | Kobaz | Right, contacts. I'm thinking of contacts |
| 01:12.52 | Samot | Yes, you are. |
| 01:12.52 | Kobaz | I'm using the wizard to make the endpoint |
| 01:12.57 | Samot | So you need an AOR |
| 01:13.06 | Kobaz | yes, I have an aor |
| 01:13.10 | Samot | OK |
| 01:13.17 | Samot | And you need to make an identity section |
| 01:13.28 | Samot | Those three things are required for using ip / header matching |
| 01:13.38 | Samot | And doing registration |
| 01:13.54 | Samot | Oh and the auth section |
| 01:13.57 | Samot | Sorry, 4 things |
| 01:13.58 | Kobaz | right all that's done |
| 01:14.02 | Samot | You need an inbound auth section |
| 01:14.06 | Kobaz | by the wizard |
| 01:14.08 | Samot | Endpoint, AOR, Auth |
| 01:14.08 | Kobaz | I have all that |
| 01:14.18 | Samot | Plus the Identity if you want to limit by IP/header |
| 01:14.28 | Kobaz | Okay let me do an experiment |
| 01:14.32 | file | Kobaz: did you restart Asterisk after changing the identifier order? |
| 01:14.40 | Samot | ^^^^^^ |
| 01:14.48 | Kobaz | file: yes, but i also noticed if you have allow restart, you don't need to restart as well |
| 01:15.07 | Kobaz | let me do an experiment real quick |
| 01:15.07 | Samot | Doing allow_reload=yes in the transports can be bad. |
| 01:15.21 | file | that has nothing to do with identifier ordering. |
| 01:15.33 | Samot | Also that |
| 01:15.35 | Kobaz | Everyone says that, but i've never run into a situation where it broke something, maybe i'm special |
| 01:15.43 | Kobaz | Anyway, let me do my experiment |
| 01:15.49 | file | you're not special, it's a race condition as to whether it will or not |
| 01:15.56 | Kobaz | aaah |
| 01:16.50 | Kobaz | yup |
| 01:16.52 | Kobaz | it works |
| 01:17.02 | Kobaz | if i remove my 'bar' endpoint that has an identify for 1.2.3.4 |
| 01:17.05 | Kobaz | i can register the endpoint |
| 01:17.27 | Kobaz | because the device is also coming from 1.2.3.4, that's trying to link up to an endpoint that accepts_registration |
| 01:17.47 | Kobaz | this is what my theory was... the matching stops when it hits the ip in identify, even though the auth doesn't match at all |
| 01:18.45 | Kobaz | yup |
| 01:18.51 | Kobaz | it's a limitation in the matching |
| 01:18.57 | Kobaz | <PROTECTED> |
| 01:19.02 | Kobaz | Now it's matching on username |
| 01:19.04 | Kobaz | Before it wasn't |
| 01:19.39 | Kobaz | So this is why the option doesn't work (endpoint_identifier_order : username,ip) |
| 01:19.44 | Kobaz | for my use case |
| 01:21.26 | Kobaz | So... correct me if I'm wrong. But I think the solution here is... when finding a matching identify, and we have failed auth... continue to match until it finds something, including usernames |
| 01:21.39 | file | you didn't have failed auth |
| 01:21.51 | file | you had a REGISTER attempt that was rejected |
| 01:22.29 | Kobaz | well, i suppose fail auth is not entirely correct. It just... found something that kind of matched.. checked it further and then gave up, not found |
| 01:23.07 | Kobaz | it matched the ip, but nothing else it.. halt matching |
| 01:23.30 | file | I can not reproduce your issue |
| 01:23.52 | file | I leave it at the default, it matches by IP first |
| 01:23.58 | Kobaz | k |
| 01:24.01 | file | I set "endpoint_identifier_order=username,ip,anonymous" in the global section, restart Asterisk, it matches based on username |
| 01:24.49 | Kobaz | hmm okay |
| 01:25.09 | Kobaz | i've done so many restarts and config changes, let me start over... clean restart and "endpoint_identifier_order=username,ip,anonymous |
| 01:26.10 | Kobaz | okay |
| 01:26.11 | Kobaz | whew |
| 01:26.13 | Kobaz | it does work |
| 01:26.13 | Samot | Kobaz: Your endpoints don't need outbound_auth |
| 01:26.24 | Kobaz | Samot: yeah, that's from my config generator, that's on the list |
| 01:26.39 | Kobaz | file: thanks for checking my sanity |
| 01:26.49 | Kobaz | it was confusing because... pjsip show settings: endpoint_identifier_order : username,ip |
| 01:27.02 | Kobaz | and it wasn't working... so that time there must not have been a full restart |
| 01:28.02 | Kobaz | Okay so... I think in the future, it would be great if you did have ip,username,anonymous... and there WAS an ip match, and it's not 'fully matched'... it should continue on to the usernames, instead of giving a 404 |
| 01:28.58 | Samot | What do you mean fully matched? |
| 01:29.12 | Kobaz | Whatever conditions would cause a 404 to be thrown |
| 01:29.13 | Samot | It's not a match this and that type thing. |
| 01:29.56 | Kobaz | Like... I have this other endpoint 'bar', that has remote_hosts=1.2.3.4 |
| 01:30.05 | Samot | OK |
| 01:30.11 | Kobaz | and my device is trying to register from 1.2.3.4 to the endpoint 'foo' |
| 01:30.20 | Kobaz | foo has accepts_registrations |
| 01:30.22 | Kobaz | but bar does not |
| 01:30.43 | Kobaz | so bar, with the Contact already staticly set... is matched due to 1.2.3.4 |
| 01:31.01 | Kobaz | that's what i mean by 'fully matched' |
| 01:31.22 | Kobaz | whatever the rule is that's saying, no-go... it should not completely bail matching because it hit the first matching ip address rule |
| 01:31.48 | *** join/#asterisk paulgrmn (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 01:32.14 | Samot | So it matched against bar. |
| 01:32.30 | Samot | Bar doesn't have inbound_auth or a registration section set. |
| 01:32.36 | Kobaz | correct |
| 01:32.41 | Kobaz | so then the matching is done |
| 01:32.42 | Samot | Bar doesn't accept registrations. What's the problem? |
| 01:32.46 | Samot | Correct. |
| 01:32.50 | Samot | Because it matched on IP |
| 01:33.09 | Kobaz | Wouldn't it be useful... to say okay, it matched the ip there, but it's not a 'solid match' |
| 01:33.26 | Kobaz | keep going until you either 1) exhaust the list, or 2) find a better match |
| 01:33.27 | Samot | So you want to match on IP AND do auth |
| 01:33.37 | Samot | No. |
| 01:33.38 | Kobaz | but not for that endpoint |
| 01:33.55 | Samot | You setup an identity to match this IP and associate that match to X endpoint. |
| 01:34.09 | Samot | There is no other "let's keep moving because it didn't do registration" |
| 01:34.13 | Kobaz | i'm registering... so obviously 'bar' that has no inbound_auth and no registration section, is not a good match |
| 01:34.18 | Samot | That could just mean the endpoint is misconfigured. |
| 01:34.30 | Kobaz | I understand there is no 'lets keep moving' |
| 01:34.36 | Kobaz | I think that would be useful |
| 01:34.39 | file | no, because better is relative and that means different packets could match differently and be a headache, it would also overly complicate the code |
| 01:34.40 | Samot | There is no better match |
| 01:34.42 | Samot | That IS the match |
| 01:35.03 | Kobaz | I'm not saying make it a default |
| 01:35.26 | Kobaz | But in this case, say you primarilly want to match on ip, so go for it, and then allow for rollover matching |
| 01:35.27 | file | and handlers of packets would likely need changing |
| 01:35.34 | Kobaz | ah |
| 01:35.34 | Samot | What rollover? |
| 01:35.44 | Samot | What is a rollover matching? |
| 01:35.48 | Kobaz | i renamed my 'better matching' to 'rollover' |
| 01:35.54 | Kobaz | because yes, better is subjective |
| 01:36.06 | Samot | I have an Identity section, it says match on X IP |
| 01:36.13 | Samot | And use Y endpoint. |
| 01:36.18 | Kobaz | Correct |
| 01:36.18 | Samot | A request came from X IP, it matched. |
| 01:36.23 | Kobaz | Well |
| 01:36.25 | Kobaz | Not exaxtly |
| 01:36.26 | Samot | Where is there a need for rollover? |
| 01:36.28 | Samot | Stop |
| 01:36.28 | Kobaz | Not in my use cast |
| 01:36.29 | Samot | It matched |
| 01:36.47 | file | it did because the configuration explicitly made it match |
| 01:36.48 | Kobaz | It came from that ip, and it's a REGISTER |
| 01:36.49 | Samot | You can't have 100 of devices from the same IP use IP to match on. |
| 01:37.04 | Samot | That's not what Identify is for. |
| 01:37.07 | Kobaz | correct |
| 01:37.20 | Kobaz | BUT. there's overlap, right... some other device, on that IP, needs to match on that ip |
| 01:37.24 | Samot | The fact the endpoint it matches against doesn't do registration is totally different. |
| 01:37.32 | Kobaz | but things that register, should register to their endpoints, not match the ip |
| 01:37.32 | Samot | You can't do that |
| 01:37.35 | Samot | At all |
| 01:37.40 | Kobaz | I understand you can't do that |
| 01:37.47 | Samot | A match on an IP is a match on an IP |
| 01:37.57 | Kobaz | I'm just getting feedback on... should I invest the time to add support for this as a general use case |
| 01:38.12 | Samot | If you have 5 devices behind the same IP and 5 different endpoints, you cannot match based on IP |
| 01:38.23 | Kobaz | Playing devils advocate here, saying there could very well be a good use for it |
| 01:38.37 | file | I see it adding complexity with very little usage and just being more code to maintain personally speaking |
| 01:38.39 | Samot | So it should match on TWO things. |
| 01:38.47 | Kobaz | file: Okay thanks |
| 01:38.48 | Samot | It becomes IP AND user |
| 01:39.24 | Samot | You basically want Identity to ignore the endpoint= setting |
| 01:39.30 | Kobaz | A whole complex matching system: a-la https://asterisk-dev.digium.narkive.com/6fdd5kVj/pjsip-identify-idea... would definitely add complexity |
| 01:40.19 | Samot | Kobaz |
| 01:40.21 | Kobaz | Samot: ignore the endpoint= if there's another way to get to an endpoint |
| 01:40.29 | Kobaz | ie: one that accepts registrations |
| 01:40.52 | Samot | So it needs to then search by what? |
| 01:40.57 | Samot | the username? |
| 01:41.07 | Kobaz | yeah |
| 01:41.19 | Samot | Why aren't you just matching on username? |
| 01:41.29 | Samot | Why does it need to match on username and IP? |
| 01:41.38 | Kobaz | because.... why not? |
| 01:42.02 | Samot | Use Kamailio. |
| 01:42.05 | Kobaz | Yeah |
| 01:42.10 | Kobaz | My use case could very well be uncommon for asterisk |
| 01:42.22 | Kobaz | I have tons of things like test trunks all coming and going to the same boxes |
| 01:42.34 | Samot | That's no uncommon for Asterisk |
| 01:42.37 | Kobaz | and it's matched by username in chan_sip |
| 01:42.46 | Samot | People, like me, just realize more is needed to make it work with Asterisk |
| 01:42.49 | Samot | Like Kamailio |
| 01:42.49 | Kobaz | and then in various situations, i have other endpoints that need to register |
| 01:42.55 | Kobaz | yeah |
| 01:43.01 | Kobaz | all from the same IP |
| 01:43.08 | Samot | Again.. |
| 01:43.15 | Samot | All my users come from Kamailio to Asterisk |
| 01:43.17 | Kobaz | so, as of right now, username,ip seems to work |
| 01:43.18 | Kobaz | yeah |
| 01:43.23 | Samot | I use username to match them. |
| 01:43.27 | Samot | Easy peasy |
| 01:43.30 | Samot | No problems. |
| 01:43.34 | Kobaz | And cheezy |
| 01:43.43 | Samot | I could also use match_header |
| 01:43.46 | Kobaz | and lemon squeezy |
| 01:43.48 | Samot | And send a custom header from Kamailio |
| 01:43.53 | Kobaz | Yeah |
| 01:43.59 | Kobaz | I'll play with that |
| 01:44.09 | Kobaz | Custom header sounds quite useful |
| 01:44.16 | *** join/#asterisk jayjo (jayjo@gateway/vpn/privateinternetaccess/jayjo) |
| 01:44.30 | Kobaz | But anyway, still really getting into the nitty gritty of pj |
| 01:44.44 | Kobaz | The usual when getting into something new |
| 01:44.54 | Samot | Or have you even looked at the ACLs in PJSIP? |
| 01:44.56 | Kobaz | (If only this was chan_sip, this would be so much easier) |
| 01:44.58 | Kobaz | not yet |
| 01:45.40 | Kobaz | does that affect matching? or would it just deny the session |
| 01:50.20 | Kobaz | But seriously... I am really liking the increased flexability of pj... especially multiple contacts/ips per endpoints, and better dns resolution |
| 01:50.39 | Kobaz | And I can look forward to not getting endpoints ips 'stuck' like in chan_sip |
| 01:51.06 | Kobaz | where it's cached somewhere and refuses to change even though host= has changed in the config.... you have to remove the peer, reload, and put it back... and then the ip updates |
| 01:55.19 | Kobaz | one thing i miss from chan_sip that pj needs, is 'sip show peers like' |
| 01:55.46 | Samot | Uh. |
| 01:56.05 | Samot | pjsip show endpoints/contacts/aors/identities |
| 01:56.21 | Kobaz | and where's the 'like' option |
| 01:56.29 | Kobaz | That'll go on my todo list |
| 01:56.35 | Samot | pjsip show endpoints like |
| 01:56.51 | Samot | pjsip show contacts like |
| 01:56.53 | Kobaz | oh |
| 01:56.56 | Kobaz | holy crap |
| 01:57.01 | Kobaz | it's not in the help/tab completion |
| 01:57.23 | Samot | Usage: pjsip show contacts [ like <pattern> ] |
| 01:57.23 | Samot | <PROTECTED> |
| 01:57.23 | Samot | <PROTECTED> |
| 01:57.24 | Kobaz | okay then, well... nice |
| 01:57.39 | Kobaz | pjsip show contacts <tab> .... nothing |
| 01:57.43 | Kobaz | maybe my help is messed up |
| 01:58.20 | Kobaz | oh man that makes life so much easier, yay |
| 01:59.37 | Kobaz | ah |
| 01:59.45 | Kobaz | i found it in core show help pjsip show contacts, etc |
| 01:59.54 | Kobaz | i don't normally use that since all the help is in the tab completion |
| 02:01.10 | Kobaz | like, if you type 'core show <tab>'... it's all there |
| 02:01.26 | Kobaz | and then 'core show channel' it'll give you help if you hit enter |
| 02:01.36 | Kobaz | do you get tab completion for pjsip show contacts li.<tab> |
| 02:02.07 | Kobaz | ? |
| 02:05.56 | Samot | No |
| 02:06.14 | Samot | You should report a bug |
| 02:06.32 | Kobaz | hehe |
| 02:12.00 | Kobaz | now i gotta figure out why rtp suddenly stops, but... that's for another night |
| 02:13.22 | Kobaz | oh, i think i know... i switched to vpn, need more localnets... okay cool |
| 02:19.47 | igcewieling | Starting Feb 8th Verizon will start sending stir/shaken headers on SIP TF handoff to their customer. |
| 02:20.14 | Kobaz | woah |
| 02:21.34 | igcewieling | and that is the entire useful content of their notification We never send out calls "from a toll free" on that service, so we don't have to actually do anything. |
| 02:22.31 | igcewieling | I'm looking into switching away from the service. We don't have all that many numbers and VZ wants us to take a 3 day training course SO WE CAN CHANGE THE IP THE SERVICE CONNECTS TO. |
| 02:23.14 | igcewieling | I'd be more impressed if they sent CallerID name info. |
| 02:23.33 | Kobaz | haha |
| 02:26.31 | igcewieling | Anyone around Neutral Tandem / Inteliquent ? |
| 02:26.41 | Samot | Ick |
| 02:26.50 | Kobaz | I just started working with Inteliquent |
| 02:26.56 | igcewieling | Anyone around using Neutral Tandem / Inteliquent ? |
| 02:27.22 | Kobaz | We're not onboarded yet... soooo. Not sure if that's helpful, heh |
| 02:27.23 | Samot | I used to use Inteliquent |
| 02:27.36 | igcewieling | Samot: how long ago? |
| 02:27.44 | Samot | I was not impressed |
| 02:27.50 | Samot | Last couple years |
| 02:27.52 | Kobaz | What were the issues? |
| 02:27.59 | igcewieling | more then 3 years ago? |
| 02:28.04 | Samot | No |
| 02:28.16 | igcewieling | What were you not impressed with? |
| 02:28.21 | Samot | Them |
| 02:28.27 | igcewieling | They would have to be pretty bad to be worse the VZ |
| 02:28.34 | Samot | They bought Broadvox |
| 02:28.44 | igcewieling | Ah, is that the part you dealt with? |
| 02:28.50 | Samot | Well Onvoy |
| 02:28.59 | igcewieling | they also own Onvoy which bought Vitelity. |
| 02:29.16 | Samot | Envoy bought Broadvox. It degraded |
| 02:29.23 | Samot | Onvoy |
| 02:29.32 | Kobaz | Samot: did you have termination issues? or what |
| 02:29.36 | Kobaz | tech support was slow? |
| 02:29.52 | Samot | Then Inteliquent bought onvoy and it went downhill |
| 02:30.00 | Samot | Everything was |
| 02:30.01 | igcewieling | Kobaz: what part if Intellequent are you dealing with? |
| 02:30.29 | Kobaz | sip ld-term/orig |
| 02:30.35 | Samot | Service was fine as long as you didnt need support |
| 02:30.48 | Kobaz | Are you being intentionally vague? |
| 02:30.50 | igcewieling | "Verizon SIP" for me is the former MCI Communications SIP service. |
| 02:31.05 | Samot | Plus both those companies are spam whores |
| 02:31.12 | igcewieling | Kobaz: I'd be interested in hearing about your experiences. |
| 02:31.16 | Kobaz | Do have an example? Like... Called support and waited on hold for 6 hours? |
| 02:31.36 | Samot | Like taking days to respond |
| 02:31.38 | Kobaz | igcewieling: yeah sure, i'll keep that in mind when we get test trunks |
| 02:31.41 | Kobaz | ah |
| 02:31.46 | Kobaz | Peerless has been like that |
| 02:31.52 | igcewieling | Kobaz: if you are not dealing with the Broadvox part of the company, you are not dealing with the same people as Samot. |
| 02:32.05 | Kobaz | We need a new trunk... oh just email support... why don't you have a portal where i can add my own trunk ips? |
| 02:32.08 | Samot | That would be that side |
| 02:32.18 | Samot | Term/Orig |
| 02:32.59 | Kobaz | And then they have to do a test window to bring up a new trunk ip. I can do my own testing, thank you |
| 02:33.02 | Samot | Both NT and Inteliquent have high volume's of spam calls |
| 02:33.40 | igcewieling | I'm interested in the "Neutral Tandem, Inc. provides voice, Internet protocol (IP) transit, and Ethernet telecommunications services primarily on a wholesale basis." part. |
| 02:33.51 | igcewieling | not the "cloud voice solutions" part. lol |
| 02:33.54 | Samot | Yeah |
| 02:34.04 | igcewieling | Samot: that is good to know. |
| 02:34.10 | Samot | So are the outbound campaign people |
| 02:34.16 | igcewieling | I dislike rewarding evilness. |
| 02:34.43 | Samot | People report a lot of their whiolesalers |
| 02:34.59 | Samot | NT moreso |
| 02:35.23 | Samot | Because they will collocate with them |
| 02:35.27 | Kobaz | okay, one last pj question and then i need to sleep.. other than force_rport/rewrite_contact/rtp_symmetric and seting proper local_net... why would rtp still be going out to an internal ip |
| 02:35.32 | Samot | Since NT has DCs |
| 02:35.36 | igcewieling | but,., but,, but they are supposed to offer g722 on their interconnects, and some of their customers accept it! |
| 02:35.46 | igcewieling | I'm mostly joking about that part. |
| 02:36.15 | Kobaz | [Feb 4 21:27:58] [1612492076.8] Sent RTP packet to 192.168.50.206:2264 (type 00, seq 022764, ts 002720, len 000160).... so not cool |
| 02:36.32 | igcewieling | I've even seen reports of people getting end-to-end on Intellequent <-> t-mobile calls. Not a reason to switch, but it sure would be nice if true. |
| 02:36.32 | Kobaz | 192.168.50.0/24 or anything like it is NOT in local_net |
| 02:37.04 | Kobaz | and i've done full restarts, etc |
| 02:37.17 | Samot | Is it remote? |
| 02:37.31 | Kobaz | the endpoint contact is on the wan. yup it's remote |
| 02:37.46 | Samot | Behind NAT |
| 02:37.48 | Samot | ? |
| 02:37.49 | Kobaz | yup |
| 02:38.06 | Samot | So that's a problem on that end |
| 02:38.08 | Kobaz | with force_rport and symmetric sip |
| 02:38.24 | Kobaz | sorry, sleeping... sym-rtp |
| 02:38.40 | Kobaz | this is on a B2BUA call |
| 02:38.51 | Kobaz | Oddly enough, media works fine when talking direct to Ast... ie Playback() |
| 02:38.55 | Kobaz | and Record() |
| 02:39.07 | Kobaz | ALl the SDP looks fine |
| 02:40.00 | Kobaz | Oh |
| 02:40.08 | Kobaz | Is this that Wait(1) Answer() stuff again |
| 02:40.10 | Kobaz | i wonder |
| 02:41.24 | Samot | Asterisk needs to receive RTP first |
| 02:41.28 | Kobaz | Yeah |
| 02:41.54 | Kobaz | which it does, for sure when doing Playback |
| 02:44.14 | Kobaz | ooooooh, it's trying a reinvite |
| 02:44.28 | Kobaz | I just noticed this |
| 02:44.34 | Kobaz | <PROTECTED> |
| 02:49.06 | Kobaz | fixed |
| 02:49.12 | Kobaz | direct_media=no |
| 02:55.36 | igcewieling | that options fixes MANY problems. |
| 02:56.21 | *** join/#asterisk tsal_ (~tsal@i59F5264E.versanet.de) |
| 03:15.47 | *** join/#asterisk cloud9 (~cloud9@198.29.32.168) |
| 03:18.15 | cloud9 | hey everyone, I got asterisk configured with WebRTC today. Working really well. Very cool. Am just using the sipml5 client for testing. I think between all my troubleshooting along the way I saw a thread where someone said the sipml5 library sucks and to use something else. |
| 03:18.29 | cloud9 | do you have any suggestions on which library is best? |
| 03:18.41 | cloud9 | sorry if that's outside the scope of this channel |
| 03:42.27 | *** join/#asterisk electronic_eel (~quassel@213.240.182.103) |
| 05:04.02 | *** join/#asterisk waldo323_ (~waldo323@d149-67-45-83.clv.wideopenwest.com) |
| 06:27.06 | *** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net) |
| 07:22.08 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda003836ac30b39637fa.dip0.t-ipconnect.de) |
| 07:52.28 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 07:58.10 | *** join/#asterisk GoldenBear (~gb@titan.pathogen.is) |
| 08:06.17 | *** join/#asterisk akp55 (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 08:07.35 | *** join/#asterisk elguero (~miguel323@c-73-238-205-3.hsd1.nh.comcast.net) |
| 08:24.28 | *** join/#asterisk post-factum (~post-fact@104.207.131.136) |
| 08:35.36 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 08:46.05 | *** join/#asterisk sinaowolabi (~Sina@169.159.74.124) |
| 10:29.54 | *** join/#asterisk ruied (~ruied@148.69.222.209) |
| 11:00.55 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda003836ac30b39637fa.dip0.t-ipconnect.de) |
| 11:05.17 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 11:25.48 | *** join/#asterisk ruied (~ruied@148.69.222.209) |
| 11:26.43 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 11:42.55 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 12:14.02 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 12:35.13 | *** join/#asterisk sbingner (~sam@phathack/sbingner) |
| 14:00.17 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda003836ac30b39637fa.dip0.t-ipconnect.de) |
| 14:17.14 | *** join/#asterisk paulgrmn (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 14:20.58 | *** join/#asterisk jkroon (~jkroon@165.16.203.99) |
| 14:25.04 | *** join/#asterisk irrgit (~ch33se@192.241.175.183) |
| 14:36.48 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 15:23.01 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-iayhpwuqmdsgzhno) |
| 15:23.01 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:33.43 | *** join/#asterisk ghoti (~paul@bras-base-ptldon0102w-grc-03-76-66-164-242.dsl.bell.ca) |
| 15:48.02 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-libbdksipltlaplg) |
| 15:48.02 | *** mode/#asterisk [+o bford] by ChanServ |
| 16:07.26 | *** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |
| 16:43.07 | Kobaz | weird |
| 16:43.21 | Kobaz | AMI ModuleCheck doesn't report Version for anything i've checked so far |
| 16:44.58 | file | version of what? |
| 16:45.08 | Kobaz | like chan_pjsip |
| 16:45.20 | file | modules aren't versioned |
| 16:45.24 | Kobaz | ah |
| 16:45.39 | Kobaz | Not sure why ModuleCheck returns blank Version: |
| 16:45.58 | Kobaz | well yeah i should have known that, but i thought maybe that was a new thing for versioning |
| 16:47.00 | Kobaz | wait, this might be the ami wrapper sticking in Version.. hang on |
| 16:47.20 | Kobaz | never mind :/ |
| 16:48.15 | *** join/#asterisk hfb (~hfb@45.152.182.240) |
| 16:53.39 | Kobaz | wait, tcpdump is showing it's received, wtf |
| 16:56.16 | Samot | Wut? |
| 16:56.29 | Kobaz | doing more debugging, trying to figure out where this is coming from |
| 16:57.00 | Samot | Where what is coming from? |
| 16:58.44 | Kobaz | hold on, heh |
| 17:00.31 | Kobaz | I think it's just differences in AMI for asterisk-16 |
| 17:00.41 | Kobaz | I need to rework something |
| 17:00.48 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 17:02.29 | *** join/#asterisk sinaowolabi (~Sina@41.190.3.75) |
| 17:03.30 | igcewieling | I don't have any TFs, but do TFs get as much spam/scam/telemarketing calls are normal TNs? |
| 17:03.52 | Kobaz | That's a good question |
| 17:04.20 | igcewieling | Verizon is enabling STIR/SHAKEN on their inbound SIP Toll Free service, which made me wonder about that. |
| 17:04.49 | igcewieling | It is really a problem, or are they just enabling it everywhere they can. |
| 17:05.18 | Samot | It's going to be a requirement by the summer |
| 17:05.24 | Samot | So yeah, it's going to be everywhere. |
| 17:05.36 | Kobaz | could be an infrastructure thing |
| 17:05.52 | Kobaz | it might have been easier to implement STIR/SHAKEN on their TF service first |
| 17:06.16 | igcewieling | I've never seen Verizon do anything "because it is a good idea" or "because it would be better for customers". |
| 17:06.26 | Kobaz | heh |
| 17:07.05 | igcewieling | Since Verizon bought XO, they can't even figure out what part of the company handles our troubletickets. |
| 17:07.55 | Samot | It's a FCC thing. |
| 17:08.08 | Samot | Trump signed it into law in 2019. |
| 17:08.16 | igcewieling | Samot: *nod* otherwise Verizon wouldn't be doing anything at all. |
| 17:08.24 | igcewieling | Wait, Trunk did something good? |
| 17:08.29 | igcewieling | ..er.. Trump. that is. |
| 17:08.34 | Samot | Yes. |
| 17:08.38 | Kobaz | woah |
| 17:08.45 | igcewieling | Mist have been a mistake. |
| 17:09.16 | Samot | Kari's Law, Ray Baum's Act Section 503, TRACED Act, STIR/SHAKEN. |
| 17:09.26 | Samot | All things signed into law during his term. |
| 17:40.10 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 17:43.00 | *** join/#asterisk sbingner (~sam@phathack/sbingner) |
| 17:49.26 | *** join/#asterisk sbingner (~sam@phathack/sbingner) |
| 18:06.34 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 18:41.56 | *** join/#asterisk sbingner (~sam@phathack/sbingner) |
| 19:25.28 | *** join/#asterisk akp55 (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 19:26.30 | *** join/#asterisk rpifan (~rpifan@p4fca2adc.dip0.t-ipconnect.de) |
| 19:32.30 | *** join/#asterisk hfb (~hfb@45.152.182.237) |
| 19:33.57 | *** join/#asterisk akp55 (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 20:05.34 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 20:09.38 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 20:55.20 | *** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood) |
| 20:57.19 | Kobaz | anyone know a whitepages api |
| 20:57.22 | Kobaz | doesn't have to be free |
| 21:02.18 | igcewieling | Nope, though I know of some CNAM services. |
| 21:04.45 | Kobaz | google-fu |
| 21:04.45 | Kobaz | https://ekata.com/developer/documentation/api-overview/ |
| 21:04.52 | Kobaz | they used to be whitepages.com |
| 21:06.52 | Kobaz | https://github.com/thehappydinoa/TruePeopleSearch |
| 21:28.53 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 21:32.40 | *** join/#asterisk ilius (~ilius@fw.cl.6six9.taskeasy.com) |
| 22:03.49 | ilius | Is there a way to get the statistics in "pjsip show channelstats" through AMI? I've been looking for a while, but I can't seem to find an answer. |
| 22:05.30 | *** join/#asterisk jkroon (~jkroon@165.16.203.101) |
| 22:15.20 | ilius | I want to get Observium or some other RRD to graph channel call quality with lost%, jitter, and rtt. Do any of you do something like that? |
| 22:38.52 | igcewieling | you can run cli commands from AMI |
| 22:52.47 | avb | one of my clients is complaning that some callers are getting 'probably scam' caller id :) |
| 22:53.13 | avb | i feel that yes, somebody already rely on the stir/shaken signatures |
| 22:53.38 | avb | i have a call with a stir/shaken consultant next week, lets see what he will say |
| 22:53.54 | avb | maybe indeed its time to start doing signatures |
| 22:54.34 | Samot | That's not how that works. |
| 22:54.50 | Samot | The carriers will be the ones that sign/validate |
| 22:55.27 | avb | well, it doesnt look like it. If you are a saas, you would need to sign for your clients |
| 22:55.37 | Samot | I don't need to with my LECs. |
| 22:55.42 | Samot | Since I'm already their customer. |
| 22:55.48 | Samot | And I get my DIDs from them. |
| 22:55.53 | Samot | I don't have to sign anything. |
| 22:56.07 | avb | maybe thats my problem |
| 22:56.15 | Samot | Are you a LEC? |
| 22:56.26 | avb | i order dids from one provider and dialout via different one |
| 22:56.27 | Samot | One that is peering with other LECs? |
| 22:56.42 | avb | nop |
| 22:56.53 | Samot | Well unless your providers are the actual LECs then I doubt you have much to do. |
| 22:57.10 | Samot | I have a few upstreams that are aggregates and they aren't requiring anything. |
| 22:57.15 | file | even if you were to sign, you would need to work that out with who the DIDs came from as to whether you can |
| 22:57.22 | Samot | ^^^^ |
| 22:57.41 | Samot | ATT and Verizon would be the ones doing that |
| 22:57.42 | avb | correct |
| 22:57.45 | Samot | With calls between them. |
| 22:58.19 | Samot | Now I have had some carriers start to prefix + |
| 22:58.23 | avb | problem is that didww im buying from still doesnt have nothing :) |
| 22:58.35 | Samot | So if I sent a 10 digit DID it came as +NXXNXXXXX |
| 22:58.48 | Samot | Which can cuase some to think it's a International number |
| 22:59.23 | Samot | The fact it says "Likely Scam" is a carrier thing. Not a STIR/SHAKEN thing. |
| 22:59.31 | Samot | They could be using other reputation tools. |
| 22:59.52 | Samot | STIR/SHAKEN is just another tool to enhance things. |
| 23:00.59 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 23:01.10 | avb | thats what Ive thought |
| 23:01.37 | avb | they see that did is owned by didww which is recently far from the most legit source ... |
| 23:01.54 | avb | maybe I just should port numbers somewhere out |
| 23:02.34 | avb | or become a LEC |
| 23:07.13 | avb | ive been trying to study more about obtaining a LEC status, as I understand I would need to get licenses in every state the company is working in? |
| 23:15.42 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 23:27.25 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-qfblsuzguenljxyg) |