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

[Cockootec Jarabee]

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 at gmail.com
> wrote:

>
> 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> 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
>>
>
>
>
> _______________________________________________
> sr-dev mailing listsr-dev at 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 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/20140427/6d1a1106/attachment.html>