11 Nov
2004
11 Nov
'04
2:40 p.m.
Hi all,
I have to implement some advanced SIP services like
parallel/sequential ringing, of all registered sip and
PSTN phones.
To accomplish that I will need a "call server" that:
*)In the "parallel ringing service" will initiate all
the relavant calls and when some phone answers it will
cancel the rest of them.
*)In the "seqential ringing service" it will iniate
and cancel the calls sequential until some phone
answers ..
Can SER support that kind of functionality ?
Thanks
George
____________________________________________________________
Do You Yahoo!?
Αποκτήστε τη δωρεάν @yahoo.gr διεύθυνση σας στο http://www.otenet.gr
11 Nov
11 Nov
2:53 p.m.
Hello,
--- "G. P." <pagomen2001(a)yahoo.gr> wrote:
Hi all,
I have to implement some advanced SIP services like
parallel/sequential ringing, of all registered sip and
PSTN phones.
Can SER support that kind of functionality ?
You can use use the command append_branch() to implement parallel forking with SER. SER
doesn't
have any built-in mechanism to do sequential forking. However, you can use failure routes
in your
script to implement this feature.
Thanks
George
Regards,
=====
Girish Gopinath <gr_sh2003(a)yahoo.com>
__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
3:23 p.m.
Hi Girish, All
Sorry for asking such trivial question for you, but
in the seruser.pdf there is the following WARNING:
-----------------------------------------------------------------
ser’s request processing language allows to
make request decisions based on current URI. When
a request if forked to multiple destinations, only
the first branch’s URI is used as input for
script
processing. This might lead to unexpected results.
Whenever a URI resolves to multiple different
next-hop URIs, only the first is processed which may
result in handling not appropriate for the
other branch. For example, a URI might resolve to an
IP phone SIP address and PSTN gateway
SIP address. If the IP phone address is the first,
then script execution ignores the second branch.
If a script includes checking gateway address in
request URI, the checks never match. That might
result in ignoring of gateway admission control rules
or applying them unnecessarily to
non-gateway destinations.
------------------------------------------------------------
Doent this limination affect's the append_branch
workaround ?
____________________________________________________________
Do You Yahoo!?
Αποκτήστε τη δωρεάν @yahoo.gr διεύθυνση σας στο http://www.otenet.gr
I have to implement some advanced SIP services
like
parallel/sequential ringing, of all registered
sip
and
PSTN phones.
Can SER support that kind of functionality ?
You can use use the command append_branch() to
implement parallel forking with SER. SER doesn't
have any built-in mechanism to do sequential
forking. However, you can use failure routes in your
script to implement this feature.
4:05 p.m.
Hello,
--- "G. P." <pagomen2001(a)yahoo.gr> wrote:
Hi Girish, All
ser�s request processing language allows to
make request decisions based on current URI. When
a request if forked to multiple destinations, only
the first branch�s URI is used as input for
script
processing. This might lead to unexpected results.
We are using append_branch for parallel forking. Sometimes we fork calls to a maximum of 6
phones,
which includes IP phones as well as PSTN phones. We are dynamically adding branches, which
are
fetched from database. A module is written for this, and the script just relays the call.
For example, a URI might resolve to an
IP phone SIP address and PSTN gateway
SIP address. If the IP phone address is the first,
then script execution ignores the second branch.
Can anyone explain more about this? I am curious about this because we are forking calls
to both
PSTN gateways and IP phones. We got both PSTN and IP phones ringing at the same time and
haven't
faced any issues so far with this.
Doent this limination affect's the append_branch
workaround ?
AFAIK, append_branch is the only mechanism SER provides for parallel forking. As i said,
we
haven't faced any problems with this approach.
Regards,
=====
Girish Gopinath <gr_sh2003(a)yahoo.com>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
4:14 p.m.
Hello,
some serial forking can be implemented using the AVPOPS module with CVS
head SER version. Take a look at the example from
http://www.voice-system.ro/docs/avpops/ar01s08.html#ex_serial_forking
It may help you.
Salutari,
Ramona
Girish wrote:
Hello,
--- "G. P." <pagomen2001(a)yahoo.gr> wrote:
Hi all,
I have to implement some advanced SIP services like
parallel/sequential ringing, of all registered sip and
PSTN phones.
Can SER support that kind of functionality ?
You can use use the command append_branch() to implement parallel forking with SER. SER
doesn't
have any built-in mechanism to do sequential forking. However, you can use failure routes
in your
script to implement this feature.
Thanks
George
Regards,
=====
Girish Gopinath <gr_sh2003(a)yahoo.com>
__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
4:47 p.m.
Hello,
--- Elena Ramona Modroiu <ramona(a)voice-system.ro> wrote:
Hello,
some serial forking can be implemented using the AVPOPS module with CVS
head SER version. Take a look at the example from
http://www.voice-system.ro/docs/avpops/ar01s08.html#ex_serial_forking
It may help you.
Thanks for this info. I read only the serial forking section. A few questions...
From the code snippet given in the above mentioned doc,
i can see that the different addresses can
be set for forking initially. But it
again uses failure routes. We implement serial forking using
the existing failure routing mechanisms. Is there any advantage of using this new approach
apart
from setting the initial fork list? I guess it will make processing faster, in case the
records
are taken from DB or they are set using a custom-built module. Am i correct?
The document says that "There are no limitations", but in your mail you have
stated that "some
serial forking can be implemented". Can you explain that a bit?
Then, pardon me for my ignorance... but what is 'Salutari' ??
Salutari,
Ramona
Regards,
=====
Girish Gopinath <gr_sh2003(a)yahoo.com>
__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
12 Nov
12 Nov
12:55 a.m.
Hello,
comments inline ...
Girish wrote:
Hello,
--- Elena Ramona Modroiu <ramona(a)voice-system.ro> wrote:
I don't know how is your implementation, with this approach you can load
the destination addresses from database as well as specifying them
directly in config file or from a module. Otherwise the failure route
mechanism should be the same.
Hello,
some serial forking can be implemented using the AVPOPS module with CVS
head SER version. Take a look at the example from
http://www.voice-system.ro/docs/avpops/ar01s08.html#ex_serial_forking
It may help you.
Thanks for this info. I read only the serial forking section. A few questions...
From the code snippet given in the above mentioned doc, i can see that the different
addresses can
be set for forking initially. But it again uses failure routes. We implement serial
forking using
the existing failure routing mechanisms. Is there any advantage of using this new approach
apart
from setting the initial fork list?
I guess it will make processing faster, in case the
records
are taken from DB or they are set using a custom-built module. Am i correct?
yes, but as I said above you can set them also directly in the config file.
The document says that "There are no
limitations", but in your mail you have stated that "some serial forking can be
implemented". Can you explain that a bit?
The "no limitations" statement is about the way of setting or resetting
the destination set. I said "some serial forking" because, for example,
it doesn't support explicitly priorities for destination addresses (from
database the records are loaded in the order returned by a query after
the name).
Then, pardon me for my ignorance... but what is
'Salutari' ??
"salutari" is the Romanian word for "regards". You can check it
at
www.dictionare.com .
Salutari :),
Ramona
7:17 a.m.
Hello,
--- Elena Ramona Modroiu <ramona(a)voice-system.ro> wrote:
Yes, I understand.
The "no limitations" statement is about the way of setting or resetting
the destination set. I said "some serial forking" because, for example,
it doesn't support explicitly priorities for destination addresses (from
database the records are loaded in the order returned by a query after
the name).
OK. So if I have a module function 'set_fork_list()' as given in the doc, which
gets the fork list
may be with an sql query - something like this:
SELECT uri_to_branch, priority FROM fork_list WHERE actual_uri = 'abc(a)xyz.com'
ORDER BY priority
DESC;
Will that overcome the limitation? I assume that DESC is required since the AVP list is
arranged
backwards. Right?
I guess it will
make processing faster, in case the records
are taken from DB or they are set using a custom-built module. Am i correct?
yes, but as I said above you can set them also directly in the config file.
The document says that "There are no
limitations", but in your mail you have stated that "some
serial forking
can be implemented". Can you explain that a bit?
"salutari" is the Romanian word for
"regards". You can check it at
www.dictionare.com .
Thanks for this.
Salutari :),
Ramona
Thanks & Regards,
=====
Girish Gopinath <gr_sh2003(a)yahoo.com>
__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
7:47 p.m.
Hello,
On Thu, Nov 11, 2004 at 09:17:25PM -0800, Girish wrote:
Hello,
--- Elena Ramona Modroiu <ramona(a)voice-system.ro> wrote:
The "no limitations" statement is about the way of setting or resetting
the destination set. I said "some serial forking" because, for example,
it doesn't support explicitly priorities for destination addresses (from
database the records are loaded in the order returned by a query after
the name).
OK. So if I have a module function 'set_fork_list()' as given in the doc, which
gets the fork list
may be with an sql query - something like this:
SELECT uri_to_branch, priority FROM fork_list WHERE actual_uri = 'abc(a)xyz.com'
ORDER BY priority
DESC;
Will that overcome the limitation? I assume that DESC is required since the AVP list is
arranged
backwards. Right?
It might be better ASC, you have to add first the one with the lowest
priority.
Salutari,
Ramona
The document says that "There are no
limitations", but in your mail you have stated that "some
serial forking
can be implemented". Can you explain that a bit?
"salutari" is the Romanian word for "regards". You can check it at
www.dictionare.com .
8:58 p.m.
Parallel forking used to work in older versions (<= 0.8.12) very well by
using a one to many alias.
serctl add alias 122 user1(a)dom.com
serctl add alias 122 user2(a)dom.com
serctl add alias 122 user3(a)dom.com
serctl add alias 122 user4(a)dom.com
serctl add alias 122 user5(a)dom.com
Calling alias 122 would call user[1-5]. This support has been regressed
in head though, I think for design sanity reasons. I still have not
gotten around to coming up with an alternate solution...
-Jev
G. P. wrote:
Hi all,
I have to implement some advanced SIP services like
parallel/sequential ringing, of all registered sip and
PSTN phones.
To accomplish that I will need a "call server" that:
*)In the "parallel ringing service" will initiate all
the relavant calls and when some phone answers it will
cancel the rest of them.
*)In the "seqential ringing service" it will iniate
and cancel the calls sequential until some phone
answers ..
Can SER support that kind of functionality ?
Thanks
George
____________________________________________________________
Do You Yahoo!?
Αποκτήστε τη δωρεάν @yahoo.gr διεύθυνση σας στο http://www.otenet.gr
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7316
days inactive
7317
days old
9 comments
4 participants
participants (4)
-
Elena Ramona Modroiu -
G. P. -
Girish -
Jev