Hi Erwan,
On 15 Jun 2009, at 18:09, [email protected] 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':
> '[email protected]
> ', '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': '[email protected]', 'from_uri': '[email protected]',
> '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':
> '[email protected]
> ', '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':
> '[email protected]
> ', 'from_uri': '[email protected]', '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
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
