Use set_contact_alias()/handle_uri_alias() instead of fix_nated_contact().
Cheers,
Daniel
On 03/08/15 13:49, M S wrote:
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@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.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.
--
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 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@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@gmail.com> wrote:
(X.X.X.X is server IP and Y.Y.Y.Y is end user IP).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)
--
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla http://twitter.com/#!/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@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com