[sr-dev] [SR-Users] RLS Notify sent to wrong transport

Daniel-Constantin Mierla miconda at gmail.com
Mon Aug 3 12:56:47 CEST 2015


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 at 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 at WEBRTC_SIP_IP:WEBRTC_SIP_PORT")
> ...
> --
>
> Thank you.
>
>
>
> On Mon, Aug 3, 2015 at 12:33 PM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at 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 at gmail.com
>>     <mailto:shaheryarkh at 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 at lists.sip-router.org <mailto:sr-dev at 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 at lists.sip-router.org <mailto:sr-users at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20150803/30ca8584/attachment-0001.html>


More information about the sr-dev mailing list