[OpenSIPS-Users] Parallel forking (using registrar branching) & mediaproxy
Ruud Klaver
ruud at ag-projects.com
Tue Jun 30 18:35:15 CEST 2009
Hi Erwan,
On 15 Jun 2009, at 18:09, erwan.humez at orange-ftgroup.com wrote:
> Following your advice, i upgraded my platform to the following
> architecture (including private IPs & NAT):
>
> xxxxxxxxx
> TDM x x 10.0.100.2
> Phone 8003-----------x MGW 1 x--------------|
> x x |
> xxxxxxxxx |
>
> | xxxxxxxxxxxxxx
> xxxxxxxxx |
> xxxxxxxxx x x
> TDM x x 10.0.100.3 | 10.0.100.1 x
> x 90.84.16.21 90.84.16.17 x Opensips x
> Phone 8003-----------x MGW 2 x--------------|--------------x NAT
> x-----------------------------x Mediaproxy x
> x x | x
> x x inc. relay x
> xxxxxxxxx |
> xxxxxxxxx x x
>
> | xxxxxxxxxxxxxx
> xxxxxxxxx |
> x x 10.0.100.5 |
> x PC x--------------|
> x x
> xxxxxxxxx
>
> Note: 90.84.16.17 being the listening IP for both opensips &
> mediaproxy.
>
> Using those NAT translation rules:
> -> 10.0.100.2 turned into 90.84.16.2
> -> 10.0.100.3 turned into 90.84.16.3
> -> 10.0.100.5 turned into 90.84.16.5
That's a much better setup than your previous one. I really can't tell
you what a relay with two IPs when you're only listening on one does.
BTW, strictly speaking NATing to different IPs is not necessary, it
should work when NATting all to the same IP, but it's a good
approximation of a realistic situation.
> DISPATCHER / MGW2 user picks up (working)
> ========================================
> debug: Connection from relay at 90.84.16.17
> debug: Issuing "sessions" command to relay at 90.84.16.17
> debug: Issuing "update" command to relay at 90.84.16.17
> debug: Issuing "update" command to relay at 90.84.16.17
> debug: Issuing "remove" command to relay at 90.84.16.17
> debug: Got statistics: {'from_tag':
> 'E7ACBFABF6795C968B3F8EE4C65008E7', 'dialog_id': None, 'start_time':
> 1245079081.8, 'timed_out': False, 'call_id': 'E221500403491821A52E0C759CDF548B at cust1.sipetrali.fr
> ', 'to_tag': '254B127C-C20', 'streams': [{'status': 'rejected',
> 'caller_codec': 'Unknown', 'post_dial_delay': None, 'callee_codec':
> 'Unknown', 'start_time': 0, 'caller_bytes': 0, 'callee_bytes': 0,
> 'caller_packets': 0, 'end_time': 0, 'callee_remote': 'Unknown',
> 'caller_remote': 'Unknown', 'media_type': 'video', 'callee_local':
> '90.84.16.17:50006', 'timeout_wait': 0, 'caller_local':
> '90.84.16.17:50004', 'callee_packets': 0}, {'status': 'closed',
> 'caller_codec': 'Unknown(13)', 'post_dial_delay':
> 0.54056406021100001, 'callee_codec': 'G711u', 'start_time': 0,
> 'caller_bytes': 59336, 'callee_bytes': 58800, 'caller_packets': 297,
> 'end_time': 6, 'callee_remote': '90.84.16.3:19194', 'caller_remote':
> '90.84.16.5:5166', 'media_type': 'audio', 'callee_local':
> '90.84.16.17:50002', 'timeout_wait': 0, 'caller_local':
> '90.84.16.17:50000', 'callee_packets': 294}], 'duration': 6,
> 'to_uri': '8003 at 90.84.16.17', 'from_uri': 'c1p1 at cust1.sipetrali.fr',
> 'callee_ua': 'Cisco-SIPGateway/IOS-12.x', 'caller_ua': 'Kapanga
> Softphone Desktop 1.00/2172f
> +1213709005_001CBFA9A746_001C233756B9_005056C00001_005056C00008'}
>
> DISPATCHER / MGW1 user picks up (NOT working)
> ============================================
> debug: Issuing "update" command to relay at 90.84.16.17
> debug: Issuing "update" command to relay at 90.84.16.17
> debug: Issuing "remove" command to relay at 90.84.16.17
> debug: Got statistics: {'from_tag':
> 'CA3D6F5E2FF9CDAC4585370AF309F62A', 'dialog_id': None, 'start_time':
> 1245079099.1400001, 'timed_out': False, 'call_id': '1E5EC56C5A7D8879C68FB1FA02D1AA8B at cust1.sipetrali.fr
> ', 'to_tag': '1EEA090-37D', 'streams': [{'status': 'rejected',
> 'caller_codec': 'Unknown', 'post_dial_delay': None, 'callee_codec':
> 'Unknown', 'start_time': 0, 'caller_bytes': 0, 'callee_bytes': 0,
> 'caller_packets': 0, 'end_time': 0, 'callee_remote': 'Unknown',
> 'caller_remote': 'Unknown', 'media_type': 'video', 'callee_local':
> '90.84.16.17:50014', 'timeout_wait': 0, 'caller_local':
> '90.84.16.17:50012', 'callee_packets': 0}, {'status': 'closed',
> 'caller_codec': 'Unknown(13)', 'post_dial_delay':
> 0.53873777389499999, 'callee_codec': 'G711u', 'start_time': 0,
> 'caller_bytes': 55800, 'callee_bytes': 0, 'caller_packets': 279,
> 'end_time': 5, 'callee_remote': '90.84.16.3:17994', 'caller_remote':
> '90.84.16.5:5172', 'media_type': 'audio', 'callee_local':
> '90.84.16.17:50010', 'timeout_wait': 0, 'caller_local':
> '90.84.16.17:50008', 'callee_packets': 0}], 'duration': 5, 'to_uri': '8003 at 90.84.16.17
> ', 'from_uri': 'c1p1 at cust1.sipetrali.fr', 'callee_ua': 'Cisco-
> SIPGateway/IOS-12.x', 'caller_ua': 'Kapanga Softphone Desktop
> 1.00/2172f
> +1213709005_001CBFA9A746_001C233756B9_005056C00001_005056C00008'}
From this I can already see that your problem is probably in your
OpenSIPs configuration. What SHOULD happen is that any occurrence of
SDP is sent to the relay. In this scenario that would be:
1) The original INVITE
2) The first 183
3) The second 183
4) The final response, 200 OK
Now what you are trying to do with two streams of early media is quite
weird, so between steps 1 and 4 the user placing the call could be
quite confused about what it hears, since basically he/she should hear
the last gateway that sent a 183. But in the end it should be fine, as
the relay is again updated by the 200 OK, which should result in the
user hearing whichever gateway picked up.
But from your trace I can see only two update commands. I'm guessing
this is from the original INVITE and the first 183. So what happens is
that the relays is locked into the RTP of whichever gateway sends it
first. So getting your OpenSIPs config to send the SDP to the relay on
the seconds 183 and the 200 OK should fix this.
On the other hand, I would be curious to see if it will be fixed, as
the gateway that does not pick up could continue sending RTP for a
while, causing the relay to still thing this is the correct source
after the OK has been sent. It's a confusing situation...
Ruud Klaver
AG Projects
More information about the Users
mailing list