9 Feb
2016
9 Feb
'16
12:01 p.m.
Hi Franz,
Thanks for your response.
Even we observed in Wireshark traces, no username is included in REGISTER request. Any
changes required?
No, we are not using NATURAL in our platform.
Observed there is no communication between PCSCF – ICSCF while registration and also
attaching the tracefile(tcpdump) using command “tcpdump -i any -s 3000 -w
/var/tmp/trace_OpenIMS.pcap not port 22 and not port 3306”.
Please suggest me if I have missed anything.
Regards,
Sainath
From: Franz Edler [mailto:franz.edler@technikum-wien.at]
Sent: Tuesday, February 9, 2016 1:01 PM
To: Sainath Ellendula (NEP) <sainath.ellendula(a)wipro.com>
Cc: basitstar(a)hotmail.com; sr-users(a)lists.sip-router.org
Subject: AW: RE: Re:[SR-Users] Kamailio IMS deployment
The REGISTER request is OK. There is no username included in REGISTER request.
Regarding the mismatch: do you use NATURAL on your platform?
Next step should be a tracefile (tcpdump) and later a debug-log from the node which shows
the problem.
Von Samsung-Tablet gesendet
-------- Ursprüngliche Nachricht --------
Von: sainath.ellendula@wipro.com<mailto:sainath.ellendula@wipro.com>
Datum: 2016.02.09 08:05 (GMT+01:00)
An: franz.edler@technikum-wien.at<mailto:franz.edler@technikum-wien.at>
Cc: basitstar@hotmail.com<mailto:basitstar@hotmail.com>,
sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>
Betreff: RE: Re:[SR-Users] Kamailio IMS deployment
Hi Franz,
Please find ping status and seems good.
root@server:~# ping -c 1 hss.net1.test
PING hss.net1.test (10.0.0.9) 56(84) bytes of data.
64 bytes from server.net1.test (10.0.0.9): icmp_seq=1 ttl=64 time=0.017 ms
--- hss.net1.test ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.017/0.017/0.017/0.000 ms
root@server:~# ping -c 1 pcscf.net1.test
PING pcscf.net1.test (10.0.0.10) 56(84) bytes of data.
64 bytes from server.net1.test (10.0.0.10): icmp_seq=1 ttl=64 time=0.020 ms
--- pcscf.net1.test ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.020/0.020/0.020/0.000 ms
root@server:~# ping -c 1 icscf.net1.test
PING icscf.net1.test (10.0.0.11) 56(84) bytes of data.
64 bytes from server.net1.test (10.0.0.11): icmp_seq=1 ttl=64 time=0.018 ms
--- icscf.net1.test ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.018/0.018/0.018/0.000 ms
root@server:~# ping -c 1 scscf.net1.test
PING scscf.net1.test (10.0.0.12) 56(84) bytes of data.
64 bytes from server.net1.test (10.0.0.12): icmp_seq=1 ttl=64 time=0.017 ms
--- scscf.net1.test ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.017/0.017/0.017/0.000 ms
root@server:~#
Seems Some progress happened:
Tried register using Boghe IMS client and observed few errors:
0(1445) INFO: <script>: [REGISTER] from [sip:alice@net1.test] to
[sip:alice@net1.test]
0(1445) ERROR: <script>: REGISTER (sip:alice@net1.test (10.0.0.8:55280) to
sip:alice@net1.test, 2006cdca-0076-bacb-5010-bffa714b3cdb)
0(1445) DEBUG: <core> [parser/msg_parser.c:153]: get_hdr_field(): get_hdr_field:
cseq <CSeq>: <7994> <REGISTER>
0(1445) DEBUG: <core> [parser/msg_parser.c:187]: get_hdr_field(): DEBUG:
get_hdr_body : content_length=0
0(1445) DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 70
0(1445) DEBUG: <core> [parser/msg_parser.c:89]: get_hdr_field(): found end of
header
0(1445) DEBUG: sanity [mod_sanity.c:248]: w_sanity_check(): sanity checks result: 1
0(1445) DEBUG: siputils [checks.c:97]: has_totag(): no totag
0(1445) DEBUG: <core> [select.c:412]: run_select(): Calling SELECT 0x7fb548dd2400
0(1445) DEBUG: tm [t_lookup.c:1011]: t_check_msg(): DEBUG: t_check_msg: msg id=2 global
id=1 T start=0xffffffffffffffff
0(1445) DEBUG: tm [t_lookup.c:466]: t_lookup_request(): t_lookup_request: start searching:
hash=65064, isACK=0
0(1445) DEBUG: tm [t_lookup.c:424]: matching_3261(): DEBUG: RFC3261 transaction matching
failed
0(1445) DEBUG: tm [t_lookup.c:648]: t_lookup_request(): DEBUG: t_lookup_request: no
transaction found
0(1445) DEBUG: tm [t_lookup.c:1080]: t_check_msg(): DEBUG: t_check_msg: msg id=2 global
id=2 T end=(nil)
0(1445) DEBUG: sl [sl.c:280]: send_reply(): reply in stateless mode (sl)
0(1445) DEBUG: siputils [checks.c:97]: has_totag(): no totag
0(1445) DEBUG: tm [t_lookup.c:1011]: t_check_msg(): DEBUG: t_check_msg: msg id=2 global
id=2 T start=(nil)
0(1445) DEBUG: tm [t_lookup.c:1086]: t_check_msg(): DEBUG: t_check_msg: T previously
sought and not found
0(1445) DEBUG: ims_registrar_pcscf [save.c:273]: save_pending(): contact requesting to
expire in 600000 seconds
0(1445) DEBUG: ims_usrloc_pcscf [usrloc.c:106]: get_alias_host_from_contact(): no alias
param
0(1445) DEBUG: ims_usrloc_pcscf [usrloc.c:155]: get_hash_slot(): using host for hash
[10.0.0.8]
0(1445) DEBUG: ims_usrloc_pcscf [usrloc.c:159]: get_hash_slot(): Returning hash slot:
[167]
0(1445) DEBUG: ims_usrloc_pcscf [udomain.c:465]: get_pcontact(): Searching for contact in
P-CSCF usrloc [sip:alice@10.0.0.8:55280;transport=udp]
0(1445) DEBUG: ims_usrloc_pcscf [usrloc.c:106]: get_alias_host_from_contact(): no alias
param
0(1445) DEBUG: ims_usrloc_pcscf [usrloc.c:183]: get_aor_hash(): using host for hash
[10.0.0.8]
0(1445) DEBUG: ims_usrloc_pcscf [usrloc.c:187]: get_aor_hash(): Returning hash slot:
[1662767783]
0(1445) DEBUG: ims_usrloc_pcscf [udomain.c:483]: get_pcontact(): Comparing needle
user@host:port [alice@10.0.0.8:55280] and contact_user@contact_host:port
[alice@10.0.0.8:51219]
0(1445) DEBUG: ims_usrloc_pcscf [udomain.c:494]: get_pcontact(): Searching for
[sip:alice@10.0.0.8:55280;transport=udp] and comparing to
[sip:alice@10.0.0.8:51219;transport=udp]
0(1445) DEBUG: ims_usrloc_pcscf [udomain.c:553]: get_pcontact(): Port don't match:
51219 (contact) 51219 (received) != 55280!
0(1445) DEBUG: ims_registrar_pcscf [save.c:310]: save_pending(): Adding pending pcontact:
<sip:alice@10.0.0.8:55280;transport=udp>
0(1445) DEBUG: ims_usrloc_pcscf [pcontact.c:132]: new_pcontact(): New contact
[<sip:alice@10.0.0.8:55280;transport=udp>] with 0 associated IMPUs in state:
[registration pending]
0(1445) DEBUG: ims_registrar_pcscf [save.c:314]: save_pending(): registering for UL
callback
0(1445) DEBUG: ims_usrloc_pcscf [usrloc.c:106]: get_alias_host_from_contact(): no alias
param
Please guide me for any more changes has to be done, As observed in Wireshark(Register
request from 10.0.0.8(host)-PCSCF as REGISTER sip:net1.test SIP/2.0). I think the register
request should sent as REGISTER sip:alice@net1.test SIP/2.0
Thanks in advance!!
Regards,
Sainath
From: Franz Edler [mailto:franz.edler@technikum-wien.at]
Sent: Tuesday, February 9, 2016 3:00 AM
To: Sainath Ellendula (NEP)
<sainath.ellendula@wipro.com<mailto:sainath.ellendula@wipro.com>>
Cc: basitstar@hotmail.com<mailto:basitstar@hotmail.com>;
sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>
Subject: RE: Re:[SR-Users] Kamailio IMS deployment
Sainath,
what was the result for ping on
- icsct.net1.test
- scscf.net1.test
- hss.net1.test
to increase debug level you have to modify the corresponding cfg-file, e.g.
kamailio-icscf.cfg in line 35: debug=2
Just increase to debug=3 and then start the process again.
BR Franz
The information contained in this electronic message and any attachments to this message
are intended for the exclusive use of the addressee(s) and may contain proprietary,
confidential or privileged information. If you are not the intended recipient, you should
not disseminate, distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments. WARNING: Computer viruses can be
transmitted via email. The recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage caused by any virus
transmitted by this email. www.wipro.com<http://www.wipro.com>
The information contained in this electronic message and any attachments to this message
are intended for the exclusive use of the addressee(s) and may contain proprietary,
confidential or privileged information. If you are not the intended recipient, you should
not disseminate, distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments. WARNING: Computer viruses can be
transmitted via email. The recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage caused by any virus
transmitted by this email. www.wipro.com
9 Feb
9 Feb
4:20 p.m.
New subject: Kamailio IMS deployment
HI,
Even we observed in Wireshark traces, no username is
included in REGISTER
request. Any changes required?
No, we are not using NATURAL in our platform.
The "NATURAL" has been an automatic spell checking of my tablet. It should have
been "NAT".
Observed there is no communication between PCSCF –
ICSCF while
registration and also attaching the tracefile(tcpdump) using command
“tcpdump -i any -s 3000 -w /var/tmp/trace_OpenIMS.pcap not port 22 and
not port 3306”.
As you can see in the trace: The P-CSCF forwards the REGISTER request to 10.0.0.9 which is
not the I-CSCF (and not prepared to receive such messages).
You should check the forwarding to I-CSCF in kamailio-pcscf.cfg.
Next time you should start with the trace also at startup of the x-CSCF to see that the
Diameter connections are up and running.
BR Franz
10 Feb
10 Feb
2:32 p.m.
New subject: Kamailio IMS deployment
Hi Franz,
Thanks for your response.
We are not using "NAT" in our network instead of that using
"Bridged".
As communication is not happening from P-SCF to I-CSCF, I don't see anything like
forwarding to I-CSCF in kamailio-pcscf.cfg. Here do we have anything files like pcscf.xml
as it is not available by default.
One more thing observed in tcpdump, In DNS answer getting IP of
server.net1.test(10.0.0.9), This might be issue that REGISTER request is trying to
communicate with 10.0.0.9 instead of 10.0.0.11(I-CSCF). Please any suggestions.
Please find attachments of Tcpdump, kamailio-pcscf.cfg and pcscf.cfg.
Thanks in advance!!
Regards,
Sainath
-----Original Message-----
From: Franz Edler [mailto:franz.edler@technikum-wien.at]
Sent: Tuesday, February 9, 2016 8:50 PM
To: Sainath Ellendula (NEP) <sainath.ellendula(a)wipro.com>
Cc: basitstar(a)hotmail.com; sr-users(a)lists.sip-router.org
Subject: RE: Re:[SR-Users] Kamailio IMS deployment
HI,
Even we observed in Wireshark traces, no username is
included in
REGISTER request. Any changes required?
No, we are not using NATURAL in our platform.
The "NATURAL" has been an automatic spell checking of my tablet. It should have
been "NAT".
Observed there is no communication between PCSCF –
ICSCF while
registration and also attaching the tracefile(tcpdump) using command
“tcpdump -i any -s 3000 -w /var/tmp/trace_OpenIMS.pcap not port 22 and
not port 3306”.
As you can see in the trace: The P-CSCF forwards the REGISTER request to 10.0.0.9 which is
not the I-CSCF (and not prepared to receive such messages).
You should check the forwarding to I-CSCF in kamailio-pcscf.cfg.
Next time you should start with the trace also at startup of the x-CSCF to see that the
Diameter connections are up and running.
BR Franz
The information contained in this electronic message and any attachments to this message
are intended for the exclusive use of the addressee(s) and may contain proprietary,
confidential or privileged information. If you are not the intended recipient, you should
not disseminate, distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments. WARNING: Computer viruses can be
transmitted via email. The recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage caused by any virus
transmitted by this email. www.wipro.com
11 Feb
11 Feb
6:26 p.m.
New subject: Kamailio IMS deployment
Hi,
One more thing observed in tcpdump, In DNS answer
getting IP of
server.net1.test(10.0.0.9), This might be issue that REGISTER request is trying
to communicate with 10.0.0.9 instead of 10.0.0.11(I-CSCF). Please any
suggestions.
Yes, of course. That is the reason.
When the register request is processed by P-CSCF if forwards the request to an inbound
proxy server of the target domain, and that is exactly the I-CSCF.
You have to modify the DNS entries for resolving the SIP domain accordingly.
I have quickly modified the zone-files for you. That should work now.
BR Franz
12 Feb
12 Feb
10:45 a.m.
New subject: Kamailio IMS deployment
Hi Franz,
Thanks a lot for your support.
It's working fine with given zone-files.
Now, I could able to setup a call between two users, Please find attachment of tcpdump.
Small clarification, I have started capturing of tcpdump before starting of other
components including hss. But I don't see any diameter messages in Wireshark
traces(tcpdump).
Tcpdump traces call flow seems correct whereas same thing I was captured from my windows
machine, Here call has been established but don't see call flow travels from different
IPs.
Please find attachment of tcpdump and window machine Wireshark traces.
Any suggestion would be very helpful.
Thanks in advance!!
Regards,
Sainath
-----Original Message-----
From: Franz Edler [mailto:franz.edler@technikum-wien.at]
Sent: Thursday, February 11, 2016 10:57 PM
To: Sainath Ellendula (NEP) <sainath.ellendula(a)wipro.com>
Cc: basitstar(a)hotmail.com; sr-users(a)lists.sip-router.org
Subject: RE: Re:[SR-Users] Kamailio IMS deployment
Hi,
One more thing observed in tcpdump, In DNS answer
getting IP of
server.net1.test(10.0.0.9), This might be issue that REGISTER request
is trying to communicate with 10.0.0.9 instead of 10.0.0.11(I-CSCF).
Please any suggestions.
Yes, of course. That is the reason.
When the register request is processed by P-CSCF if forwards the request to an inbound
proxy server of the target domain, and that is exactly the I-CSCF.
You have to modify the DNS entries for resolving the SIP domain accordingly.
I have quickly modified the zone-files for you. That should work now.
BR Franz
The information contained in this electronic message and any attachments to this message
are intended for the exclusive use of the addressee(s) and may contain proprietary,
confidential or privileged information. If you are not the intended recipient, you should
not disseminate, distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments. WARNING: Computer viruses can be
transmitted via email. The recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage caused by any virus
transmitted by this email. www.wipro.com
6:21 p.m.
New subject: Kamailio IMS deployment
Hi Sainath,
It's working fine with given zone-files.
Now, I could able to setup a call between two users, Please find attachment
of tcpdump.
Thats fine and congratulation.
Small clarification, I have started capturing of
tcpdump before starting of
other components including hss. But I don't see any diameter messages in
Wireshark traces(tcpdump).
That is caused by the fact that the 3 involved diameter nodes (HSS, I-CSCF and S-CSCF) use
3 different ports for Diameter (3868, 3869 and 3870).
Only port 3868 is the assigned port number to Diameter, the other two port numbers (3869
and 3870) are not.
The reason for this is a historic one. The OpenIMSCore platform used one common IP-address
for all tree nodes and therefore different port-numbers had to be used.
Wireshark has limited possibilities to automatically detect the protocol behind a stream
when port numbers deviating from the assigned ones are used.You have to tell that to
Wireshark.
Just take the two packets (#10 and #17) and in your tracefile trace_12_2_2016_12.pcap
and tell Wireshark "decode as Diameter" and you will see what you might have
expected.
In your case, where you now succeeded to split the platform with different IP-addresses
this constraint has gone.
There is no reason to not use the same "assigned" port number 3868 for all three
nodes. This could be the next challenge for you to reconfigure.
I have also added a message diagram produced with sip-scenario generator which helps a lot
in debugging. Just extract both html files and open the one with the shorter filename
(trace_12_2_2016_12_index.html).
The sip-scenario generator is an open-source-tool but unfortunately with no support
anymore. But it is really helpful.
If you are interested I can provide the tool.
BR
Franz
15 Feb
15 Feb
8:10 a.m.
New subject: Kamailio IMS deployment
Hi Franz,
Thanks a lot for your support.
Traces decoded with diameter and could able to see the messages correctly.
Yes, I am interested to capture traces using sip-scenario generator tool. Can you please
provide that tool.
Somewhere I have read in Kamailio forum that, Call setup has successful happened using
"Boghe IMS client" and " Mercuro-Silver".
Currently We are trying to automate the basic call scenario using Boghe IMS client, It
would be better if you can provide "Mercuro-Silver", So that call can be
established between two different IMS Client. Tried finding in google for
"Mercuro-Silver" but couldn't get it.
Thanks in advance!!
Regards,
Sainath
-----Original Message-----
From: Franz Edler [mailto:franz.edler@technikum-wien.at]
Sent: Friday, February 12, 2016 10:51 PM
To: Sainath Ellendula (NEP) <sainath.ellendula(a)wipro.com>
Cc: basitstar(a)hotmail.com; sr-users(a)lists.sip-router.org
Subject: RE: Re:[SR-Users] Kamailio IMS deployment
Hi Sainath,
It's working fine with given zone-files.
Now, I could able to setup a call between two users, Please find
attachment of tcpdump.
Thats fine and congratulation.
Small clarification, I have started capturing of
tcpdump before
starting of other components including hss. But I don't see any
diameter messages in Wireshark traces(tcpdump).
That is caused by the fact that the 3 involved diameter nodes (HSS, I-CSCF and S-CSCF) use
3 different ports for Diameter (3868, 3869 and 3870).
Only port 3868 is the assigned port number to Diameter, the other two port numbers (3869
and 3870) are not.
The reason for this is a historic one. The OpenIMSCore platform used one common IP-address
for all tree nodes and therefore different port-numbers had to be used.
Wireshark has limited possibilities to automatically detect the protocol behind a stream
when port numbers deviating from the assigned ones are used.You have to tell that to
Wireshark.
Just take the two packets (#10 and #17) and in your tracefile trace_12_2_2016_12.pcap
and tell Wireshark "decode as Diameter" and you will see what you might have
expected.
In your case, where you now succeeded to split the platform with different IP-addresses
this constraint has gone.
There is no reason to not use the same "assigned" port number 3868 for all three
nodes. This could be the next challenge for you to reconfigure.
I have also added a message diagram produced with sip-scenario generator which helps a lot
in debugging. Just extract both html files and open the one with the shorter filename
(trace_12_2_2016_12_index.html).
The sip-scenario generator is an open-source-tool but unfortunately with no support
anymore. But it is really helpful.
If you are interested I can provide the tool.
BR
Franz
The information contained in this electronic message and any attachments to this message
are intended for the exclusive use of the addressee(s) and may contain proprietary,
confidential or privileged information. If you are not the intended recipient, you should
not disseminate, distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments. WARNING: Computer viruses can be
transmitted via email. The recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage caused by any virus
transmitted by this email. www.wipro.com
17 Feb
17 Feb
7:32 a.m.
New subject: Kamailio IMS deployment
Hi Franz,
Could you please share the SIP generator .
Thank you so much in advance.
Regards,
-kranti
On Mon, Feb 15, 2016 at 12:40 PM, <sainath.ellendula(a)wipro.com> wrote:
Hi Franz,
Thanks a lot for your support.
Traces decoded with diameter and could able to see the messages correctly.
Yes, I am interested to capture traces using sip-scenario generator tool.
Can you please provide that tool.
Somewhere I have read in Kamailio forum that, Call setup has successful
happened using "Boghe IMS client" and " Mercuro-Silver".
Currently We are trying to automate the basic call scenario using Boghe
IMS client, It would be better if you can provide "Mercuro-Silver", So that
call can be established between two different IMS Client. Tried finding in
google for "Mercuro-Silver" but couldn't get it.
Thanks in advance!!
Regards,
Sainath
-----Original Message-----
From: Franz Edler [mailto:franz.edler@technikum-wien.at]
Sent: Friday, February 12, 2016 10:51 PM
To: Sainath Ellendula (NEP) <sainath.ellendula(a)wipro.com>
Cc: basitstar(a)hotmail.com; sr-users(a)lists.sip-router.org
Subject: RE: Re:[SR-Users] Kamailio IMS deployment
Hi Sainath,
It's working fine with given zone-files.
Now, I could able to setup a call between two users, Please find
attachment of tcpdump.
Thats fine and congratulation.
Small clarification, I have started capturing of
tcpdump before
starting of other components including hss. But I don't see any
diameter messages in Wireshark traces(tcpdump).
That is caused by the fact that the 3 involved diameter nodes (HSS, I-CSCF
and S-CSCF) use 3 different ports for Diameter (3868, 3869 and 3870).
Only port 3868 is the assigned port number to Diameter, the other two port
numbers (3869 and 3870) are not.
The reason for this is a historic one. The OpenIMSCore platform used one
common IP-address for all tree nodes and therefore different port-numbers
had to be used.
Wireshark has limited possibilities to automatically detect the protocol
behind a stream when port numbers deviating from the assigned ones are
used.You have to tell that to Wireshark.
Just take the two packets (#10 and #17) and in your tracefile
trace_12_2_2016_12.pcap and tell Wireshark "decode as Diameter" and you
will see what you might have expected.
In your case, where you now succeeded to split the platform with different
IP-addresses this constraint has gone.
There is no reason to not use the same "assigned" port number 3868 for all
three nodes. This could be the next challenge for you to reconfigure.
I have also added a message diagram produced with sip-scenario generator
which helps a lot in debugging. Just extract both html files and open the
one with the shorter filename (trace_12_2_2016_12_index.html).
The sip-scenario generator is an open-source-tool but unfortunately with
no support anymore. But it is really helpful.
If you are interested I can provide the tool.
BR
Franz
The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s) and
may contain proprietary, confidential or privileged information. If you are
not the intended recipient, you should not disseminate, distribute or copy
this e-mail. Please notify the sender immediately and destroy all copies of
this message and any attachments. WARNING: Computer viruses can be
transmitted via email. The recipient should check this email and any
attachments for the presence of viruses. The company accepts no liability
for any damage caused by any virus transmitted by this email.
www.wipro.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
9:34 p.m.
New subject: Kamailio IMS deployment
Hi, again
Thanks a lot for your support.
Yes, I am interested to capture traces using sip-scenario generator tool. Can
you please provide that tool.
I have provided it at
https://www.dropbox.com/s/nqay103s2rmnffq/sip_scenario.v1.2.7.zip?dl=0 .
Somewhere I have read in Kamailio forum that, Call
setup has successful
happened using "Boghe IMS client" and " Mercuro-Silver".
Currently We are trying to automate the basic call scenario using Boghe IMS
client, It would be better if you can provide "Mercuro-Silver", So that call
can
be established between two different IMS Client. Tried finding in google for
"Mercuro-Silver" but couldn't get it.
Mercuro Silver was a commercial IMS client provided by a company "Inexbee" which
unfortunately does not exist anymore.
The company offered 3 clients Mercure bronce, silver and gold. The Mercuro bronce was the
free one.
I have saved it here:
https://www.dropbox.com/s/0pjmhi44c8blbyd/Mercuro%20IMS%20Client%20Bronze%2…
and here is the data sheet:
https://www.dropbox.com/s/81rleqfsvhyeqbc/Mercuro_Datasheet_V1R01.pdf?dl=0
The chief development engineer at Inexbee meanwhile has founded https://www.doubango.org/
with the client you are already using.
BR Franz
3014
days inactive
3022
days old
8 comments
3 participants
participants (3)
-
Franz Edler -
Kranti Kumar -
sainath.ellendula＠wipro.com