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 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

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@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:

...

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
<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@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@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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 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:

...

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@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:

...

    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
    <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@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@lists.sip-router.org
    <mailto: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://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com

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@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:

...

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 <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:

...

    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@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:

...

        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 <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@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@lists.sip-router.org
        <mailto: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://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