[OpenSIPS-Users] Parallel forking (using registrar branching) & mediaproxy
erwan.humez at orange-ftgroup.com
erwan.humez at orange-ftgroup.com
Mon Jun 15 18:09:31 CEST 2009
Hi Dan,
Thanks for the feedback.
>It can be used that way just fine. But if you use it with a private IP
>address (as defined by rfc 1918), it may not behave like you expect
>it. Since we do not use it that way (and nobody we know does), it's
>not tested and nobody knows exactly what to expect. In other words we
>cannot give you advice for that use case or tell you what to expect.
>If you explore the case, please share your results here.
Indeed, i did several tests using private IP addresses for all equipment
(MGW, Opensips/Mediaproxy, softphone).
Those tests were successfull and mainly included : sip2sip, sip2tdm,
tdm2sip, sip2sip (// fork), with & without early media and more opensips
related ones.
Only one case was NOK : the one described in my first email about sip2tdm
(// fork).
Find below a quick schema of the previous platform architecture used to
perform those tests.
xxxxxxxxx
TDM x x
Phone 8003-----------x MGW 1 x
x x
xxxxxxxxx
| 10.0.1.1
|
| 10.0.1.2 xxxxxxxxxxxxxx
xxxxxxxxx x x
TDM x x 10.0.0.2 10.0.0.1 x Opensips x
Phone 8003-----------x MGW 2 x---------------------------x Mediaproxy x
x x x inc. relay x
xxxxxxxxx x x
xxxxxxxxxxxxxx
|
xxxxxxxxx |
x x 192.168.2.223 192.168.2.233 |
x PC x----------------------------------
x x
xxxxxxxxx
Note: 192.168.2.233 being the listening IP for both opensips & mediaproxy.
>One thing that is known not to work when using private IP addresses,
>is chaining multiple media relays in the path. When they do not have a
>public IP address they will deadlock (if there is more than one media-
>relay in the path). However, if they have a public IP, the relays can
>start relaying even before they receive a packet from both ends,
>because with a public IP they know that it's not behind NAT and
>reachable, so they can start sending to that address right away and
>thus avoiding the deadlock.
Actually, media relay chaining is not to be considered since only one
relay has been used so far.
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
I re-run exactly the same tests and all were OK except the one for which i
first sent an email : call forking from sip to tdm.
So finally, i got exactly the same issue even when using public IPs... To
sum up, please remember the test scenario from my first email and find
below 2 main logs from mediaproxy:
In working case (MGW2 is answering the forked call):
------------------------------------------------------
debug: Got traffic information for stream: (audio) 10.0.100.5:5166 (RTP:
90.84.16.5:5166, RTCP: 90.84.16.5:5167) <-> 90.84.16.17:50000 <->
90.84.16.17:50002 <-> 10.0.100.3:19194 (RTP: 90.84.16.3:19194, RTCP:
90.84.16.2:16867)
=> we got some errors here with the RTP and RTCP IP addresses which belong
to different MGWs, but this does not prevent from working.
In non-working case (MGW1 is answering the forked call):
----------------------------------------------------------
debug: Got traffic information for stream: (audio) 10.0.100.5:5172 (RTP:
90.84.16.5:5172, RTCP: 90.84.16.5:5173) <-> 90.84.16.17:50008 <->
90.84.16.17:50010 <-> 10.0.100.2:19160 (RTP: 90.84.16.3:17994, RTCP:
90.84.16.3:17995)
=> we got some errors here with the RTP IP addresses which belong to
different MGWs: 90.84.16.3 does not pick up the call and the RTP
information RTP:90.84.16.3:17994 is not correct and comes from the 183/SDP
message received before picking up the call (can be checked in the network
traces).
=> that is why i said it might be related to some early media issue here.
Please find the complete mediaproxy traces below:
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'}
RELAY / MGW2 user picks up (working)
===================================
debug: Adding new dispatcher at 90.84.16.17:25060
debug: Connected to dispatcher at 90.84.16.17:25060
debug: Received new SDP offer
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50000
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50001
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50002
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50003
debug: Added new stream: (audio) 10.0.100.5:5166 (RTP: Unknown, RTCP:
Unknown) <-> 90.84.16.17:50000 <-> 90.84.16.17:50002 <-> Unknown (RTP:
Unknown, RTCP: Unknown)
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50004
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50005
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50006
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50007
debug: Added new stream: (video) 10.0.100.5:5168 (RTP: Unknown, RTCP:
Unknown) <-> 90.84.16.17:50004 <-> 90.84.16.17:50006 <-> Unknown (RTP:
Unknown, RTCP: Unknown)
debug: created new session
E221500403491821A52E0C759CDF548B at cust1.sipetrali.fr:
c1p1 at cust1.sipetrali.fr (E7ACBFABF6795C968B3F8EE4C65008E7) -->
8003 at 90.84.16.17
debug: Got traffic information for stream: (audio) 10.0.100.5:5166 (RTP:
Unknown, RTCP: Unknown) <-> 90.84.16.17:50000 <-> 90.84.16.17:50002 <->
Unknown (RTP: 90.84.16.3:19194, RTCP: Unknown)
debug: Got traffic information for stream: (audio) 10.0.100.5:5166 (RTP:
Unknown, RTCP: Unknown) <-> 90.84.16.17:50000 <-> 90.84.16.17:50002 <->
Unknown (RTP: 90.84.16.3:19194, RTCP: 90.84.16.2:16867)
debug: updating existing session
E221500403491821A52E0C759CDF548B at cust1.sipetrali.fr:
c1p1 at cust1.sipetrali.fr (E7ACBFABF6795C968B3F8EE4C65008E7) -->
8003 at 90.84.16.17
debug: Received updated SDP answer
debug: Got initial answer from callee for stream: (audio) 10.0.100.5:5166
(RTP: Unknown, RTCP: Unknown) <-> 90.84.16.17:50000 <-> 90.84.16.17:50002
<-> 10.0.100.3:19194 (RTP: 90.84.16.3:19194, RTCP: 90.84.16.2:16867)
debug: Stream explicitly rejected: (video) 10.0.100.5:5168 (RTP: Unknown,
RTCP: Unknown) <-> 90.84.16.17:50004 <-> 90.84.16.17:50006 <-> Unknown
(RTP: Unknown, RTCP: Unknown)
(Port 50004 Closed)
(Port 50005 Closed)
(Port 50006 Closed)
(Port 50007 Closed)
debug: Got traffic information for stream: (audio) 10.0.100.5:5166 (RTP:
90.84.16.5:5166, RTCP: Unknown) <-> 90.84.16.17:50000 <->
90.84.16.17:50002 <-> 10.0.100.3:19194 (RTP: 90.84.16.3:19194, RTCP:
90.84.16.2:16867)
debug: Got traffic information for stream: (audio) 10.0.100.5:5166 (RTP:
90.84.16.5:5166, RTCP: 90.84.16.5:5167) <-> 90.84.16.17:50000 <->
90.84.16.17:50002 <-> 10.0.100.3:19194 (RTP: 90.84.16.3:19194, RTCP:
90.84.16.2:16867)
debug: removing session
E221500403491821A52E0C759CDF548B at cust1.sipetrali.fr:
c1p1 at cust1.sipetrali.fr (E7ACBFABF6795C968B3F8EE4C65008E7) -->
8003 at 90.84.16.17
(Port 50000 Closed)
(Port 50001 Closed)
(Port 50002 Closed)
(Port 50003 Closed)
RELAY / MGW1 user picks up (NOT working)
=======================================
debug: Received new SDP offer
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50008
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50009
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50010
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50011
debug: Added new stream: (audio) 10.0.100.5:5172 (RTP: Unknown, RTCP:
Unknown) <-> 90.84.16.17:50008 <-> 90.84.16.17:50010 <-> Unknown (RTP:
Unknown, RTCP: Unknown)
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50012
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50013
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50014
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50015
debug: Added new stream: (video) 10.0.100.5:5174 (RTP: Unknown, RTCP:
Unknown) <-> 90.84.16.17:50012 <-> 90.84.16.17:50014 <-> Unknown (RTP:
Unknown, RTCP: Unknown)
debug: created new session
1E5EC56C5A7D8879C68FB1FA02D1AA8B at cust1.sipetrali.fr:
c1p1 at cust1.sipetrali.fr (CA3D6F5E2FF9CDAC4585370AF309F62A) -->
8003 at 90.84.16.17
debug: Got traffic information for stream: (audio) 10.0.100.5:5172 (RTP:
Unknown, RTCP: Unknown) <-> 90.84.16.17:50008 <-> 90.84.16.17:50010 <->
Unknown (RTP: 90.84.16.3:17994, RTCP: Unknown)
debug: updating existing session
1E5EC56C5A7D8879C68FB1FA02D1AA8B at cust1.sipetrali.fr:
c1p1 at cust1.sipetrali.fr (CA3D6F5E2FF9CDAC4585370AF309F62A) -->
8003 at 90.84.16.17
debug: Received updated SDP answer
debug: Got initial answer from callee for stream: (audio) 10.0.100.5:5172
(RTP: Unknown, RTCP: Unknown) <-> 90.84.16.17:50008 <-> 90.84.16.17:50010
<-> 10.0.100.2:19160 (RTP: 90.84.16.3:17994, RTCP: Unknown)
debug: Stream explicitly rejected: (video) 10.0.100.5:5174 (RTP: Unknown,
RTCP: Unknown) <-> 90.84.16.17:50012 <-> 90.84.16.17:50014 <-> Unknown
(RTP: Unknown, RTCP: Unknown)
(Port 50012 Closed)
(Port 50013 Closed)
(Port 50014 Closed)
(Port 50015 Closed)
debug: Got traffic information for stream: (audio) 10.0.100.5:5172 (RTP:
Unknown, RTCP: Unknown) <-> 90.84.16.17:50008 <-> 90.84.16.17:50010 <->
10.0.100.2:19160 (RTP: 90.84.16.3:17994, RTCP: 90.84.16.3:17995)
debug: Got traffic information for stream: (audio) 10.0.100.5:5172 (RTP:
90.84.16.5:5172, RTCP: Unknown) <-> 90.84.16.17:50008 <->
90.84.16.17:50010 <-> 10.0.100.2:19160 (RTP: 90.84.16.3:17994, RTCP:
90.84.16.3:17995)
debug: Got traffic information for stream: (audio) 10.0.100.5:5172 (RTP:
90.84.16.5:5172, RTCP: 90.84.16.5:5173) <-> 90.84.16.17:50008 <->
90.84.16.17:50010 <-> 10.0.100.2:19160 (RTP: 90.84.16.3:17994, RTCP:
90.84.16.3:17995)
debug: removing session
1E5EC56C5A7D8879C68FB1FA02D1AA8B at cust1.sipetrali.fr:
c1p1 at cust1.sipetrali.fr (CA3D6F5E2FF9CDAC4585370AF309F62A) -->
8003 at 90.84.16.17
(Port 50008 Closed)
(Port 50009 Closed)
(Port 50010 Closed)
(Port 50011 Closed)
Thanks again for your precious help and let me know if you need anything,
Kindly regards,
Erwan.
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090615/15c6a8a6/attachment-0001.htm
More information about the Users
mailing list