Ah OK, i see the issue now. The contact is
"sip:<user-id>@<domain>",
which is changed by NATHelper to "sip:<user-id>@<received
address>".
Since user is a webrtc end-point so it can never send me correct
contact header, therefore i have to tweak things in NATMANAGE route.
Is that correct, or is there anything else possible?
Thank you.
On Mon, Aug 3, 2015 at 12:56 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Look at the trace when the SUBSCRIBE is handled, because the R-URI
in NOTIFY is the Contact from SUBSCRIBE.
Cheers,
Daniel
On 03/08/15 12:51, M S wrote:
Yes in sip trace i do see notify being sent
using udp transport
rather then tls.
--
U 2015/08/03 10:30:53.213962 X.X.X.X:5060 -> Y.Y.Y.Y:57526
NOTIFY sip:1234567890@Y.Y.Y.Y:57526 SIP/2.0
...
--
I also notice that R-URI domain part is destination user's IP,
instead of his/her domain, which i am afraid would be rejected by
destination user if it ever get there.
I am not using force send socket anywhere for presence. The
event_route[tm:local-request] just does some xlog. This xlog
appears AFTER the send socket warning in kamailio logs (so i
guess it is already too late to using force send socket anyway).
Here are the presence modules params,
--
...
# ----- presence params -----
modparam("presence", "waitn_time", 10)
modparam("presence", "subs_db_mode", 2)
modparam("presence", "fetch_rows", 1024)
modparam("presence", "clean_period", 30)
modparam("presence", "db_update_period", 30)
modparam("presence", "notifier_processes", 4)
modparam("presence", "db_table_lock_type", 0)
modparam("presence", "db_url", "WEBRTC_DBURL")
modparam("presence", "timeout_rm_subs", 0)
modparam("presence", "expires_offset", 10)
modparam("presence", "local_log_level", 3)
modparam("presence", "pres_htable_size", 12)
modparam("presence", "subs_htable_size", 12)
modparam("presence", "max_expires", WEBRTC_SIP_MAX_EXPIRE)
# ----- presence_xml params -----
modparam("presence_xml", "force_active", 1)
modparam("presence_xml", "db_url", "WEBRTC_DBURL")
modparam("presence_xml", "integrated_xcap_server", 1)
# ----- xcap_server params -----
modparam("xcap_server", "db_url", "WEBRTC_ALT_DBURL")
modparam("xcap_server", "buf_size", 65536)
# ----- pua params -----
modparam("pua", "db_mode", 2)
modparam("pua", "fetch_rows", 1024)
modparam("pua", "update_period", 30)
modparam("pua", "db_url", "WEBRTC_DBURL")
modparam("pua", "hash_size", 12)
modparam("pua", "check_remote_contact", 0)
modparam("pua", "min_expires", WEBRTC_SIP_MIN_EXPIRE)
modparam("pua", "default_expires", WEBRTC_SIP_DEFAULT_EXPIRE)
# ----- rls params -----
# only enable for distributed setup
modparam("rls", "db_mode", 2)
modparam("rls", "waitn_time", 10)
modparam("rls", "fetch_rows", 1024)
modparam("rls", "clean_period", 30)
modparam("rls", "notifier_processes", 4)
modparam("rls", "db_url", "WEBRTC_DBURL")
modparam("rls", "hash_size", 12)
modparam("rls", "to_presence_code", 10)
modparam("rls", "integrated_xcap_server", 1)
modparam("rls", "disable_remote_presence", 1)
modparam("rls", "rls_event", "presence;winfo")
modparam("rls", "max_expires", WEBRTC_SIP_MAX_EXPIRE)
modparam("rls", "server_address",
"sip:rls@WEBRTC_SIP_IP:WEBRTC_SIP_PORT")
...
--
Thank you.
On Mon, Aug 3, 2015 at 12:33 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
can you look at SIP trace and see what is the Contact address
of the subscription? You can use ngrep to sniff on port 5060
(for tcp) on kamailio server.
Also, are you using and routing enforcement for NOTIFY (e.g.,
you have a chain of proxies or use
event_route[tm:local-request] with force send socket)?
Having the parameters for presence, rls and pua modules might
be helpful to spot what is wrong.
Cheers,
Daniel
On 03/08/15 12:28, M S wrote:
Any ideas anyone?
I have updated the Kamailio to v4.3.1 Rev.4717b5, still the
same issue.
Thank you.
On Fri, Jul 31, 2015 at 7:36 PM, M S <shaheryarkh(a)gmail.com
<mailto:shaheryarkh@gmail.com>> wrote:
Hi,
I have a Kamailio v4.3.0 with SVN Rev. c6aa95 running an
RLS based presence setup. Everything works fine when
end-user has UDP transport, however, if user has TCP or
TLS transport then i aggregated NOTIFY sent by RLS gives
send error,
--
WARNING: <core> [forward.c:231]: get_send_socket2():
protocol/port mismatch (forced tls:X.X.X.X:5061, to
udp:Y.Y.Y.Y:12345)
--
(X.X.X.X is server IP and Y.Y.Y.Y is end user IP).
Not sure if it is configuration issue or some bug, so
posting it to both mailing list.
Please help.
Thank you.
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -
http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio -
http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users