I am sorry for inconvenience. Yes I asked these questions in developer
context.
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.
Thanks for your help
On Mon, Apr 7, 2014 at 3:41 PM, Olle E. Johansson <oej(a)edvina.net> wrote:
On 07 Apr 2014, at 15:39, Andreas Granig <agranig(a)sipwise.com> wrote:
Hi,
On 03/26/2014 03:18 PM, Alex Balashov wrote:
> No. You can't route the RTP and RTCP traffic to Kamailio, by definition.
>
> 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.
For the sake of discussion, I think it's somewhat possible to route
rtp/rtcp with kamailio. Does it make sense? No. Would it work? Probably,
in a limited way.
Of course, if you are a developer, you can do anything. :-)
But the question wasn't asked in the developer context, at least I did not
parse it that way...
/O
So if I wanted to do something like this, then I'd find the point where
kamailio is actually calling recv(), then find out where it feeds the
received data into the sip parser. There, I'd implement the logic to
quickly check if what we're dealing with is an rtp packet, and handle it
differently than other packets. For SDP in request and response bodies
flowing through my config, I'd modify SDP to put 5060 as media port for
the various streams.
Now since every packet will be received on port 5060, you can't really
distinguish between different streams, as you can't rely on the source
address advertised in SDP because of NAT, so any NAT scenario with more
than one phone behind that NAT is going to break the whole thing. Well,
putting aside NAT, you now would have to maintain mapping tables of
source addresses announced in SDP and check (and rely on) them for
inbound packets and map them to the outbound leg based on the source
address. That might work for non-NAT scenarios (but who's using NAT in a
world of IPv6 anyways?).
Now the question is, why would anyone want to do that? If the intention
is to make it work better in NAT environments, then our OP has probably
not thought it through entirely.
Andreas
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev