<br><font size=2 face="sans-serif">Hi Ruud,</font>
<br>
<br><font size=2 face="sans-serif">Thanks a lot for your answers.</font>
<br>
<br><font size=2 face="sans-serif">Please find a few feedbacks below in
your email...</font>
<br>
<br><font size=2 face="sans-serif">I will try to figure out how to fix
this issue in the opensips configuration and will keep you posted in case
i succeed ;-)</font>
<br>
<br><font size=2 face="sans-serif">Anyway, thanks a lot for your patience
and precious help again.</font>
<br>
<br><font size=2 face="sans-serif">Kindly regards</font>
<br>
<br><font size=2 face="sans-serif">Erwan.</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Ruud Klaver <ruud@ag-projects.com></b>
</font>
<p><font size=1 face="sans-serif">30/06/2009 18:35</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">A</font></div>
<td valign=top><font size=1 face="sans-serif">erwan.humez@orange-ftgroup.com</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top><font size=1 face="sans-serif">users users <users@lists.opensips.org></font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Objet</font></div>
<td valign=top><font size=1 face="sans-serif">Re: [OpenSIPS-Users] Parallel
forking (using registrar branching) & mediaproxy</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>Hi Erwan,<br>
<br>
On 15 Jun 2009, at 18:09, erwan.humez@orange-ftgroup.com wrote:<br>
<br>
> Following your advice, i upgraded my platform to the following <br>
> architecture (including private IPs & NAT):<br>
><br>
>
xxxxxxxxx<br>
> TDM x
x 10.0.100.2<br>
> Phone 8003-----------x MGW 1 x--------------|<br>
>
x x
|<br>
>
xxxxxxxxx |<br>
>
<br>
> |
xxxxxxxxxxxxxx<br>
>
xxxxxxxxx |
<br>
> xxxxxxxxx
x
x<br>
> TDM x
x 10.0.100.3 | 10.0.100.1 x
<br>
> x 90.84.16.21 90.84.16.17 x Opensips x<br>
> Phone 8003-----------x MGW 2 x--------------|--------------x NAT
<br>
> x-----------------------------x Mediaproxy x<br>
>
x x
| x
<br>
> x
x inc. relay x<br>
>
xxxxxxxxx |
<br>
> xxxxxxxxx
x
x<br>
>
<br>
> |
xxxxxxxxxxxxxx<br>
>
xxxxxxxxx |<br>
>
x x 10.0.100.5 |<br>
>
x PC x--------------|<br>
>
x x<br>
>
xxxxxxxxx<br>
><br>
> Note: 90.84.16.17 being the listening IP for both opensips & <br>
> mediaproxy.<br>
><br>
> Using those NAT translation rules:<br>
> -> 10.0.100.2 turned into 90.84.16.2<br>
> -> 10.0.100.3 turned into 90.84.16.3<br>
> -> 10.0.100.5 turned into 90.84.16.5<br>
<br>
That's a much better setup than your previous one. I really can't tell
<br>
you what a relay with two IPs when you're only listening on one does.<br>
</tt></font>
<br><font size=2 face="Courier New">[ERWAN] I don't quite understand your
statement above since the relay is only using one IP in the last target
architecture : 90.84.16.17. Only the initial architecture (with private
IPs) used a 2-IPs relay but i have given up with this architecture in order
to stick to your recommandations.</font>
<br><font size=2><tt><br>
BTW, strictly speaking NATing to different IPs is not necessary, it <br>
should work when NATting all to the same IP, but it's a good <br>
approximation of a realistic situation.<br>
</tt></font>
<br><font size=2 face="Courier New">[ERWAN] agreed, PAT only might have
been used but it was easier and quicker to setup this way ;-) It should
not have any impact on the relay behaviour, provided that IP reachability
is ensured.</font>
<br><font size=2><tt><br>
> DISPATCHER / MGW2 user picks up (working)<br>
> ========================================<br>
> debug: Connection from relay at 90.84.16.17<br>
> debug: Issuing "sessions" command to relay at 90.84.16.17<br>
> debug: Issuing "update" command to relay at 90.84.16.17<br>
> debug: Issuing "update" command to relay at 90.84.16.17<br>
> debug: Issuing "remove" command to relay at 90.84.16.17<br>
> debug: Got statistics: {'from_tag': <br>
> 'E7ACBFABF6795C968B3F8EE4C65008E7', 'dialog_id': None, 'start_time':
<br>
> 1245079081.8, 'timed_out': False, 'call_id': 'E221500403491821A52E0C759CDF548B@cust1.sipetrali.fr
<br>
> ', 'to_tag': '254B127C-C20', 'streams': [{'status': 'rejected', <br>
> 'caller_codec': 'Unknown', 'post_dial_delay': None, 'callee_codec':
<br>
> 'Unknown', 'start_time': 0, 'caller_bytes': 0, 'callee_bytes': 0,
<br>
> 'caller_packets': 0, 'end_time': 0, 'callee_remote': 'Unknown', <br>
> 'caller_remote': 'Unknown', 'media_type': 'video', 'callee_local':
<br>
> '90.84.16.17:50006', 'timeout_wait': 0, 'caller_local': <br>
> '90.84.16.17:50004', 'callee_packets': 0}, {'status': 'closed', <br>
> 'caller_codec': 'Unknown(13)', 'post_dial_delay': <br>
> 0.54056406021100001, 'callee_codec': 'G711u', 'start_time': 0, <br>
> 'caller_bytes': 59336, 'callee_bytes': 58800, 'caller_packets': 297,
<br>
> 'end_time': 6, 'callee_remote': '90.84.16.3:19194', 'caller_remote':
<br>
> '90.84.16.5:5166', 'media_type': 'audio', 'callee_local': <br>
> '90.84.16.17:50002', 'timeout_wait': 0, 'caller_local': <br>
> '90.84.16.17:50000', 'callee_packets': 294}], 'duration': 6, <br>
> 'to_uri': '8003@90.84.16.17', 'from_uri': 'c1p1@cust1.sipetrali.fr',
<br>
> 'callee_ua': 'Cisco-SIPGateway/IOS-12.x', 'caller_ua': 'Kapanga <br>
> Softphone Desktop 1.00/2172f <br>
> +1213709005_001CBFA9A746_001C233756B9_005056C00001_005056C00008'}<br>
><br>
> DISPATCHER / MGW1 user picks up (NOT working)<br>
> ============================================<br>
> debug: Issuing "update" command to relay at 90.84.16.17<br>
> debug: Issuing "update" command to relay at 90.84.16.17<br>
> debug: Issuing "remove" command to relay at 90.84.16.17<br>
> debug: Got statistics: {'from_tag': <br>
> 'CA3D6F5E2FF9CDAC4585370AF309F62A', 'dialog_id': None, 'start_time':
<br>
> 1245079099.1400001, 'timed_out': False, 'call_id': '1E5EC56C5A7D8879C68FB1FA02D1AA8B@cust1.sipetrali.fr
<br>
> ', 'to_tag': '1EEA090-37D', 'streams': [{'status': 'rejected', <br>
> 'caller_codec': 'Unknown', 'post_dial_delay': None, 'callee_codec':
<br>
> 'Unknown', 'start_time': 0, 'caller_bytes': 0, 'callee_bytes': 0,
<br>
> 'caller_packets': 0, 'end_time': 0, 'callee_remote': 'Unknown', <br>
> 'caller_remote': 'Unknown', 'media_type': 'video', 'callee_local':
<br>
> '90.84.16.17:50014', 'timeout_wait': 0, 'caller_local': <br>
> '90.84.16.17:50012', 'callee_packets': 0}, {'status': 'closed', <br>
> 'caller_codec': 'Unknown(13)', 'post_dial_delay': <br>
> 0.53873777389499999, 'callee_codec': 'G711u', 'start_time': 0, <br>
> 'caller_bytes': 55800, 'callee_bytes': 0, 'caller_packets': 279, <br>
> 'end_time': 5, 'callee_remote': '90.84.16.3:17994', 'caller_remote':
<br>
> '90.84.16.5:5172', 'media_type': 'audio', 'callee_local': <br>
> '90.84.16.17:50010', 'timeout_wait': 0, 'caller_local': <br>
> '90.84.16.17:50008', 'callee_packets': 0}], 'duration': 5, 'to_uri':
'8003@90.84.16.17 <br>
> ', 'from_uri': 'c1p1@cust1.sipetrali.fr', 'callee_ua': 'Cisco- <br>
> SIPGateway/IOS-12.x', 'caller_ua': 'Kapanga Softphone Desktop <br>
> 1.00/2172f <br>
> +1213709005_001CBFA9A746_001C233756B9_005056C00001_005056C00008'}<br>
<br>
<br>
From this I can already see that your problem is probably in your <br>
OpenSIPs configuration. What SHOULD happen is that any occurrence of <br>
SDP is sent to the relay. In this scenario that would be:<br>
<br>
1) The original INVITE<br>
2) The first 183<br>
3) The second 183<br>
4) The final response, 200 OK<br>
</tt></font>
<br><font size=2 face="Courier New">[ERWAN] Actually i found out that sending
an update for 183/SDP messages is worst : no media is established at all.
So i de-activated the sending of update for 183/SDP messages only, so that
only the final 200/SDP message of the answering gateway triggers an update
to the relay at the end of the call establishment, so at least one of the
call can be estabished but still not the other (this is my issue).</font>
<br><font size=2><tt><br>
Now what you are trying to do with two streams of early media is quite
<br>
weird, so between steps 1 and 4 the user placing the call could be <br>
quite confused about what it hears, since basically he/she should hear
<br>
the last gateway that sent a 183. But in the end it should be fine, as
<br>
the relay is again updated by the 200 OK, which should result in the <br>
user hearing whichever gateway picked up.<br>
</tt></font>
<br><font size=2><tt>[ERWAN]Totally agreed, this is what i was thinking
about by de-activating update for 183/SDP messages only (check my previous
remark above) : still the 200OK/SDP update of the answering gateway should
be enough for the relay to do his job.</tt></font>
<br><font size=2><tt><br>
But from your trace I can see only two update commands. I'm guessing <br>
this is from the original INVITE and the first 183. So what happens is
<br>
that the relays is locked into the RTP of whichever gateway sends it <br>
first. So getting your OpenSIPs config to send the SDP to the relay on
<br>
the seconds 183 and the 200 OK should fix this.<br>
</tt></font>
<br><font size=2><tt>[ERWAN] I guess the update of the traces belongs to
the first INVITE/SDP of the caller and the last 200OK/SDP of the called
gateway. But since i de-activate update for 183/SDP, we should have 2 updates
for one gateway (INVITE/SDP + 200OK/SDP) and only one update for the other
gateway (INVITE/SDP) which is not the case. Your explanations is clear
and i will try to tune my opensips configuration and to figure out which
update belongs to which SIP message exactly.</tt></font>
<br><font size=2><tt><br>
On the other hand, I would be curious to see if it will be fixed, as <br>
the gateway that does not pick up could continue sending RTP for a <br>
while, causing the relay to still thing this is the correct source <br>
after the OK has been sent. It's a confusing situation...<br>
</tt></font>
<br><font size=2><tt>[ERWAN]Agreed, this is a possible situation (gateway
sending RTP packets before receiving final call disconnection) since we
are using early-media but the media relay should not pay attention to it
as soon as the BYE/CANCEL is issues i guess... If RTP packets received
by the relay are the issue, i think that one of the solution would be to
de-activate SDP in 183 messages on the gateway side but i still haven't
found the solution yet.</tt></font>
<br><font size=2><tt><br>
Ruud Klaver<br>
AG Projects<br>
</tt></font>
<br>
<table><tr><td bgcolor=#ffffff><font color=#000000>*********************************<br>
This message and any attachments (the "message") are confidential and intended solely for the addressees. <br>
Any unauthorised use or dissemination is prohibited.<br>
Messages are susceptible to alteration. <br>
France Telecom Group shall not be liable for the message if altered, changed or falsified.<br>
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.<br>
********************************<br>
</font></td></tr></table>