[SR-Users] Making rtp streams appear unidirectional

aft aftnix at gmail.com
Wed Jan 14 11:58:23 CET 2015


On Mon, Jan 12, 2015 at 5:52 PM, Daniel-Constantin Mierla <miconda at gmail.com
> wrote:

>
> On 12/01/15 11:14, aft wrote:
>
>
>
> On Fri, Jan 9, 2015 at 12:37 AM, Daniel-Constantin Mierla <
> miconda at gmail.com> wrote:
>
>> Hello,
>>
>> On 01/01/15 08:29, aft wrote:
>> > Hi,
>> >
>> > Is it possible to make the rtp stream appear unidirectional?
>> >
>> > By that i mean,
>> >
>> > The rtp stream from client to proxy will go through one rtpproxy and
>> > proxy to client stream will go through another rtpproxy instance?
>> >
>> > If not, is it possible to mimic something like that by running
>> > rtpproxy in bridge mode where both IPs in bridge mode will be public IP?
>>
>>  in typical deployment rtpproxy needs to know from where to receive and
>> where to send. You may get that working if the caller and callee are on
>> public internet, if they are behind the nat, it will be hard.
>>
>> Using bridge mode should work. Also you can try to chain two rtpproxy
>> instances (with two kamailio proxy).
>>
>
>  How can i achieve this chaining?
>
> Install two kamailios with two rtpproxies and forward the messages between
> them. The second can be on the same system, different port (or even IP, if
> you want so).
>

I'm still not clear how to do this.

INVITE is usually processed by invoking route[RTPPROXY]. Now if i want to
forward it to another kamailio, what should i do?

Is the idea is like this :

INVITE--->kamailio1-----forward--->kamailio2--->route[RTPPROXY]--->Next Sip
endpoint

Client <----
route[RTPPROXY]<--------kamailio1<------forward-----kamailio2<---- reply
with SDP

If these scheme is correct, then i need to find how to do the "forward"
appropriately?



> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150114/b1de3b40/attachment.html>


More information about the sr-users mailing list