[sr-dev] [SR-Dev] Capture RTP packet in Kamailio module

[Cock Ootec]

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 at edvina.net> wrote:

>
> On 07 Apr 2014, at 15:39, Andreas Granig <agranig at 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 at lists.sip-router.org
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140414/5c898b1b/attachment.html>