7 Aug
2015
7 Aug
'15
9 a.m.
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(a)gmail.com <mailto:miconda@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:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
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:
--
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
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:
--
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
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