Thanks for your quick reply. So, Kamailio does nothing with RTP/RTCP packets? I think I understand (now when I think about it) - Kamailio only handles SIP messages by which in nested SDP two endpoints negotiate the stream where media will go through? So RTP/RTCP media stream flow directly between two UA endpoints and Kamailio has nothing to do with handling of these packets. Could you, please confirm my thoughts? All right but what if for example we have special UA that sends to Kamailio specially modified packet (non standard SIP). In my extension of topoh module I have sanity_checks disabled so will Kamailio check this packet before my module and drops it or I can receive, modify and forward this packet? I mean modify this packet to standard SIP packet and forward it to another UA. I am just asking theoretically because in the moment I cant try this. On Wed, Mar 26, 2014 at 7:41 AM, Olle E. Johansson <oej(a)edvina.net> wrote:

On 26 Mar 2014, at 08:44, Cock Ootec <cockootec(a)gmail.com> wrote: Yes, that is how the SIP protocol works. Please update yourself on the protocol which Kamailio is built around. Yes. You can modify as much as you want. /O

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. On 26 March 2014 04:21:08 GMT-04:00, Cock Ootec <cockootec(a)gmail.com> wrote: -- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard. Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com

Hi, On 03/26/2014 03:18 PM, Alex Balashov wrote: 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. 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

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:

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 > >