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

Daniel-Constantin Mierla miconda at gmail.com
Fri Aug 7 09:00:03 CEST 2015


Great!

Daniel

On 05/08/15 18:31, M S wrote:
> 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
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     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 at gmail.com <mailto:miconda at 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 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://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda
>>         Book: SIP Routing With Kamailio - http://www.asipto.com
>>
>>
>
>     -- 
>     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
>
>

-- 
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-users/attachments/20150807/e35056de/attachment.html>


More information about the sr-users mailing list