[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