[SR-Users] (Kamailio/RTPproyx) Public -> LAN -> Asterisk (1, 2, .., n)
Alexandr Usov
blessendor at gmail.com
Tue Aug 6 12:06:22 CEST 2013
It seems I am undesrtand whereis problem can be found.
Original tutorial of Kamailio+Asterisk realtime integration (by Asipto)
containse settings for cheking if the "nat=yes" presents, but in Asterisk
11 I am using nat=force_rport,comedia.
# RTPProxy control
route[NATMANAGE] {
#!ifdef WITH_NAT
if (is_request()) {
if(has_totag()) {
if(check_route_param("nat=yes")) {
setbflag(FLB_NATB);
}
}
}
if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB)))
return;
rtpproxy_manage();
if (is_request()) {
if (!has_totag()) {
add_rr_param(";nat=yes");
}
}
if (is_reply()) {
if(isbflagset(FLB_NATB)) {
fix_nated_contact();
}
}
#!endif
return;
}
BTW, we don't need NAT for asterisks peers, if we use Asterisk behinde
Kanailio LAN interface (2.2.2.2).
ToHost : 2.2.2.2
Addr->IP : 2.2.2.2:5060
If I cahnge to nat=no in the NATMANAGE - RTP debug still showing from
1.1.1.1 (public) kamailio IP.
Rtpproxy started in the bridge mode.
set_destination: Parsing <sip:2.2.2.2;r2=on;lr=on;nat=no> for address/port
to send to
set_destination: set destination to 2.2.2.2:5060
Reliably Transmitting (no NAT) to 2.2.2.2:5060:
BYE sip:1-101 at PUBLIC.CLIENT.PEER.IP:17303;ob SIP/2.0
Via: SIP/2.0/UDP 2.2.2.101:5080;branch=z9hG4bK1597848e
Route: <sip:2.2.2.2;r2=on;lr=on;nat=no>,<sip:1.1.1.1;r2=on;lr=on;nat=no>
Sent RTP packet to 1.1.1.1:63232 (type 00, seq 003837, ts 016800, len
000160)
Got RTP packet from 2.2.2.2:42346 (type 00, seq 000986, ts 016960, len
000160)
Sent RTP packet to 1.1.1.1:63232 (type 00, seq 003838, ts 016960, len
000160)
Got RTP packet from 2.2.2.2:42346 (type 00, seq 000987, ts 017120, len
000160)
Sent RTP packet to 1.1.1.1:63232 (type 00, seq 003839, ts 017120, len
000160)
But no voicing)
2013/8/6 SamyGo <govoiper at gmail.com>
> Dear Alexandr,
>
> You can connect Kamailio to RTPproxy via socket as well, use modparam like
> this:
>
> modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:12221")
>
> Then if your rtprpoxy is started in bridged mode you should use the "i"
> and "e" flags while you call the rtpproxy-manage() function in the
> kamailio.cfg file.
>
> The placement of both the flags sets the SDP c= param , so if you use "ie"
> combination of flag then that is not equal to "ei" combination of the flag.
>
> I also suggest that you turn on sip debug on the call receiving asterisk
> and observe the SDP for an incoming call from Kamailio. that will help you
> figure out the situation in SDP.
>
> Best Regards,
> Sammy
>
>
>
>
>
> On Tue, Aug 6, 2013 at 2:02 AM, Alexandr Usov <blessendor at gmail.com>wrote:
>
>> Thank you for response!
>> A little difficult for me to find the same logic in my case with tutorial
>> of ipv4/ipv6 bridgin...
>>
>> When I started
>> /usr/sbin/rtpproxy -u kamailio -l 1.1.1.1/2.2.2.2 -s udp:127.0.0.1 12221
>>
>> There is no sound.
>>
>> Is this a major to connect via unix sock?:
>>
>> modparam("rtpproxy", "rtpproxy_sock",
>> "unix:/var/run/rtpproxy/rtpproxy.sock")
>>
>>
>>
>>
>>
>> 2013/8/6 Daniel-Constantin Mierla <miconda at gmail.com>
>>
>>> Hello,
>>>
>>> you have to use rtpproxy in bridge mode, to route packets between the
>>> two local network interfaces. There are many examples out there, one shows
>>> even how to bridge between ipv4 and ipv4 networks -- you can use it as
>>> reference:
>>>
>>> - http://kb.asipto.com/kamailio:kamailio-mixed-ipv4-ipv6
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 8/5/13 7:12 PM, Alexandr Usov wrote:
>>>
>>>
>>>
>>> I have Kamailio on OpenSUSE with static real Public IP (WAN), for ex.
>>> 1.1.1.1. I have LAN IP 2.2.2.2. Asterisk as KVM virtual machine with LAN IP
>>> 2.2.2.101 and default GW not the SuSe (2.2.2.2), but 2.2.2.1 pfsense LAN
>>> with PUB IP 1.1.1.2) I am configured Registration of UA on Kamailio DB, and
>>> on Asterisk side create a static peers with Kamailio LAN ip (host=2.2.2.2).
>>>
>>> RTP Proxy question.
>>>
>>> /usr/sbin/rtpproxy -u daemon -l 1.1.1.1 -s udp:127.0.0.1 12221
>>>
>>> .... kamailio.cfg ...
>>>
>>> # RTPProxy control
>>> route[NATMANAGE] {
>>> #!ifdef WITH_NAT
>>> if (is_request()) {
>>> if(has_totag()) {
>>> if(check_route_param("nat=yes")) {
>>> setbflag(FLB_NATB);
>>> }
>>> }
>>> }
>>> if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB)))
>>> return;
>>>
>>> rtpproxy_manage();
>>>
>>> if (is_request()) {
>>> if (!has_totag()) {
>>> add_rr_param(";nat=yes");
>>> }
>>> }
>>> if (is_reply()) {
>>> if(isbflagset(FLB_NATB)) {
>>> fix_nated_contact();
>>> }
>>> }
>>> #!endif
>>> return;
>>> }
>>>
>>>
>>> Testing call:
>>>
>>> Whe User 1-100 calling User 1-101, on Asterisk side I see:
>>>
>>> -- Called SIP/1-100 at sip1.somedomain.com.ua
>>> -- SIP/sip1.somedomain.com.ua-000004cf is ringing
>>> -- SIP/sip1.somedomain.com.ua-000004cf answered SIP/1-101-000004ce
>>> > 0x15bc370 -- Probation passed - setting RTP source address to
>>> 1.1.1.1:50868
>>> > 0x7f2b6044bd10 -- Probation passed - setting RTP source address
>>> to 1.1.1.1:35082
>>>
>>> Got RTP packet from 1.1.1.1:50868 (type 00, seq 027109, ts 000160,
>>> len 000160)
>>> Sent RTP packet to 1.1.1.1:35082 (type 00, seq 037469, ts 000160,
>>> len 000160)
>>> Got RTP packet from 1.1.1.1:50868 (type 00, seq 027110, ts 000320,
>>> len 000160)
>>> Sent RTP packet to 1.1.1.1:35082 (type 00, seq 037470, ts 000320,
>>> len 000160)
>>> Got RTP packet from 1.1.1.1:50868 (type 00, seq 027111, ts 000480,
>>> len 000160)
>>> Sent RTP packet to 1.1.1.1:35082 (type 00, seq 037471, ts 000480,
>>> len 000160)
>>> Got RTP packet from 1.1.1.1:50868 (type 00, seq 027112, ts 000640,
>>> len 000160)
>>> Sent RTP packet to 1.1.1.1:35082 (type 00, seq 037472, ts 000640,
>>> len 000160)
>>>
>>>
>>> Voice transfers OK.
>>>
>>> But why not Kamailio LAN ip I receiving on the Asterisk side with the
>>> same LAN?
>>>
>>> And Kamailio log grep:
>>>
>>> skynet:~ # tail -f /var/log/messages | grep rtpproxy
>>> 2013-08-05T19:18:17.508760+03:00 skynet kamailio[25462]: 3(25481) DEBUG:
>>> rtpproxy [rtpproxy_funcs.c:148]: check_content_type(): type
>>> <application/sdp> found valid
>>> 2013-08-05T19:18:17.508875+03:00 skynet kamailio[25462]: 3(25481) DEBUG:
>>> rtpproxy [rtpproxy.c:2624]: force_rtp_proxy(): proxy reply: 63566 1.1.1.1
>>> 2013-08-05T19:18:17.530765+03:00 skynet kamailio[25462]: 6(25484) DEBUG:
>>> rtpproxy [rtpproxy_funcs.c:148]: check_content_type(): type
>>> <application/sdp> found valid
>>> 2013-08-05T19:18:17.530876+03:00 skynet kamailio[25462]: 6(25484) DEBUG:
>>> rtpproxy [rtpproxy.c:2624]: force_rtp_proxy(): proxy reply: 41958 1.1.1.1
>>> 2013-08-05T19:18:18.625815+03:00 skynet kamailio[25462]: 4(25482) DEBUG:
>>> rtpproxy [rtpproxy_funcs.c:148]: check_content_type(): type
>>> <application/sdp> found valid
>>> 2013-08-05T19:18:18.627131+03:00 skynet kamailio[25462]: 4(25482) DEBUG:
>>> rtpproxy [rtpproxy.c:2624]: force_rtp_proxy(): proxy reply: 39876 1.1.1.1
>>> 2013-08-05T19:18:18.632649+03:00 skynet kamailio[25462]: a=nortpproxy:yes
>>> 2013-08-05T19:18:18.648075+03:00 skynet kamailio[25462]: 6(25484) DEBUG:
>>> rtpproxy [rtpproxy_funcs.c:148]: check_content_type(): type
>>> <application/sdp> found valid
>>> 2013-08-05T19:18:18.649615+03:00 skynet kamailio[25462]: 6(25484) DEBUG:
>>> rtpproxy [rtpproxy.c:2624]: force_rtp_proxy(): proxy reply: 43500 1.1.1.1
>>> 2013-08-05T19:18:18.653948+03:00 skynet kamailio[25462]: a=nortpproxy:yes
>>> 2013-08-05T19:18:18.688603+03:00 skynet kamailio[25462]: 4(25482) DEBUG:
>>> rtpproxy [rtpproxy_funcs.c:148]: check_content_type(): type
>>> <application/sdp> found valid
>>> 2013-08-05T19:18:18.689762+03:00 skynet kamailio[25462]: 4(25482) DEBUG:
>>> rtpproxy [rtpproxy.c:2624]: force_rtp_proxy(): proxy reply: 63566 1.1.1.1
>>> 2013-08-05T19:18:18.701062+03:00 skynet kamailio[25462]: 6(25484) DEBUG:
>>> rtpproxy [rtpproxy_funcs.c:148]: check_content_type(): type
>>> <application/sdp> found valid
>>> 2013-08-05T19:18:18.701405+03:00 skynet kamailio[25462]: 6(25484) DEBUG:
>>> rtpproxy [rtpproxy.c:2624]: force_rtp_proxy(): proxy reply: 43500 1.1.1.1
>>> 2013-08-05T19:18:18.705506+03:00 skynet kamailio[25462]: a=nortpproxy:yes
>>>
>>> My goal is using Asterisk boxes behind Kamailio with the same LAN or
>>> even OpeVPN Lan2Lan, with Public IP on Kamailio WAN for users registration
>>> and RTP routing. So is strange to my, why RTPproxy not rewrite source of
>>> RTP traffic from PUBLIC Kamailio IP to LAN Kamailio IP when user A calls B
>>> via Asterisk?
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>> --
>>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130806/6af49073/attachment-0001.html>
More information about the sr-users
mailing list