Jump to content

lazedo

2600Hz Employees
  • Posts

    326
  • Joined

  • Days Won

    1

2 Followers

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @FASTDEVICE can you provide a real use case and trackable numbers from/to (you can send the number in private) ? 1) when you use the /v2/.../sms api you can send messages with more than 160 characters, we do segmentation or use udh depending on the number provider 2) when your webhook is called (after a text is received for the number), you should receive the ALL text, again, provider may use udh or segmentation. in the case of segmentation we reassemble before delivering to webhook or device thanks
  2. not sure what that means. depends on your carrier and how you connect to your carrier
  3. that depends mostly from the providers & apps & gateways. Our implementation does segmentation & reassembly https://en.wikipedia.org/wiki/Segmentation_and_reassembly
  4. you don't need to provide the "host" if you're using aws. the "host" is used for s3 compatible servers like minio or when cnames are used.
  5. @Joshua did you check this ?
  6. Hi Dhruv, the SMS and XMPP settings are useless, all you have to do is to enable presence. note however that, a message will be delivered to all registered devices until one replies with success. for example, if you have 3 (A,B,C) registered devices belonging to a user with a sms enabled number, an incoming message to that number will be delivered to the A device, if it fails, its delivered to B device , if it fails its delivered to C device, if it fails its dropped. if device A is a yealink you may have receive the message (tho you expected it in bria). so, i would recommend to 1) create 2 new users 2) assigned the Bria devices to those users 3) move the sms enabled numbers to those users, or get new ones 4) try it out i have successfully worked with bria & linphone & yealink
  7. the host field is used for custom s3 providers, you shouldn't be doing that.
  8. https is supported oob. you should look with your provider
  9. what portal are you expecting the user to logon ? you tipically have a landing page for auth like in https://monster.sandbox.2600hz.com/ where the user can login with his kazoo credentials or with a oauth provider. depending on the level of integration you want, you may redirect immediately from the landing page to your oauth login url. if you have your own identity provider oauth app, then you need to configure it as a provider (see google & office365 docs in system_auth database) and create an application to reference that provider. do you have discovery url for your oauth provider ? any documentation for it ?
  10. no, i meant that to use 2+ rabbitmq servers in one zone (not failover) , you need to cluster them
  11. this is only valid if you cluster rabbitmq servers on the same zone. as for the number of erlang vm's (kazoo), freeswitch servers, kamailio servers, there's no limit on kazoo imposing that.
  12. you can set 1 way or 2 way in the callflow
  13. @esoare every kamailio box is aware of fast-pickup. In 4.0 and previous, fast-pickup cookie was created in omnipresence and notify was sent with a direct queue to targeted kamailio boxes. as of 4.1, notify is broadcasted (via amqp) and kamailio boxes will check if they have subscribers for the presence-id and will notify the phones if they have. The fast -pickup cookie is created with known values that can be converted by every kamailio box.
  14. this is not correct as of 4.1
  15. if you set "record everything", that is the expected behaviour.
×
×
  • Create New...