Yes, though of course you would have to correlate the
calls (most likely
by Call-ID) and integrate all this.
On March 14, 2017 2:46:27 AM EDT, przeqpiciel <przeqpiciel(a)gmail.com>
wrote:
So, I can use Kamailio as SBC/Load
balancer/registrar, Asterisk as IVR
and
application server, and rtpproxy as media relay and recorder ?
2017-03-14 7:44 GMT+01:00 Alex Balashov <abalashov(a)evaristesys.com>om>:
It can record, as can a number of other media
relays.
On March 14, 2017 2:43:15 AM EDT, przeqpiciel <przeqpiciel(a)gmail.com>
wrote:
>>> WHy not installing rtpproxy and proxying all
>Because I would like to record some calls and I dont know RTPProxy's
>features, maybe it could record ?
>
>2017-03-14 5:14 GMT+01:00 anfecora <anfecora(a)gmail.com>om>:
>
>> WHy not installing rtpproxy and proxying all rtp to the inside
uase
>> kamailio to load balance them, it will
be transparent on the
inside
>perhaps
>> a cleaner solution?
>>
>> On Mon, Mar 13, 2017 at 3:21 PM, Kjeld Flarup <kfc(a)viptel.dk>
wrote:
>>
>>> As I recall it is sequential, but not from the start everytime,
it
>is
>>> incrementing all the time.
>>>
>>> If You are running three servers, then with a 100% identical
load,
>one
>>> would expect an average of 2 failing attempts per call.
>>>
>>> The reality I see is however often very different RTP ports, most
>likely
>>> because load isn't 100% identical.
>>>
>>>
>>> Med venlig hilsen / Best regards
>>> Kjeld Flarup (Christensen) M.Sc E.E, Teknisk chef
>>> Viptel ApS, Hammershusvej 16C, DK-7400 Herning
>>> Telefon: +45 46949949, Telefax: +45 46949950,
http://viptel.dk
>>>
>>> On 03/13/2017 11:05 PM, Alex Balashov wrote:
>>>
>>>> Well, indeed, but a sequential scan of many consecutive ports
like
>this
>>>> from the bottom of the same range can be quite a latent
operation.
>So at
>>>> the very least the allocation strategy would benefit from being
>random.
>>>> Does Asterisk take that approach?
>>>>
>>>> On March 13, 2017 6:04:06 PM EDT, Kjeld Flarup <kfc(a)viptel.dk>
>wrote:
>>>>
>>>>> No there is no such thing as magic.
>>>>>
>>>>> The most obvious way to implement the RTP port handling, is to
>first
>>>>> open the next UDP port in the OS, and then report that back in
the
>>>>> Invite/200Ok. If the port
cannot be opened, then simply try the
>next in
>>>>>
>>>>> line.
>>>>>
>>>>>
>>>>> Med venlig hilsen / Best regards
>>>>> Kjeld Flarup (Christensen) M.Sc E.E, Teknisk chef
>>>>> Viptel ApS, Hammershusvej 16C, DK-7400 Herning
>>>>> Telefon: +45 46949949, Telefax: +45 46949950,
http://viptel.dk
>>>>>
>>>>> On 03/13/2017 01:52 PM, przeqpiciel wrote:
>>>>>
>>>>>> Maybe there is an magic device? I know that if we have an
>asterisk,
>>>>>> that become to us with default configuration of rtp ports sets
to
>>>>>> 10000_20000. And each
call choose the one port fron that
range.
>So if
>>>>>> we have several asterisks with default configuratiin of rtp,
>there is
>>>>>> possibilities to have 2 concurent calls each through another
>asterisk
>>>>>> instance with this same rtp port. Am i right?
>>>>>>
>>>>>> So mqybe this magic device could see source IP address and
route
>rtp
>>>>>> to correct adterisk?
>>>>>>
>>>>>> 13.03.2017 7:15 AM "Alex Balashov"
<abalashov(a)evaristesys.com
>>>>>> <mailto:abalashov@evaristesys.com>> napisał(a):
>>>>>>
>>>>>> On Mon, Mar 13, 2017 at 07:08:09AM +0100, Kjeld Flarup
>wrote:
>>>>>>
>>>>>> > We run multiple Asterisk instances since 1.4 and
never
>>>>>> configured RTP ports.
>>>>>> >
>>>>>> > More challenging issues are the Asterisk DB, and the
>Asteisk
>>>>>>
>>>>> home.
>>>>>
>>>>>> You may not have enough calls for RTP port collisions to
>become
>>>>>>
>>>>> an
>>>>>
>>>>>> issue. Otherwise, I'm not sure how you're avoiding
it,
since
>>>>>>
>>>>> Asterisk
>>>>>
>>>>>> isn't aware of which ports from within the range are in
use.
>>>>>>
>>>>>> --
>>>>>> Alex Balashov | Principal | Evariste Systems LLC
>>>>>>
>>>>>> Tel: +1-706-510-6800 <tel:%2B1-706-510-6800> /
>+1-800-250-5920
>>>>>> <tel:%2B1-800-250-5920> (toll-free)
>>>>>> Web:
http://www.evaristesys.com/,
http://www.csrpswitch.com/
>>>>>>
>>>>>> _______________________________________________
>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) -
sr-users
>>>>>>
>>>>> mailing
>>>>>
>>>>>> list
>>>>>> sr-users(a)lists.sip-router.org
>>>>>>
>>>>> <mailto:sr-users@lists.sip-router.org>
>>>>>
>>>>>>
>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>
><http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>mailing
>>>>>>
>>>>> list
>>>>>
>>>>>> sr-users(a)lists.sip-router.org
>>>>>>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>
>>>>>
>>>> -- Alex
>>>>
>>>> --
>>>> Principal, Evariste Systems LLC (
www.evaristesys.com)
>>>>
>>>> Sent from my Google Nexus.
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing
>list
>>>> sr-users(a)lists.sip-router.org
>>>>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing
list
>> sr-users(a)lists.sip-router.org
>>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
> sr-users(a)lists.sip-router.org
>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
-- Alex
--
Principal, Evariste Systems LLC (
www.evaristesys.com)
Sent from my Google Nexus.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
> sr-users(a)lists.sip-router.org
>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
)
Sent from my Google Nexus.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org