[OpenSIPS-Users] Parallel forking (using registrar branching) & mediaproxy
erwan.humez at orange-ftgroup.com
erwan.humez at orange-ftgroup.com
Wed Jul 8 10:33:26 CEST 2009
Hi Ruud,
Thanks a lot for your answers.
Please find a few feedbacks below in your email...
I will try to figure out how to fix this issue in the opensips
configuration and will keep you posted in case i succeed ;-)
Anyway, thanks a lot for your patience and precious help again.
Kindly regards
Erwan.
Ruud Klaver <ruud at ag-projects.com>
30/06/2009 18:35
A
erwan.humez at orange-ftgroup.com
cc
users users <users at lists.opensips.org>
Objet
Re: [OpenSIPS-Users] Parallel forking (using registrar branching) &
mediaproxy
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.
[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.
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.
[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.
> 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
[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).
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.
[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.
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.
[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.
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...
[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.
Ruud Klaver
AG Projects
*********************************
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/20090708/de460148/attachment.htm
More information about the Users
mailing list