11 Jul
2007
11 Jul
'07
2:03 p.m.
Not sure. I think it is possible to turn it on but possibly ENUM's processing
latency may conflict with the failure_route located in the middle of transaction
processing and lead to some blocknig conditions, current TM maintainer, Andrei, will
certainly know better.
-jiri
At 16:41 11/07/2007, JF wrote:
Hi,
Is there any particular reason why enum_query cannot be called from
FAILURE_ROUTE?
Thanks,
JF
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
11 Jul
11 Jul
3:22 p.m.
New subject: [Serusers] enum_query from failure route
Jiri Kuthan wrote:
At 16:41 11/07/2007, JF wrote:
In short: There may be dragons there.
Anyways, I am not sure what you want to do, but you can usually skip the
problem by fixing the Request-URI and sprialing the call to yourself.
For instance, if call forwarding is what you're after, instead of
re-setting the target and just running processing again, you can just
stuff the URI you want to forward to in the Request-URI and call
t_relay() (don't forget the append_branch() if in a failure_route).
As a rule, keep failure and onreply routes simple. Actually, as a rule,
keep your config simple (Though simple does not necessarly mean short).
Regards,
Martin
Is there any particular reason why enum_query cannot be called from
FAILURE_ROUTE?
Not sure. I think it is possible to turn it on but possibly ENUM's processing
latency may conflict with the failure_route located in the middle of
transaction
processing and lead to some blocknig conditions, current TM
maintainer, Andrei, will
certainly know better.
3:49 p.m.
At 21:22 11/07/2007, Martin Hoffmann wrote:
Jiri Kuthan wrote:
Indeed: KISS applies to ser.cfg very well.
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
At 16:41 11/07/2007, JF wrote:
In short: There may be dragons there.
Anyways, I am not sure what you want to do, but you can usually skip the
problem by fixing the Request-URI and sprialing the call to yourself.
For instance, if call forwarding is what you're after, instead of
re-setting the target and just running processing again, you can just
stuff the URI you want to forward to in the Request-URI and call
t_relay() (don't forget the append_branch() if in a failure_route).
As a rule, keep failure and onreply routes simple. Actually, as a rule,
keep your config simple (Though simple does not necessarly mean short).
Is there any particular reason why enum_query cannot be called from
FAILURE_ROUTE?
Not sure. I think it is possible to turn it on but possibly ENUM's processing
latency may conflict with the failure_route located in the middle of
transaction
processing and lead to some blocknig conditions, current TM
maintainer, Andrei, will
certainly know better. 
12 Jul
12 Jul
6:08 a.m.
So, if I want to perform some less simple (e.g. enum_query) processing
on failed requests, I should loop the request through SER again and do
it in request route?
Not a very nice way to solve it. One more Record-Route, bigger
message... parsing the whole thing again.
Andrei, what exactly is the problem regarding long processing in
failure route, and what could be done to fix it?
Thanks,
JF
On 7/11/07, Jiri Kuthan <jiri(a)iptel.org> wrote:
At 21:22 11/07/2007, Martin Hoffmann wrote:
Jiri Kuthan wrote:
Indeed: KISS applies to ser.cfg very well.
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
At 16:41 11/07/2007, JF wrote:
In short: There may be dragons there.
Anyways, I am not sure what you want to do, but you can usually skip the
problem by fixing the Request-URI and sprialing the call to yourself.
For instance, if call forwarding is what you're after, instead of
re-setting the target and just running processing again, you can just
stuff the URI you want to forward to in the Request-URI and call
t_relay() (don't forget the append_branch() if in a failure_route).
As a rule, keep failure and onreply routes simple. Actually, as a rule,
keep your config simple (Though simple does not necessarly mean short).
Is there any particular reason why enum_query cannot be called from
FAILURE_ROUTE?
Not sure. I think it is possible to turn it on but possibly ENUM's processing
latency may conflict with the failure_route located in the middle of
transaction
processing and lead to some blocknig conditions, current TM
maintainer, Andrei, will
certainly know better. 
6:20 a.m.
Hi Jf,
There is one hack you can do.. wich would allow you do to a enumquery..
but, it´s not nice..
in failure_route, call a regular route. and in the reuglar route do a
enum_query. It works I think (not tried it) but it´s not nice.
this way, you will "skip" the extra record_rotue etc..
- Atle
* JF <jfkavaka(a)gmail.com> [070712 12:09]:
So, if I want to perform some less simple (e.g.
enum_query) processing
on failed requests, I should loop the request through SER again and do
it in request route?
Not a very nice way to solve it. One more Record-Route, bigger
message... parsing the whole thing again.
Andrei, what exactly is the problem regarding long processing in
failure route, and what could be done to fix it?
Thanks,
JF
On 7/11/07, Jiri Kuthan <jiri(a)iptel.org> wrote:
At 21:22 11/07/2007, Martin Hoffmann wrote:
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers Jiri Kuthan wrote:
Indeed: KISS applies to ser.cfg very well.
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
At 16:41 11/07/2007, JF wrote:
>
>Is there any particular reason why enum_query cannot be called from
>FAILURE_ROUTE?
Not sure. I think it is possible to turn it on but possibly ENUM's processing
latency may conflict with the failure_route located in the middle of
transaction
processing and lead to some blocknig conditions, current TM
maintainer, Andrei, will
certainly know better.
In short: There may be dragons there.
Anyways, I am not sure what you want to do, but you can usually skip the
problem by fixing the Request-URI and sprialing the call to yourself.
For instance, if call forwarding is what you're after, instead of
re-setting the target and just running processing again, you can just
stuff the URI you want to forward to in the Request-URI and call
t_relay() (don't forget the append_branch() if in a failure_route).
As a rule, keep failure and onreply routes simple. Actually, as a rule,
keep your config simple (Though simple does not necessarly mean short).
6:40 a.m.
Thanks.
The issue here is what kind of "Dragons" will be awaked in TM if I do that...
JF
On 7/12/07, Atle Samuelsen <clona(a)cyberhouse.no> wrote:
Hi Jf,
There is one hack you can do.. wich would allow you do to a enumquery..
but, it´s not nice..
in failure_route, call a regular route. and in the reuglar route do a
enum_query. It works I think (not tried it) but it´s not nice.
this way, you will "skip" the extra record_rotue etc..
- Atle
* JF <jfkavaka(a)gmail.com> [070712 12:09]:
So, if I want to perform some less simple (e.g.
enum_query) processing
on failed requests, I should loop the request through SER again and do
it in request route?
Not a very nice way to solve it. One more Record-Route, bigger
message... parsing the whole thing again.
Andrei, what exactly is the problem regarding long processing in
failure route, and what could be done to fix it?
Thanks,
JF
On 7/11/07, Jiri Kuthan <jiri(a)iptel.org> wrote:
At 21:22 11/07/2007, Martin Hoffmann wrote:
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers Jiri Kuthan wrote:
> At 16:41 11/07/2007, JF wrote:
> >
> >Is there any particular reason why enum_query cannot be called from
> >FAILURE_ROUTE?
>
> Not sure. I think it is possible to turn it on but possibly ENUM's processing
> latency may conflict with the failure_route located in the middle of
> transaction
> processing and lead to some blocknig conditions, current TM
> maintainer, Andrei, will
> certainly know better.
In short: There may be dragons there.
Anyways, I am not sure what you want to do, but you can usually skip the
problem by fixing the Request-URI and sprialing the call to yourself.
For instance, if call forwarding is what you're after, instead of
re-setting the target and just running processing again, you can just
stuff the URI you want to forward to in the Request-URI and call
t_relay() (don't forget the append_branch() if in a failure_route).
As a rule, keep failure and onreply routes simple. Actually, as a rule,
keep your config simple (Though simple does not necessarly mean short).
Indeed: KISS applies to ser.cfg very well.
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6:51 a.m.
Hi,
Well, I do this for years now (jumping right back into routes for
processing call-forward-busy etc.) without any problems. Should I care? :o)
Andreas
JF wrote:
Thanks.
The issue here is what kind of "Dragons" will be awaked in TM if I do
that...
JF
On 7/12/07, Atle Samuelsen <clona(a)cyberhouse.no> wrote:
Hi Jf,
There is one hack you can do.. wich would allow you do to a enumquery..
but, it´s not nice..
in failure_route, call a regular route. and in the reuglar route do a
enum_query. It works I think (not tried it) but it´s not nice.
this way, you will "skip" the extra record_rotue etc..
- Atle
* JF <jfkavaka(a)gmail.com> [070712 12:09]:
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users So, if I want to perform some less simple (e.g.
enum_query) processing
on failed requests, I should loop the request through SER again and do
it in request route?
Not a very nice way to solve it. One more Record-Route, bigger
message... parsing the whole thing again.
Andrei, what exactly is the problem regarding long processing in
failure route, and what could be done to fix it?
Thanks,
JF
On 7/11/07, Jiri Kuthan <jiri(a)iptel.org> wrote:
> At 21:22 11/07/2007, Martin Hoffmann wrote:
> >Jiri Kuthan wrote:
> >> At 16:41 11/07/2007, JF wrote:
> >> >
> >> >Is there any particular reason why enum_query cannot be called
from
> >> >FAILURE_ROUTE?
> >>
> >> Not sure. I think it is possible to turn it on but possibly
ENUM's processing
> >> latency may conflict with the
failure_route located in the
middle of
> >> transaction
> >> processing and lead to some blocknig conditions, current TM
> >> maintainer, Andrei, will
> >> certainly know better.
> >
> >In short: There may be dragons there.
> >
> >Anyways, I am not sure what you want to do, but you can usually
skip
the
> >problem by fixing the Request-URI and
sprialing the call to
yourself.
> >
> >For instance, if call forwarding is what you're after, instead of
> >re-setting the target and just running processing again, you can
just
> >stuff the URI you want to forward to in
the Request-URI and call
> >t_relay() (don't forget the append_branch() if in a failure_route).
> >
> >As a rule, keep failure and onreply routes simple. Actually, as a
rule,
> >keep your config simple (Though simple
does not necessarly mean
short).
Indeed: KISS applies to ser.cfg very well.
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7:23 a.m.
hi,
I´ve never used enum in this way, but, ive rather often done
failure_route -> route to do other stuff.. Like, It´s happend I need to
send a 181.. or other call-forwarding related stuff :) so, even while
it´s ugly,, it works ;)
- Atle
* Andreas Granig <agranig(a)sipwise.com> [070712 12:52]:
Hi,
Well, I do this for years now (jumping right back into routes for processing
call-forward-busy etc.) without any problems. Should I care? :o)
Andreas
JF wrote:
>Thanks.
>The issue here is what kind of "Dragons" will be awaked in TM if I do
that...
>JF
>On 7/12/07, Atle Samuelsen <clona(a)cyberhouse.no> wrote:
>>
>>Hi Jf,
>>
>>There is one hack you can do.. wich would allow you do to a enumquery..
>>but, it?s not nice..
>>
>>in failure_route, call a regular route. and in the reuglar route do a
>>enum_query. It works I think (not tried it) but it?s not nice.
>>
>>this way, you will "skip" the extra record_rotue etc..
>>- Atle
>>
>>* JF <jfkavaka(a)gmail.com> [070712 12:09]:
>>> So, if I want to perform some less simple (e.g. enum_query) processing
>>> on failed requests, I should loop the request through SER again and do
>>> it in request route?
>>>
>>> Not a very nice way to solve it. One more Record-Route, bigger
>>> message... parsing the whole thing again.
>>>
>>> Andrei, what exactly is the problem regarding long processing in
>>> failure route, and what could be done to fix it?
>>>
>>> Thanks,
>>> JF
>>>
>>> On 7/11/07, Jiri Kuthan <jiri(a)iptel.org> wrote:
>>> > At 21:22 11/07/2007, Martin Hoffmann wrote:
>>> > >Jiri Kuthan wrote:
>>> > >> At 16:41 11/07/2007, JF wrote:
>>> > >> >
>>> > >> >Is there any particular reason why enum_query cannot be
called from
>>> > >> >FAILURE_ROUTE?
>>> > >>
>>> > >> Not sure. I think it is possible to turn it on but possibly
ENUM's processing
>>> > >> latency may conflict with the failure_route located in the
middle of
>>> > >> transaction
>>> > >> processing and lead to some blocknig conditions, current TM
>>> > >> maintainer, Andrei, will
>>> > >> certainly know better.
>>> > >
>>> > >In short: There may be dragons there.
>>> > >
>>> > >Anyways, I am not sure what you want to do, but you can usually
skip the
>>> > >problem by fixing the Request-URI and sprialing the call to
yourself.
>>> > >
>>> > >For instance, if call forwarding is what you're after, instead
of
>>> > >re-setting the target and just running processing again, you can
just
>>> > >stuff the URI you want to forward to in the Request-URI and call
>>> > >t_relay() (don't forget the append_branch() if in a
failure_route).
>>> > >
>>> > >As a rule, keep failure and onreply routes simple. Actually, as a
rule,
>>> > >keep your config simple (Though simple does not necessarly mean
short).
>>> >
>>> > Indeed: KISS applies to ser.cfg very well.
>>> >
>>> > -jiri
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Jiri Kuthan http://iptel.org/~jiri/
>>> >
>>> > _______________________________________________
>>> > Serusers mailing list
>>> > Serusers(a)lists.iptel.org
>>> > http://lists.iptel.org/mailman/listinfo/serusers
>>> >
>>> _______________________________________________
>>> Serusers mailing list
>>> Serusers(a)lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>_______________________________________________
>Users mailing list
>Users(a)openser.org
>http://openser.org/cgi-bin/mailman/listinfo/users
7:34 a.m.
Hi Andreas,
as time the functions you are using are safe to be used in failure
route, there is no problem doing that...:)
JF, regarding the "enum" functions in failure_route: the reason for not
being officially allowed in failure route is because of how the newly
added branches are processed, so you might have problems when the enum
query returns more than one result. Otherwise is perfectly safe.
Just to give you an example of the branch issue: the enum_query()
function stores the first URI (from result) in RURI and the rest of them
as branches; so, if the query returns A, B and C (ordered by q), you
will have A in RURI and B + C in branches. As failure route does not use
RURI anymore, you need to do a append_branch() to move A also as a
branch -> you have B,C,A order now which conflicts with q.
if you do not have multiple results, you can safely do from
failure_route the enum_query() and append_branch().
regards,
bogdan
Andreas Granig wrote:
Hi,
Well, I do this for years now (jumping right back into routes for
processing call-forward-busy etc.) without any problems. Should I
care? :o)
Andreas
JF wrote:
> Thanks.
> The issue here is what kind of "Dragons" will be awaked in TM if I do
> that...
>
> JF
>
> On 7/12/07, Atle Samuelsen <clona(a)cyberhouse.no> wrote:
>>
>> Hi Jf,
>>
>> There is one hack you can do.. wich would allow you do to a enumquery..
>> but, it´s not nice..
>>
>> in failure_route, call a regular route. and in the reuglar route do a
>> enum_query. It works I think (not tried it) but it´s not nice.
>>
>> this way, you will "skip" the extra record_rotue etc..
>> - Atle
13 Jul
13 Jul
9:32 a.m.
On Jul 12, 2007 at 12:51, Andreas Granig <agranig(a)sipwise.com> wrote:
Hi,
Well, I do this for years now (jumping right back into routes for
processing call-forward-busy etc.) without any problems. Should I care? :o)
For enum no. However working arround ser's failoure route checks using
route() might burn you if you use some command which really is not
failure route safe. You could get a deadlock if you use a tm non failure
route safe command.
So, if you use it make sure everything you call from that route is
failure route safe.
Andrei
Andreas
JF wrote:
>Thanks.
>The issue here is what kind of "Dragons" will be awaked in TM if I do
>that...
>
>JF
>
>On 7/12/07, Atle Samuelsen <clona(a)cyberhouse.no> wrote:
>>
>>Hi Jf,
>>
>>There is one hack you can do.. wich would allow you do to a enumquery..
>>but, it?s not nice..
>>
>>in failure_route, call a regular route. and in the reuglar route do a
>>enum_query. It works I think (not tried it) but it?s not nice.
>>
>>this way, you will "skip" the extra record_rotue etc..
>>- Atle
>>
>>* JF <jfkavaka(a)gmail.com> [070712 12:09]:
>>> So, if I want to perform some less simple (e.g. enum_query) processing
>>> on failed requests, I should loop the request through SER again and do
>>> it in request route?
>>>
>>> Not a very nice way to solve it. One more Record-Route, bigger
>>> message... parsing the whole thing again.
>>>
>>> Andrei, what exactly is the problem regarding long processing in
>>> failure route, and what could be done to fix it?
>>>
>>> Thanks,
>>> JF
>>>
>>> On 7/11/07, Jiri Kuthan <jiri(a)iptel.org> wrote:
>>> > At 21:22 11/07/2007, Martin Hoffmann wrote:
>>> > >Jiri Kuthan wrote:
>>> > >> At 16:41 11/07/2007, JF wrote:
>>> > >> >
>>> > >> >Is there any particular reason why enum_query cannot be
called
>>from
>>> > >> >FAILURE_ROUTE?
>>> > >>
>>> > >> Not sure. I think it is possible to turn it on but possibly
>>ENUM's processing
>>> > >> latency may conflict with the failure_route located in the
>>middle of
>>> > >> transaction
>>> > >> processing and lead to some blocknig conditions, current TM
>>> > >> maintainer, Andrei, will
>>> > >> certainly know better.
>>> > >
>>> > >In short: There may be dragons there.
>>> > >
>>> > >Anyways, I am not sure what you want to do, but you can usually
>>skip the
>>> > >problem by fixing the Request-URI and sprialing the call to
>>yourself.
>>> > >
>>> > >For instance, if call forwarding is what you're after, instead
of
>>> > >re-setting the target and just running processing again, you can
>>just
>>> > >stuff the URI you want to forward to in the Request-URI and call
>>> > >t_relay() (don't forget the append_branch() if in a
failure_route).
>>> > >
>>> > >As a rule, keep failure and onreply routes simple. Actually, as a
>>rule,
>>> > >keep your config simple (Though simple does not necessarly mean
>>short).
>>> >
>>> > Indeed: KISS applies to ser.cfg very well.
>>> >
>>> > -jiri
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Jiri Kuthan http://iptel.org/~jiri/
>>> >
>>> > _______________________________________________
>>> > Serusers mailing list
>>> > Serusers(a)lists.iptel.org
>>> > http://lists.iptel.org/mailman/listinfo/serusers
>>> >
>>> _______________________________________________
>>> Serusers mailing list
>>> Serusers(a)lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>
>_______________________________________________
>Users mailing list
>Users(a)openser.org
>http://openser.org/cgi-bin/mailman/listinfo/users
9:27 a.m.
On Jul 12, 2007 at 11:08, JF <jfkavaka(a)gmail.com> wrote:
So, if I want to perform some less simple (e.g.
enum_query) processing
on failed requests, I should loop the request through SER again and do
it in request route?
Not a very nice way to solve it. One more Record-Route, bigger
message... parsing the whole thing again.
Andrei, what exactly is the problem regarding long processing in
failure route, and what could be done to fix it?
The problem is you block all the processes that handle messages
belonging to the same transaction. For example if you have some
retransmitted replies while you are in the failure route (for the same
transaction the retransmitted replies belong to), the processes
receiving the replies will be blocked untill the failure route ends.
That's why in general is better to spend as little time as possible in
the failure route.
A fix to this would mean trying to execute most of the failure route out
of the reply_lock. I think this would be possible, but requires a
very carefull analysis, lots of testing and more lockless code
(read as: it's not trivial and I'm not 100% sure we can do it
without breaking some sip scenarios). If it makes you feel better,
it's on my "secret" todo list, but with a low priority, so don't
expect any changes in the near future.
Andrei
Thanks,
JF
On 7/11/07, Jiri Kuthan <jiri(a)iptel.org> wrote:
>At 21:22 11/07/2007, Martin Hoffmann wrote:
>>Jiri Kuthan wrote:
>>> At 16:41 11/07/2007, JF wrote:
>>> >
>>> >Is there any particular reason why enum_query cannot be called from
>>> >FAILURE_ROUTE?
>>>
>>> Not sure. I think it is possible to turn it on but possibly ENUM's
>processing
>>> latency may conflict with the failure_route located in the middle of
>>> transaction
>>> processing and lead to some blocknig conditions, current TM
>>> maintainer, Andrei, will
>>> certainly know better.
>>
>>In short: There may be dragons there.
>>
>>Anyways, I am not sure what you want to do, but you can usually skip the
>>problem by fixing the Request-URI and sprialing the call to yourself.
>>
>>For instance, if call forwarding is what you're after, instead of
>>re-setting the target and just running processing again, you can just
>>stuff the URI you want to forward to in the Request-URI and call
>>t_relay() (don't forget the append_branch() if in a failure_route).
>>
>>As a rule, keep failure and onreply routes simple. Actually, as a rule,
>>keep your config simple (Though simple does not necessarly mean short).
>
>Indeed: KISS applies to ser.cfg very well.
>
>-jiri
>
>
>
>
>--
>Jiri Kuthan http://iptel.org/~jiri/
>
>_______________________________________________
>Serusers mailing list
>Serusers(a)lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>
12 Jul
12 Jul
2:38 p.m.
New subject: [Serusers] enum_query from failure route
Jiri Kuthan wrote:
LOL, when did you last see a non-trivial ser.cfg that conformed to KISS ;-)
g-)
As a rule, keep failure and onreply routes
simple. Actually, as a rule,
keep your config simple (Though simple does not necessarly mean short).
Indeed: KISS applies to ser.cfg very well.
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6:09 p.m.
New subject: [Serusers] enum_query from failure route
At 20:38 12/07/2007, Greger V. Teigre wrote:
Jiri Kuthan wrote:
LOL, when did you last see a non-trivial ser.cfg that conformed to KISS ;-)
I think current ser.cfg is actually both quite well structured (even though there is
a couple of things I would do even simpler) and still quite powerful.
-jiri
As a rule, keep failure and onreply routes simple. Actually, as a rule,
keep your config simple (Though simple does not necessarly mean short).
Indeed: KISS applies to ser.cfg very well.
g-)
--
Jiri Kuthan http://iptel.org/~jiri/
-jiri
--
Jiri Kuthan <http://iptel.org/~jiri/>http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
<mailto:Serusers@lists.iptel.org>Serusers@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6243
days inactive
6245
days old
12 comments
8 participants
participants (8)
-
Andreas Granig -
Andrei Pelinescu-Onciul -
Atle Samuelsen -
Bogdan-Andrei Iancu -
Greger V. Teigre -
JF -
Jiri Kuthan -
Martin Hoffmann