<div dir="ltr">I am sorry for inconvenience. Yes I asked these questions in developer context.<div>Now I am able to work with RTP packets in my module (I know that this seems to be useless but it is for my school project ;-) ) so if anyone asks it is possible.<br>
<br>Thanks for your help</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 7, 2014 at 3:41 PM, Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net" target="_blank">oej@edvina.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
On 07 Apr 2014, at 15:39, Andreas Granig <<a href="mailto:agranig@sipwise.com">agranig@sipwise.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> On 03/26/2014 03:18 PM, Alex Balashov wrote:<br>
>> No. You can't route the RTP and RTCP traffic to Kamailio, by definition.<br>
>><br>
>> You keep asking questions that betray a lack of basic understanding of SIP network elements. I think you should take Olle's suggestion and learn how it works.<br>
><br>
> For the sake of discussion, I think it's somewhat possible to route<br>
> rtp/rtcp with kamailio. Does it make sense? No. Would it work? Probably,<br>
> in a limited way.<br>
</div>Of course, if you are a developer, you can do anything. :-)<br>
<br>
But the question wasn't asked in the developer context, at least I did not<br>
parse it that way...<br>
<span class="HOEnZb"><font color="#888888"><br>
/O<br>
</font></span><div class="HOEnZb"><div class="h5">><br>
> So if I wanted to do something like this, then I'd find the point where<br>
> kamailio is actually calling recv(), then find out where it feeds the<br>
> received data into the sip parser. There, I'd implement the logic to<br>
> quickly check if what we're dealing with is an rtp packet, and handle it<br>
> differently than other packets. For SDP in request and response bodies<br>
> flowing through my config, I'd modify SDP to put 5060 as media port for<br>
> the various streams.<br>
><br>
> Now since every packet will be received on port 5060, you can't really<br>
> distinguish between different streams, as you can't rely on the source<br>
> address advertised in SDP because of NAT, so any NAT scenario with more<br>
> than one phone behind that NAT is going to break the whole thing. Well,<br>
> putting aside NAT, you now would have to maintain mapping tables of<br>
> source addresses announced in SDP and check (and rely on) them for<br>
> inbound packets and map them to the outbound leg based on the source<br>
> address. That might work for non-NAT scenarios (but who's using NAT in a<br>
> world of IPv6 anyways?).<br>
><br>
> Now the question is, why would anyone want to do that? If the intention<br>
> is to make it work better in NAT environments, then our OP has probably<br>
> not thought it through entirely.<br>
><br>
> Andreas<br>
><br>
> _______________________________________________<br>
> sr-dev mailing list<br>
> <a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
<br>
<br>
_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
</div></div></blockquote></div><br></div>