Hi,
I'm having a problem with routing of BYEs in my multi homed Kamailio.
My setup is a phone on 172.16.230.1, talking to Kamailio on 172.16.230.128. On the "outside" Kamailio uses 10.64.5.16 and its talking to 41.221.230.60
I'm using the stock Kamailio 4.0.3 kamailio.cfg, with: WITH_NAT defined mhomed=1 Little change in NATMANAGE to do the rtpproxy_manage with ie or ei as appropriate, coming from my previous post and the response from Alex.
Here's the invite from the phone:
U 172.16.230.1:3694 -> 172.16.230.128:5060 INVITE sip:7171001@vc2.connection-telecom.com;transport=udp SIP/2.0. Via: SIP/2.0/UDP 172.16.230.1:3694 ;branch=z9hG4bK-d8754z-6a91626ae4c3f625-1---d8754z-;rport. Max-Forwards: 70. Contact: sip:2686959@172.16.230.1:3694;transport=udp. To: sip:7171001@vc2.connection-telecom.com. From: "vc2 2686959"sip:2686959@vc2.connection-telecom.com;tag=014e3010. Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc. CSeq: 2 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/sdp. Proxy-Authorization: ...some stuff... Supported: replaces. User-Agent: Bria 3 release 3.5.3 stamp 70600. Content-Length: 256. . v=0. o=- 1377005946728952 1 IN IP4 172.16.230.1. s=Bria 3 release 3.5.3 stamp 70600. c=IN IP4 172.16.230.1. t=0 0. m=audio 52448 RTP/AVP 8 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv.
Kamailio forwards with double-Record-Route with both of its addresses. I believe this is per SIP OUTBOUND RFC:
U 10.64.5.16:5060 -> 41.221.230.60:5060 INVITE sip:7171001@vc2.connection-telecom.com;transport=udp SIP/2.0. Record-Route: sip:10.64.5.16;r2=on;lr=on;ftag=014e3010;nat=yes. Record-Route: sip:172.16.230.128;r2=on;lr=on;ftag=014e3010;nat=yes. Via: SIP/2.0/UDP 10.64.5.16;branch=z9hG4bKe355.e526ca52.0. Via: SIP/2.0/UDP 172.16.230.1:3694 ;branch=z9hG4bK-d8754z-6a91626ae4c3f625-1---d8754z-;rport=3694. Max-Forwards: 16. Contact: sip:2686959@172.16.230.1:3694;transport=udp. To: sip:7171001@vc2.connection-telecom.com. From: "vc2 2686959"sip:2686959@vc2.connection-telecom.com;tag=014e3010. Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc. CSeq: 2 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/sdp. Proxy-Authorization: ...some stuff... Supported: replaces. User-Agent: Bria 3 release 3.5.3 stamp 70600. Content-Length: 270. P-hint: outbound. . v=0. o=- 1377005946728952 1 IN IP4 10.64.5.16. s=Bria 3 release 3.5.3 stamp 70600. c=IN IP4 10.64.5.16. t=0 0. m=audio 59194 RTP/AVP 8 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. a=nortpproxy:yes.
So that behaviour seems OK. The call does get correctly established and rtpproxy is correctly setup and audio passes in both directions.
But when the BYE is sent (from the outside), though, things go wrong:
Here's what arrives from upstream. Route: has the two entries per the RR that was sent.
U 41.221.230.60:5060 -> 10.64.5.16:5060 BYE sip:2686959@10.64.5.16:5060;transport=udp SIP/2.0. Record-Route: sip:41.221.230.60;lr=on;ftag=as70703d1c. Via: SIP/2.0/UDP 41.221.230.60;branch=z9hG4bKbd37.4108b6b2.0. Via: SIP/2.0/UDP 41.221.230.60:5070 ;received=41.221.230.60;branch=z9hG4bK4e6b38bf;rport=5070. Route: sip:10.64.5.16;r2=on;lr=on;ftag=014e3010;nat=yes,sip:172.16.230.128;r2=on;lr=on;ftag=014e3010;nat=yes. Max-Forwards: 69. From: sip:7171001@vc2.connection-telecom.com;tag=as70703d1c. To: "vc2 2686959"sip:2686959@vc2.connection-telecom.com;tag=014e3010. Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc. CSeq: 102 BYE. User-Agent: Enswitch. X-Asterisk-HangupCause: Normal Clearing. X-Asterisk-HangupCauseCode: 16. Content-Length: 0. X-Enswitch-RURI: sip:2686959@10.64.5.16:5060;transport=udp. X-Enswitch-Source: 41.221.230.60:5070. .
So Kamailio peels off the first route and then sends the BYE actually to itself. With an oddly formed blank Route: header.
Tracing through the kamailio.cfg the BYE is processed in WITHINDLG - loose_route() succeeds
It logs that 172.16.230.128 "is loose router".
U 10.64.5.16:5060 -> 172.16.230.128:5060 BYE sip:172.16.230.128;r2=on;lr=on;ftag=014e3010;nat=yes SIP/2.0. Record-Route: sip:41.221.230.60;lr=on;ftag=as70703d1c. Via: SIP/2.0/UDP 10.64.5.16;branch=z9hG4bKbd37.25d16bf3.0. Via: SIP/2.0/UDP 41.221.230.60;rport=5060;branch=z9hG4bKbd37.4108b6b2.0. Via: SIP/2.0/UDP 41.221.230.60:5070 ;received=41.221.230.60;branch=z9hG4bK4e6b38bf;rport=5070. Route: . Max-Forwards: 16. From: sip:7171001@vc2.connection-telecom.com;tag=as70703d1c. To: "vc2 2686959"sip:2686959@vc2.connection-telecom.com;tag=014e3010. Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc. CSeq: 102 BYE. User-Agent: Enswitch. X-Asterisk-HangupCause: Normal Clearing. X-Asterisk-HangupCauseCode: 16. Content-Length: 0. X-Enswitch-RURI: sip:2686959@10.64.5.16:5060;transport=udp. X-Enswitch-Source: 41.221.230.60:5070. .
When Kamailio receives the BYE from itself it sends a 404 Not here. Which is forwarded back upstream. This 404 Not here is generated in WITHINDLG too; looks like loose_route() fails (which makes sense since there is nothing in the Route header), and in that case WINTHINDLG only has code for dealing with SUBSCRIBE and ACK.
U 172.16.230.128:5060 -> 10.64.5.16:5060 SIP/2.0 404 Not here. Via: SIP/2.0/UDP 10.64.5.16;branch=z9hG4bKbd37.25d16bf3.0;rport=5060. Via: SIP/2.0/UDP 41.221.230.60;rport=5060;branch=z9hG4bKbd37.4108b6b2.0. Via: SIP/2.0/UDP 41.221.230.60:5070 ;received=41.221.230.60;branch=z9hG4bK4e6b38bf;rport=5070. From: sip:7171001@vc2.connection-telecom.com;tag=as70703d1c. To: "vc2 2686959"sip:2686959@vc2.connection-telecom.com;tag=014e3010. Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc. CSeq: 102 BYE. Server: kamailio (4.0.3 (i386/linux)). Content-Length: 0. .
U 10.64.5.16:5060 -> 41.221.230.60:5060 SIP/2.0 404 Not here. Via: SIP/2.0/UDP 41.221.230.60;rport=5060;branch=z9hG4bKbd37.4108b6b2.0. Via: SIP/2.0/UDP 41.221.230.60:5070 ;received=41.221.230.60;branch=z9hG4bK4e6b38bf;rport=5070. From: sip:7171001@vc2.connection-telecom.com;tag=as70703d1c. To: "vc2 2686959"sip:2686959@vc2.connection-telecom.com;tag=014e3010. Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc. CSeq: 102 BYE. Server: kamailio (4.0.3 (i386/linux)). Content-Length: 0. .
I tried with enable_double_rr as 0 and that did send only one Record-Route with the relayed INVITE, but the record route uses the inside address of the proxy and so we never even receive the BYE from the upstream system in that case.
I'm kinda lost about where this is going wrong - so pointers would be welcome!
Thanks, Steve
Hello,
the problem with the BYE is that the R-URI is the ip address of kamailio, resulting in match for strict routing rather than loose routing (both cases are handled by loose_route() function).
My guess of what happens is that 41.221.230.60 detects the invite as coming from behind nat and does something like fix_nated_contact(). Not being the first proxy in the path of the caller, should not do any contact mangling, but rely only on Recor-Route headers for routing.
If you cannot control 41.221.230.60 or ask for a change there, the solution is to use htable in your config to store the contact uri from invite and replace it in bye before loose_route().
I wanted to add such logic in default config for kamailio as well (not mangle contact if not first proxy), but forgot about it, I'll do it soon. There is a new function is_first_hop() in devel version, for older version the solution is to store the number of record-route headers for request and compare with the number of them in response.
Cheers, Daniel
On 8/20/13 6:00 PM, Steve Davies wrote:
Hi,
I'm having a problem with routing of BYEs in my multi homed Kamailio.
My setup is a phone on 172.16.230.1, talking to Kamailio on 172.16.230.128. On the "outside" Kamailio uses 10.64.5.16 and its talking to 41.221.230.60
I'm using the stock Kamailio 4.0.3 kamailio.cfg, with: WITH_NAT defined mhomed=1 Little change in NATMANAGE to do the rtpproxy_manage with ie or ei as appropriate, coming from my previous post and the response from Alex.
Here's the invite from the phone:
U 172.16.230.1:3694 <http://172.16.230.1:3694> -> 172.16.230.128:5060 <http://172.16.230.128:5060> INVITE sip:7171001@vc2.connection-telecom.com <mailto:sip%3A7171001@vc2.connection-telecom.com>;transport=udp SIP/2.0. Via: SIP/2.0/UDP 172.16.230.1:3694;branch=z9hG4bK-d8754z-6a91626ae4c3f625-1---d8754z-;rport. Max-Forwards: 70. Contact: <sip:2686959@172.16.230.1:3694;transport=udp>. To: <sip:7171001@vc2.connection-telecom.com <mailto:sip%3A7171001@vc2.connection-telecom.com>>. From: "vc2 2686959"<sip:2686959@vc2.connection-telecom.com <mailto:sip%3A2686959@vc2.connection-telecom.com>>;tag=014e3010. Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc. CSeq: 2 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/sdp. Proxy-Authorization: ...some stuff... Supported: replaces. User-Agent: Bria 3 release 3.5.3 stamp 70600. Content-Length: 256. . v=0. o=- 1377005946728952 1 IN IP4 172.16.230.1. s=Bria 3 release 3.5.3 stamp 70600. c=IN IP4 172.16.230.1. t=0 0. m=audio 52448 RTP/AVP 8 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv.Kamailio forwards with double-Record-Route with both of its addresses. I believe this is per SIP OUTBOUND RFC:
U 10.64.5.16:5060 <http://10.64.5.16:5060> -> 41.221.230.60:5060 <http://41.221.230.60:5060> INVITE sip:7171001@vc2.connection-telecom.com <mailto:sip%3A7171001@vc2.connection-telecom.com>;transport=udp SIP/2.0. Record-Route: <sip:10.64.5.16;r2=on;lr=on;ftag=014e3010;nat=yes>. Record-Route: <sip:172.16.230.128;r2=on;lr=on;ftag=014e3010;nat=yes>. Via: SIP/2.0/UDP 10.64.5.16;branch=z9hG4bKe355.e526ca52.0. Via: SIP/2.0/UDP 172.16.230.1:3694;branch=z9hG4bK-d8754z-6a91626ae4c3f625-1---d8754z-;rport=3694. Max-Forwards: 16. Contact: <sip:2686959@172.16.230.1:3694;transport=udp>. To: <sip:7171001@vc2.connection-telecom.com <mailto:sip%3A7171001@vc2.connection-telecom.com>>. From: "vc2 2686959"<sip:2686959@vc2.connection-telecom.com <mailto:sip%3A2686959@vc2.connection-telecom.com>>;tag=014e3010. Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc. CSeq: 2 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/sdp. Proxy-Authorization: ...some stuff... Supported: replaces. User-Agent: Bria 3 release 3.5.3 stamp 70600. Content-Length: 270. P-hint: outbound. . v=0. o=- 1377005946728952 1 IN IP4 10.64.5.16. s=Bria 3 release 3.5.3 stamp 70600. c=IN IP4 10.64.5.16. t=0 0. m=audio 59194 RTP/AVP 8 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. a=nortpproxy:yes.So that behaviour seems OK. The call does get correctly established and rtpproxy is correctly setup and audio passes in both directions.
But when the BYE is sent (from the outside), though, things go wrong:
Here's what arrives from upstream. Route: has the two entries per the RR that was sent.
U 41.221.230.60:5060 <http://41.221.230.60:5060> -> 10.64.5.16:5060 <http://10.64.5.16:5060> BYE sip:2686959@10.64.5.16:5060;transport=udp SIP/2.0. Record-Route: <sip:41.221.230.60;lr=on;ftag=as70703d1c>. Via: SIP/2.0/UDP 41.221.230.60;branch=z9hG4bKbd37.4108b6b2.0. Via: SIP/2.0/UDP 41.221.230.60:5070;received=41.221.230.60;branch=z9hG4bK4e6b38bf;rport=5070. Route: <sip:10.64.5.16;r2=on;lr=on;ftag=014e3010;nat=yes>,<sip:172.16.230.128;r2=on;lr=on;ftag=014e3010;nat=yes>. Max-Forwards: 69. From: <sip:7171001@vc2.connection-telecom.com <mailto:sip%3A7171001@vc2.connection-telecom.com>>;tag=as70703d1c. To: "vc2 2686959"<sip:2686959@vc2.connection-telecom.com <mailto:sip%3A2686959@vc2.connection-telecom.com>>;tag=014e3010. Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc. CSeq: 102 BYE. User-Agent: Enswitch. X-Asterisk-HangupCause: Normal Clearing. X-Asterisk-HangupCauseCode: 16. Content-Length: 0. X-Enswitch-RURI: sip:2686959@10.64.5.16:5060;transport=udp. X-Enswitch-Source: 41.221.230.60:5070 <http://41.221.230.60:5070>. .So Kamailio peels off the first route and then sends the BYE actually to itself. With an oddly formed blank Route: header.
Tracing through the kamailio.cfg the BYE is processed in WITHINDLG - loose_route() succeeds
It logs that 172.16.230.128 "is loose router".
U 10.64.5.16:5060 <http://10.64.5.16:5060> -> 172.16.230.128:5060 <http://172.16.230.128:5060> BYE sip:172.16.230.128;r2=on;lr=on;ftag=014e3010;nat=yes SIP/2.0. Record-Route: <sip:41.221.230.60;lr=on;ftag=as70703d1c>. Via: SIP/2.0/UDP 10.64.5.16;branch=z9hG4bKbd37.25d16bf3.0. Via: SIP/2.0/UDP 41.221.230.60;rport=5060;branch=z9hG4bKbd37.4108b6b2.0. Via: SIP/2.0/UDP 41.221.230.60:5070;received=41.221.230.60;branch=z9hG4bK4e6b38bf;rport=5070. Route: . Max-Forwards: 16. From: <sip:7171001@vc2.connection-telecom.com <mailto:sip%3A7171001@vc2.connection-telecom.com>>;tag=as70703d1c. To: "vc2 2686959"<sip:2686959@vc2.connection-telecom.com <mailto:sip%3A2686959@vc2.connection-telecom.com>>;tag=014e3010. Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc. CSeq: 102 BYE. User-Agent: Enswitch. X-Asterisk-HangupCause: Normal Clearing. X-Asterisk-HangupCauseCode: 16. Content-Length: 0. X-Enswitch-RURI: sip:2686959@10.64.5.16:5060;transport=udp. X-Enswitch-Source: 41.221.230.60:5070 <http://41.221.230.60:5070>. .When Kamailio receives the BYE from itself it sends a 404 Not here. Which is forwarded back upstream. This 404 Not here is generated in WITHINDLG too; looks like loose_route() fails (which makes sense since there is nothing in the Route header), and in that case WINTHINDLG only has code for dealing with SUBSCRIBE and ACK.
U 172.16.230.128:5060 <http://172.16.230.128:5060> -> 10.64.5.16:5060 <http://10.64.5.16:5060> SIP/2.0 404 Not here. Via: SIP/2.0/UDP 10.64.5.16;branch=z9hG4bKbd37.25d16bf3.0;rport=5060. Via: SIP/2.0/UDP 41.221.230.60;rport=5060;branch=z9hG4bKbd37.4108b6b2.0. Via: SIP/2.0/UDP 41.221.230.60:5070;received=41.221.230.60;branch=z9hG4bK4e6b38bf;rport=5070. From: <sip:7171001@vc2.connection-telecom.com <mailto:sip%3A7171001@vc2.connection-telecom.com>>;tag=as70703d1c. To: "vc2 2686959"<sip:2686959@vc2.connection-telecom.com <mailto:sip%3A2686959@vc2.connection-telecom.com>>;tag=014e3010. Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc. CSeq: 102 BYE. Server: kamailio (4.0.3 (i386/linux)). Content-Length: 0. . U 10.64.5.16:5060 <http://10.64.5.16:5060> -> 41.221.230.60:5060 <http://41.221.230.60:5060> SIP/2.0 404 Not here. Via: SIP/2.0/UDP 41.221.230.60;rport=5060;branch=z9hG4bKbd37.4108b6b2.0. Via: SIP/2.0/UDP 41.221.230.60:5070;received=41.221.230.60;branch=z9hG4bK4e6b38bf;rport=5070. From: <sip:7171001@vc2.connection-telecom.com <mailto:sip%3A7171001@vc2.connection-telecom.com>>;tag=as70703d1c. To: "vc2 2686959"<sip:2686959@vc2.connection-telecom.com <mailto:sip%3A2686959@vc2.connection-telecom.com>>;tag=014e3010. Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc. CSeq: 102 BYE. Server: kamailio (4.0.3 (i386/linux)). Content-Length: 0. .I tried with enable_double_rr as 0 and that did send only one Record-Route with the relayed INVITE, but the record route uses the inside address of the proxy and so we never even receive the BYE from the upstream system in that case.
I'm kinda lost about where this is going wrong - so pointers would be welcome!
Thanks, Steve
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 20 August 2013 18:49, Daniel-Constantin Mierla miconda@gmail.com wrote:
If you cannot control 41.221.230.60 or ask for a change there, the solution is to use htable in your config to store the contact uri from invite and replace it in bye before loose_route().
Let me have a go at doing it this way. For the learning as much as anything.
What is an appropriate htable "key" to use to remember the contact? the $ci (callid) is what I can think of.
Thanks, Steve
On 8/20/13 9:08 PM, Steve Davies wrote:
On 20 August 2013 18:49, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
If you cannot control 41.221.230.60 <tel:41.221.230.60> or ask for a change there, the solution is to use htable in your config to store the contact uri from invite and replace it in bye before loose_route().Let me have a go at doing it this way. For the learning as much as anything.
What is an appropriate htable "key" to use to remember the contact? the $ci (callid) is what I can think of.
I would use also the tags - something like: - save for invite: $sht(x=>$ci::$ft) = $sel(contact.uri); - save for 200ok of invite $sht(x=>$ci::$tt) = $sel(contact.uri);
For bye, if uri==myself, then if $sht(x=>$ci::$tt)!=$null then $ru = $sht(x=>$ci::$tt)
You should define hash table x with db persistence if you want to have the items saved on restarts.
Cheers, Daniel
Hi,
On 20 August 2013 23:37, Daniel-Constantin Mierla miconda@gmail.com wrote:
I would use also the tags - something like:
- save for invite:
$sht(x=>$ci::$ft) = $sel(contact.uri);
- save for 200ok of invite
$sht(x=>$ci::$tt) = $sel(contact.uri);
For bye, if uri==myself, then if $sht(x=>$ci::$tt)!=$null then $ru = $sht(x=>$ci::$tt)
I've got something that works for my simple test case.
But could you just explain one thing for me:
When the upstream service sends back the 407 to the initial INVITE, the kamalio.cfg processes that via failure_route[MANAGE_FAILURE]. That calls route[NATMANAGE]. Its in NATMANAGE where I put my code to save the contact.
But I'm surprised to see that "is_request()" is apparently true at that time:
My code says "if ( is_request() && ($ft != $null) && ($sel(contact.uri) != $null) ) ...." - ie its a request, there is a from_tag, and there is a contact: uri. In that case I save the contact.uri and xlog a message.
I see the message, and the contact is (re-)saved. Its harmless since the contact in the 407 is the same contact that was in the INVITE.
But to improve my understanding, which is is_request true for the 407 which surely is a reply?
Is there documentation I have missed which will help me understand the "architecture" and internal logic flow of Kamailio better?
Thanks, Steve
On 20 August 2013 18:49, Daniel-Constantin Mierla miconda@gmail.com wrote:
I wanted to add such logic in default config for kamailio as well (not mangle contact if not first proxy), but forgot about it, I'll do it soon. There is a new function is_first_hop() in devel version, for older version the solution is to store the number of record-route headers for request and compare with the number of them in response.
Hi Daniel,
If you are going to work on the default config, note also that the rtpproxy_manage as is doesn't work properly if the rtpproxy is working in bridged mode on a multi-homed box. Per Alex's advice and my experiments you need to to the rtpproxy_manage with "ie" or "ei" flags depending whether the request is inside->outside or outside->inside.
Thanks, Steve
Hello,
On 8/21/13 10:36 AM, Steve Davies wrote:
On 20 August 2013 18:49, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
I wanted to add such logic in default config for kamailio as well (not mangle contact if not first proxy), but forgot about it, I'll do it soon. There is a new function is_first_hop() in devel version, for older version the solution is to store the number of record-route headers for request and compare with the number of them in response.Hi Daniel,
If you are going to work on the default config, note also that the rtpproxy_manage as is doesn't work properly if the rtpproxy is working in bridged mode on a multi-homed box. Per Alex's advice and my experiments you need to to the rtpproxy_manage with "ie" or "ei" flags depending whether the request is inside->outside or outside->inside.
multi-homed/bridging networks is a custom installation, not the common one and anyhow 'e', 'i' flags don't work automatically, they require to know the order of listen interfaces provided to rtpproxy application as well as conditions on local receiving sockets. Therefore I think it doesn't belong to default config -- the case is documented in several places, there are some examples in the rtpproxy module folder as well as articles on the web.
We have the kamailio-advanced.cfg (installed as well and shipped in packages), file that tries to collect as many features as people want to add, if someone is interesting in adding a option for multihomed, it's free to do it (ie., using some define condition such as WITH_MULTIHOMED).
On the other hand, peering with other voip networks (which can run a proxy) is common and we actually allow that in the default config (calls from local users to foreign networks and calls from foreign networks to local users).
Cheers, Daniel
-
Daniel-Constantin Mierla -
Steve Davies -
Steve Davies