Jump to content


Photo

Trunk Custom Headers


  • Please log in to reply
8 replies to this topic

#1 ahennis@voicespring.net

ahennis@voicespring.net

    Advanced Member

  • Members
  • PipPipPip
  • 183 posts

Posted 12 June 2017 - 03:15 PM

We are using custom headers in our trunks with the To header set up as follows.

"{domain-display}" <sip:{if clip true}anonymous@anonymous.invalid{fi clip true}{if disa true}{ext-ani}@{domain}{fi disa true}{from-ani}@{domain}>

We need to change the "{domain-display}" part based on the outbound ANI of the extension making the call or some other custom field that can be configured for each extension. I do not see any other variables we can use to replace {domain-display} with to make this happen.

 

We can't use {ext-display} because each extension has the users first and last name configured. It would be great if there was a field for each extension that could be populated with this a value that set a variable that could be used in the custom header, something like {ext-CNAM}. If an extension's CNAM field were set to "Company 1" the {ext-CNAM} variable would "Company 1" If a different extension on the same domain had its CNAM field set to "Company 2" the {ext-CNAM} variable would "Company 2"

 

In he custom header below if an extensions CNAM field is set, whatever value was in the field would be used otherwise processing will continue and the {domain-display} variable will be used.

{if ext-CNAM isset}"{ext-CNAM}" "{domain-display}" <sip:{if clip true}anonymous@anonymous.invalid{fi clip true}{if disa true}{ext-ani}@{domain}{fi disa true}{from-ani}@{domain}>



#2 Vodia PBX

Vodia PBX

    Advanced Member

  • Administrators
  • PipPipPip
  • 8,988 posts
  • Gender:Male

Posted 13 June 2017 - 10:00 AM

The first problem I see here is that you need to handle true and false cases. Otherwise you will end up with "Whatever" <sip:anonymous@anonymous.invalid123456@domain.com>

 

I think it makes sense to include the general purpose parameters that are available for extensions and also other accounts. We will call them {ext-param1-3} in the next build. Then you can put whatever you like in there and reference it when building the header. 



#3 ahennis@voicespring.net

ahennis@voicespring.net

    Advanced Member

  • Members
  • PipPipPip
  • 183 posts

Posted 13 June 2017 - 11:22 AM

I like this!!! To clarify will you be adding {ext-param1-3} to each extension or to the domain?

 

Edit: Perhaps a {dom-param1-3} would be useful as well.



#4 Vodia PBX

Vodia PBX

    Advanced Member

  • Administrators
  • PipPipPip
  • 8,988 posts
  • Gender:Male

Posted 13 June 2017 - 06:07 PM

Yes domain-paramX also makes sense!



#5 ahennis@voicespring.net

ahennis@voicespring.net

    Advanced Member

  • Members
  • PipPipPip
  • 183 posts

Posted 14 June 2017 - 06:09 PM

Yes domain-paramX also makes sense!

This is great to have the variables exposed. 

 

Will we also be able to do logical tests on the variables so we can change the header accordingly? For example using {if clip true} checks if the variable clip is true allowing us to return a different value if variable clip is set to true or false. Maybe something like {if ext-param1 isblank} or would it be as simple as {if ext-param1 ""} to make a string comparison with "" meaning a null value. I prefer the later as it is more flexible and allows not only checking if a variable is null but also if it is equal to a value. 

 

For example in the below statement we are checking if the ext-param1 field has been populated for an extension making a call. If the variable has a non blank value the system would return {ext-parm1} else it would return {domain-display}.

 

{if ext-param1 isblank}"{domain-display}""{ext-param1}" <sip:{if clip true}anonymous@anonymous.invalid{fi clip true}{if disa true}{ext-ani}@{domain}{fi disa true}{from-ani}@{domain}>



#6 Vodia PBX

Vodia PBX

    Advanced Member

  • Administrators
  • PipPipPip
  • 8,988 posts
  • Gender:Male

Posted 14 June 2017 - 07:36 PM

Yes you can combine that with conditional statements. If you want to compare with empty string, you can use {if ext-param1}, because the argument is missing and evaluate to "". There is actually no quoting there. 



#7 ahennis@voicespring.net

ahennis@voicespring.net

    Advanced Member

  • Members
  • PipPipPip
  • 183 posts

Posted 14 June 2017 - 09:21 PM

This is really great news!!! Thank you for considering my request and implementing it so quickly.

 

So is it possible we could see this in v58 or 59? My background is in programming so I understand that features can be delayed due to unforeseen factors.



#8 Vodia PBX

Vodia PBX

    Advanced Member

  • Administrators
  • PipPipPip
  • 8,988 posts
  • Gender:Male

Posted 15 June 2017 - 07:50 AM

It is included in all builds made after 6/14/17, also the latest 57.4 builds.



#9 ahennis@voicespring.net

ahennis@voicespring.net

    Advanced Member

  • Members
  • PipPipPip
  • 183 posts

Posted 15 June 2017 - 08:01 AM

Wow. That was fast. Thank you.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users