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 &lt;miconda(a)gmail.com > 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 &lt;shaheryarkh(a)gmail.com> >> 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 listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > -- > Daniel-Constantin Mierlahttp://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(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > >

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 &lt;miconda(a)gmail.com > 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> >> 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 &lt;shaheryarkh(a)gmail.com>> >>> 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 listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >> >> >> -- >> Daniel-Constantin Mierlahttp://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(a)lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> > > -- > Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda > Book: SIP Routing With Kamailio - http://www.asipto.com > >

yes, using set_contact_alias() fixed the problem. Many thanks and kind regards. On Wed, Aug 5, 2015 at 4:18 PM, Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt; wrote: