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

[Daniel-Constantin Mierla]

On 14/04/14 10:29, Cock Ootec wrote:
> 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
It is not useless if needed. Maybe you can share more details and we can 
give hints on what could be reused for easier development. Also, you may 
be surprised to find other people having same interest and in case it is 
something wanted by more  and you want to release your code open source, 
then we can include the module in official kamailio git repository.

Cheers,
Daniel

> 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 
> <mailto:oej at edvina.net>> wrote:
>
>
>     On 07 Apr 2014, at 15:39, Andreas Granig <agranig at sipwise.com
>     <mailto: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 <mailto: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 <mailto: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

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140416/57196d21/attachment-0001.html>