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

I must find out how it is with licence of school project but of course if it wouldn't be problem I can share git repo. Just today I asked in another thread here on [sr-dev] if there is way to use internal udp socket to send packets to VoIP client in my module. On Wed, Apr 16, 2014 at 8:57 AM, Daniel-Constantin Mierla <miconda(a)gmail.com > > 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(a)edvina.net> >> >> On 07 Apr 2014, at 15:39, Andreas Granig <agranig(a)sipwise.com>> >> > 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 >> > > > > _______________________________________________ > sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > -- > Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda > > > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > >