Hi Richard,
this is more or less the same problem that I am experiencing. To understand
it better, just assume one branch needs to do SRTP, and the other simple
RTP.
To make this happen, you will have to enable rtpengine differently for the
same call, and this is where the crash/error happens.
R
Unfortunately rtpengine doesn't work in this way. At the end of the calls this
is the output log:
Final packet stats:
Tag 'Fw3D7R0', created 0:41 ago, in dialogue with 'TTPyT~Hdw'
Media #1, port 30224 <> 192.168.10.20:7078 , 540 p, 92880 b, 0 e
Media #1, port 30225 <> 192.168.10.20:7079 (RT
On 09/29/14 14:51, Marino Mileti wrote:
> Without rtpproxy:
>
> - A offers port a1,a2 (audio video) in INVITE to B,C (in case of no natted
> client so no needs of rtpproxy)
> - B offers port b1,b2 (183)
> - C offers port c1,c2 (182).
> - A starts to send audio/video RTP to B on port b1,b2
> - A s
On 09/29/14 14:23, Marino Mileti wrote:
> The problem isn't on 183s but on the multiple INVITE that Kamailio sends to
> clients behind rtpengine. Rtpengine open new ports for answer but on INVITE
> the rtpengine ports are the same...This happens because for all these
> clients the callid is still t
: lunedì 29 settembre 2014 20:31
A: sr-users@lists.sip-router.org
Oggetto: Re: [SR-Users] R: Re: R: Re: RTPPROXY & BRANCH
On 09/29/14 14:23, Marino Mileti wrote:
> The problem isn't on 183s but on the multiple INVITE that Kamailio
> sends to clients behind rtpengine. Rtpengine ope
2014 19:37
A: sr-users@lists.sip-router.org
Oggetto: Re: [SR-Users] R: Re: R: Re: RTPPROXY & BRANCH
On 09/29/14 13:29, Frank Carmickle wrote:
>
> On Sep 29, 2014, at 1:24 PM, Richard Fuchs wrote:
>
>> On 09/29/14 13:19, Frank Carmickle wrote:
>>>
>>> On Sep 29
On 09/29/14 13:29, Frank Carmickle wrote:
>
> On Sep 29, 2014, at 1:24 PM, Richard Fuchs wrote:
>
>> On 09/29/14 13:19, Frank Carmickle wrote:
>>>
>>> On Sep 29, 2014, at 1:14 PM, Richard Fuchs wrote:
This may work with rtpengine, as it will open new ports for answers come
from d
On Sep 29, 2014, at 1:24 PM, Richard Fuchs wrote:
> On 09/29/14 13:19, Frank Carmickle wrote:
>>
>> On Sep 29, 2014, at 1:14 PM, Richard Fuchs wrote:
>>>
>>> This may work with rtpengine, as it will open new ports for answers come
>>> from different endpoints. But the final two-way associatio
On 09/29/14 13:19, Frank Carmickle wrote:
>
> On Sep 29, 2014, at 1:14 PM, Richard Fuchs wrote:
>>
>> This may work with rtpengine, as it will open new ports for answers come
>> from different endpoints. But the final two-way association for the
>> actual call may still end up broken, as it has n
On Sep 29, 2014, at 1:14 PM, Richard Fuchs wrote:
>
> This may work with rtpengine, as it will open new ports for answers come
> from different endpoints. But the final two-way association for the
> actual call may still end up broken, as it has no way of knowing which
> client ends up receiving
On 09/25/14 10:41, Marino Mileti wrote:
>
> No no. The video will be sent by the caller user to all the callees.
>
> I'l try to explain better. My scenario is:
>
> - A make a call to a group... B & C are group member...so Kamailio is
> able to call them in parallel using alias..
>
> - B & C r
On Sep 25, 2014, at 10:41 AM, Marino Mileti wrote:
>
> No no. The video will be sent by the caller user to all the callees.
>
> I'l try to explain better. My scenario is:
>
> - A make a call to a group... B & C are group member...so Kamailio is able to
> call them in parallel using alias..
No no. The video will be sent by the caller user to all the callees.
I'l try to explain better. My scenario is:
- A make a call to a group... B & C are group member...so Kamailio is able
to call them in parallel using alias..
- B & C receive the INVITEs & replies with two separate 183 with SDP
13 matches
Mail list logo
