I'm just throwing this out there, but what if the pattern (we'll use that
name for now, although I'm not sure I like it as the final name) could
itself define new types. Then, if you provided a standard config (i.e.,
the sample config) which defined some set of standard types (phone,
itsp/trunk,
On Sun, Sep 21, 2014 at 11:07 AM, Brad Watkins marqui...@gmail.com wrote:
I'm just throwing this out there, but what if the pattern (we'll use
that name for now, although I'm not sure I like it as the final name) could
itself define new types. Then, if you provided a standard config (i.e.,
George Joseph wrote:
snip
My proposal is to allow registration/server_uri to be specified as a
comma separated list or to be specified multiple times just like
aor/contact and identify/match. This would allow us to manage only 1
registration section in the same manner as aor and identify. A
On Sat, Sep 20, 2014 at 10:33 AM, Joshua Colp jc...@digium.com wrote:
George Joseph wrote:
snip
My proposal is to allow registration/server_uri to be specified as a
comma separated list or to be specified multiple times just like
aor/contact and identify/match. This would allow us to
George Joseph wrote:
snip
5. The idea of higher level concept configuration has been thrown
around as something to make this easier. I personally think this
sort of thing belongs there. A type=trunk, itsp, phone, etc. Lower
level blocks remain the same and additional logic on
On Sat, Sep 20, 2014 at 11:21 AM, Joshua Colp jc...@digium.com wrote:
George Joseph wrote:
snip
5. The idea of higher level concept configuration has been thrown
around as something to make this easier. I personally think this
sort of thing belongs there. A type=trunk, itsp,
On Sat, Sep 20, 2014 at 12:06 PM, George Joseph george.jos...@fairview5.com
wrote:
On Sat, Sep 20, 2014 at 11:21 AM, Joshua Colp jc...@digium.com wrote:
George Joseph wrote:
snip
5. The idea of higher level concept configuration has been thrown
around as something to make this
George Joseph wrote:
snip
Or separate objects from a config file perspective but implemented in
pjsip_configuration with endpoint.
Completely separate. Mixing the two defeats the purpose of having a
clear boundary.
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis
On Sat, Sep 20, 2014 at 1:10 PM, Joshua Colp jc...@digium.com wrote:
George Joseph wrote:
snip
Or separate objects from a config file perspective but implemented in
pjsip_configuration with endpoint.
Completely separate. Mixing the two defeats the purpose of having a clear
boundary.
George Joseph wrote:
On Sat, Sep 20, 2014 at 1:10 PM, Joshua Colp jc...@digium.com
mailto:jc...@digium.com wrote:
George Joseph wrote:
snip
Or separate objects from a config file perspective but
implemented in
pjsip_configuration with endpoint.
On Sat, Sep 20, 2014 at 1:35 PM, Joshua Colp jc...@digium.com wrote:
George Joseph wrote:
On Sat, Sep 20, 2014 at 1:10 PM, Joshua Colp jc...@digium.com
mailto:jc...@digium.com wrote:
George Joseph wrote:
snip
Or separate objects from a config file perspective but
George Joseph wrote:
snip
I was thinking that we probably don't want to create hard coded objects
called trunk, user, etc. Instead let the user define the patterns
that suit them.
It would be much more approachable for a user with specific types. These
types result in underlying endpoint,
On Sat, Sep 20, 2014 at 2:20 PM, Joshua Colp jc...@digium.com wrote:
George Joseph wrote:
snip
I was thinking that we probably don't want to create hard coded objects
called trunk, user, etc. Instead let the user define the patterns
that suit them.
It would be much more approachable
George Joseph wrote:
On Sat, Sep 20, 2014 at 2:20 PM, Joshua Colp jc...@digium.com
mailto:jc...@digium.com wrote:
George Joseph wrote:
snip
I was thinking that we probably don't want to create hard coded
objects
called trunk, user, etc. Instead let the user
On Sat, Sep 20, 2014 at 3:13 PM, Joshua Colp jc...@digium.com wrote:
George Joseph wrote:
On Sat, Sep 20, 2014 at 2:20 PM, Joshua Colp jc...@digium.com
mailto:jc...@digium.com wrote:
George Joseph wrote:
snip
I was thinking that we probably don't want to create hard
George Joseph wrote:
snip
How about we use the pattern approach but compile in patterns for trunk
and user. There are lots of minor differences between ITSPs and phones
and I just worry that in the quest to create something for everyone we
create something that's useful to no one.
If it
On Sat, Sep 20, 2014 at 4:44 PM, Joshua Colp jc...@digium.com wrote:
George Joseph wrote:
snip
How about we use the pattern approach but compile in patterns for trunk
and user. There are lots of minor differences between ITSPs and phones
and I just worry that in the quest to create
In the process of getting my GUI and real customers up on PJSIP I've come
across a few things that could work better for me. One of them is the
configuration process for ITSP trunks, specifically those that require
registration and have more than 1 server.
In a simple single-server scenario, a
18 matches
Mail list logo
