Jump to content
KAZOOcon: hackathon signup and details here! ×

Darren Schreiber

Administrators
  • Posts

    1,202
  • Joined

  • Days Won

    27

Posts posted by Darren Schreiber

  1. Something to keep in mind... "Comcast" is really American Cable Systems. Which became Comcast in 1969. Then they bought Group W Cable in 1986. Then Storer Communications in 1985. Then it bought Maclean-Hunter's US division. 

    Then it started rolling out internet via the "@Home" network (anyone remember this?). This was partially via a company named "Excite", who went bankrupt, and Comcast bought their assets.

    Then they bought Prime Communications. and some VeriSign stock. and MediaOne (via a trade with AT&T). Also they bought AT&T Broadband. and Patriot Media in 2007.

    shall I go on?

    If you think during each of these mergers, they walked in and within 90 days ripped & replaced all the customer equipment, billing systems, routers, switches, fiber cables, etc. with a nice unified system... Wellllll hehehe ummm 


    In reality they're JUST getting to that point now with just their portal and ticketing systems (within the past couple years). They still operate the territories somewhat separately.

    Why am I saying all this? My guess is they have different equipment and programming in each region.

    Hence the weird, inconsistent network results.

    There is no "Comcast" there's just "merger mess with a nice name."
  2. No problem, if it is Comcast you should be experiencing it on all phones, unless it's a local LAN issue.

    There are some other things to try. You indeed could try switching codecs. Believe it or not sometimes audio sounds funky when it gets "upsampled" to HD but is actually a regular PSTN call on PCMU.
  3. Switching to TCP just changes signaling. If you were using UDP, it didn't work well, you switched to TCP and your "signaling" issues went away but you now have audio issues, you've actually proven that the internet or network IS the problem.

    TCP covers up connectivity problems, which is why we don't like it. UDP has no error correction built-in, so errors and unreliable links become problematic. TCP corrects errors on it's own, but you can't use it for audio because it adds delay. So audio still remains UDP. Thus, if TCP "fixes" your original issue, then really TCP likely just "covered up" your original issue and now UDP is still used for audio but is still having the same issue.
  4. Sorry, I was referring to the original request (see title of this thread). I'm not sure why you actually added eavesdrop here, might I suggest opening a separate thread for that request? It is not the same or really related to call screening from a technical perspective and should exist as a different request.

    My response was in regards to call screening.
  5. We've got a pretty healthy list of new features coming out which will probably consume most of our focus for at least the next month or two. We can consider this after that but we only have so many staff members to work on this.

    If you'd like to contribute this somehow you are welcome to in the meantime. Otherwise, perhaps file a feature request in the tickets.2600hz.com site? Then we'll groom that and look for new features at a later date.
  6. http://www.fiercetelecom.com/telecom/verizon-seeks-fcc-permission-to-shutter-more-legacy-ss7-voice-s...

    "
    1. Legacy SS7 elements: Verizon wants to be relieved of an FCC requirement to upgrade and replace legacy SS7 network elements in order to generate and pass the charge number (CN) when it differs from calling party number (CPN)."
    Which relates to both billing, Caller ID and ANI passing actually. Spawned by the "Truth in Caller ID" act. Google away :)
  7. LOL, isn't it though? The previous FCC chairman had a mandate that all carriers be able to start passing reliable Caller ID info between each other for this very reason, so spoofing stops. But the new FCC chairman is likely to nix that requirement now (Verizon and one other company, forget who, just re-petitioned to try to remove the requirement to upgrade their equipment to support this feature).

    So it will stay messy for a while.
  8. There are limits in any system on packet sizes and memory buffers. Engineers sometimes code things assuming they'll only ever get so big.

    Sometimes they'll pick a number like 1024 for the number of bytes that can exist in a string.

    Well, if you call a phone in our system, potentially it creates this string:
    bridge {caller_id=X,caller_id_name=Y}sofia/profile/sipint...;some_setting=a&some_setting=b

    OK, that's for one person. Now you have two people, well, it doubles in length:
    bridge {caller_id=X,caller_id_name=Y}sofia/profile/sipint...;some_setting=a&some_setting=b,
    {caller_id=X,caller_id_name=Y}sofia/profile/sipint...;some_setting=a&some_setting=b

    Well, when you get to 100, maybe you now exceed 1024 characters and something breaks.

    It's impossible to unravel every single line of code an engineer has ever written to see if they have made an assumption like this basically, hence why they become "bugs" :-) It's something an engineer never thought someone would do, but then someone does it.
  9. There is a GUI component for this and I'm debating having a Monster app for this. The dream was to allow people to subscribe to a public list of telemarketers, too, and download updates to it regularly to block bogus Caller IDs.

    That idea, however, turns out to be flawed. A lot of telemarketers are now spoofing their Caller ID with numbers they don't own that belong to other people. Which means we'd accidentally block some poor soul out there. Kind of a big problem if you ask me but not a good solution to it.
  10. Our very first customer in NYC is still with us. They have 32 phones on a ring group when you call the main number. It was hell on earth to get that working in 2008 hehe - the bridge string in FreeSWITCH was HUGE because there were different settings on each phone. But we eventually figured it out.

    Since then, it's worked pretty flawlessly. And a lot of other people do it, too.

    Of course, I think 50 is probably the largest group I know of. If you put 100 or 200 in a group we'll probably hit some new problem we haven't seen before.

    Sooo I'd call 50 the max I know of :-) but larger might work OK too.
×
×
  • Create New...