Documentation/Explanation of configuration


Expected behavior:

  • Know what the marked form fields are used for. Especially the “User assignment to Sipgate users” section. What does it do? The sentence below does not make a lot of sense.

Actual behavior:

  • Not knowing what the two marked forms are for.

Steps to reproduce the behavior:

  • Install Zammad, go to the configuration.
  • Have configured (Inbound/Outbound)
  • Entering the sipgate user mail and the corresponding zammad agent mail does not do anything when a call comes in and is shown in zammad.


Sorry but I guess that “API-User and API-Password” should be self explanationary?
That’s the API credentials from you’ll need to provide so that Zammad is able to pull and put information from and to sipgate.

To the second part… I totally agree, that’s not a helping text… :frowning:
The user assignment simply is an mapping between sipgate users (extensions) and your Zammad agents.

This will enable Zammad to know which sipgate extension belongs to which agent. As soon as an known agent picks up a call, a new tab “inbound call” will open. Also, for all agents (as long as the phone is ringing) Zammad will show additional call information.

This will look like so:

I hope this is a bit clearer.
I’ll note myself to adjust the sipgate wiki as we didn’t update the docs yet, sorry about that.

Edit: I just created an issue to adjust the description texts - thank you very much for the heads up!
You can find the issue here:

I don’t see a difference in the call info view (the little box that appears when a call comes in) and in the caller log.
Also, no screen appears where i can create a new ticket when i take the call.
And there is no additional call information shown.

What i tried

  1. I did map my sipgate user to my zammad user in zammad’s by entering both emails (they are the same) and clicking ‘add’.
  2. I did call the agent’s number.
  3. The inbound call for that test-customer is shown.
  4. I Accept the call as the agent.
  5. The inbound-call-info disappears
  6. Nothing else pops up and no ticket view opens.

Did try the same after removing the sipgate-zammad-user-association => No difference in information shown in the inbound-call-info box or in the caller log.

Also tried mapping the SIP-ID to the zammad account.

Also, when clicking the ‘add’-button the first time in the user association, the entry is not created and the form fields are emptied.

Can you please tail your production.log in a temporary log while trying this again and share that log part?
It should work ™, so right now I can’t verify the issue :frowning:

I will asap. But before, i need to know which field is meant by SIPGATE/USER in the “User Assignment to Sipgate users” section:

  • fullUserId (e.g. 1234567a1)
  • user (e.g. Mister X) or
  • userId (e.g. w10)


This should be stated in the documentation and on the configuration page, too (and not only in the form input’s placeholder :yum: ).

If it is the userId, this would be problematic, as in the sipgate web UI there is no way of finding it out. I only got mine from the Developer Console Webhook Debug Log. This way one had to make a test call for each agent just to find out the userId. It would be easier to use the SIP-ID/fullUserId

I managed to get it to work.

The thing is - as i wrote in my previous reply - that i only got my userId from the developer console log after doing a test call.
Also, as i am seeing right now, it is also visible in the browser url when logged into one’s sipgate account.

This is not intuitive. Is it feasible to use the SIP-ID which would be the full user id truncated by the user id in future?

Sorry, I can’t provide further information if this is going to change or not.

@martini might be able to provide further information on how we currently seem to use sipgate UIDs (which I also think is unpexpected, when talking about sipgate-users. I’d expect the extension ID, which is kinda a username in my opinion)

Thank you for your quick assistance and the information you provided.

I suggested this, because it seems easier. Despite this, a sipgate admin can impersonate it’s agents and check the URI part with the userId and communicate it to the Zammad admin.

Also - i think changing this, to use something different (e.g. the SIP-ID) as a replacement for the userId would break existing installtions for users.

Maybe this thread might help others, stumbling over this issue.

1 Like

Sorry but I guess that “API-User and API-Password” should be self explanationary?
That’s the API credentials from you’ll need to provide so that Zammad is able to pull and put information from and to sipgate.

It should be self-explanatory but I tried everything I could find on the sipgate basic and web interface but nor the SIP login details neither something else I could find there. I even tried creating an application on their site, which wasn’t helpful as this is related to OAuth. So which details do I have to provide there and where exactly can I find them?

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.