search

OpenSIPS / opensips

OpenSIPS is a GPL implementation of a multi-functionality SIP Server that targets to deliver a high-level technical solution (performance, security and quality) to be used in professional SIP server platforms.
https://opensips.org
Other
1.28k stars 581 forks source link

[FEATURE] NAT Helper Ping #2165

Closed volga629-1 closed 1 year ago

volga629-1 commented 4 years ago

Opensips 3.1-dev

Hello Everyone, Based on this conversation

https://groups.google.com/forum/#!topic/jssip/1D3n2_MJrf8

Opensips is not set user name portion in request uri for NAT helper OPTIONS packet. I found RFC for proxy layer that user name portion is not required, but I can't find any information about UA.

Is possible clarify what behavior should be for UA.

RFC

  The target of the OPTIONS request is identified by the Request-URI,
   which could identify another UA or a SIP server.  If the OPTIONS is
   addressed to a proxy server, the Request-URI is set without a user
   part, similar to the way a Request-URI is set for a REGISTER request.

keepalive

stale[bot] commented 4 years ago

Any updates here? No progress has been made in the last 15 days, marking as stale. Will close this issue if no further updates are made in the next 30 days.

razvancrainea commented 4 years ago

Hi, Volga!

The OPTIONS messages the nat pinger module is sending are only sent with the purpose of keeping the NAT pinhole up, they are not actually targeted OPTION messages to a user. That's why the user is missing. Feel free to switch this to a feature request in case this is a behavior you need.

Best regards, Răzvan

volga629-1 commented 4 years ago

@razvancrainea Thank you for reply. Yes, that feature request. Idea to have mod parameter which will allow add username in case ping goes to UA.

Example:


modparam("nathelper", "ping_proxy_only", 1)
digipigeon commented 4 years ago

+1 on this feature request, it would be very useful when using sip.js with SIP Ping.

InnovateAsterisk commented 2 years ago

I would also like to upvote this feature request.

I'm using OpenSIPS with webrtc, and when the connection is made from the browser to OpenSIPS there would not be any proxy servers on route, so no need for nat ping, however the websocket can close after the timeout period. Some sort of ping/options is very useful especially since it is often server-to-client, and even better that the client can respond with a correct response so that OpenSIPS knows the client javascript is responsive and working.

Further, I believe this becomes the responsibility of the registrar module to keep the registrations active and responsive (since this is now not a nat feature), so I propose these features be copied to the registrar module. (Similar to the way Asterisk can qualify an endpoint.) Having the feature in both registrar and nathelper modules means they could be used for their respective uses, where say for example registered endpoints get an options message with a username and contact via and registrar module, and nathelper just sends the sipping to keep nat connections alive.

bogdan-iancu commented 2 years ago

@InnovateAsterisk , the nathelper module is performing OPTION;s based pinging to the registered contact, so there is no need to copy anything into the registrar module - the nathelper IS taking the destination to be pinged from the registrar module.

I think the discussion here is about adding a username part also to the RURI in the OPTION requests.

InnovateAsterisk commented 2 years ago

I think the discussion here is about adding a username part also to the RURI in the OPTION requests.

@bogdan-iancu Isn't there a route option for this, that I can add my own $rU based on my own conditions, rather than making up some kind of hard rule here. I just checked "local_route", but the message doesn't appear there. I can't seem to find the OPTIONS messages (when generated from sipping) in any of the routes.

palmtown commented 1 year ago

+1 - At minimum, should have an option to include the user to allow for a correct response from the client to be sent.

palmtown commented 1 year ago

Hello Community,

Please note that in that section of the RFC 3261 at , https://www.rfc-editor.org/rfc/rfc3261#section-11.2 , it states:

The response to an OPTIONS is constructed using the standard rules for a SIP response as discussed in Section 8.2.6. The response code chosen MUST be the same that would have been chosen had the request been an INVITE.

Therefore, given the absence of the correct RURI in the OPTIONS request, any client that is in compliance with RFC 3261 would respond with 404 or alike as it would for an incorrect INVITE. Therefore, wouldn't OpenSIPS not be following RFC 3261 if it is constructing an OPTIONS request not following the standard rules for a SIP request such as an INVITE?

Shkiperon commented 1 year ago

Hello everyone. I looked at list of commits in OpenSIPS 3.4 (released few days ago) and found commit https://github.com/OpenSIPS/opensips/commit/dbc36057be709daaaec576e7d9ea501b609bc7d7 with fix. I have tested this issue (I saw it many times, so I know how to reproduce it) on OpenSIPS 3.4 built from source (in build options I disabled HP_MALLOC because there was an error with incorrect code usage on compile stage) and looks like it really fixed.

Can someone make some tests to confirm too?

vladpaiu commented 1 year ago

Closed via https://github.com/OpenSIPS/opensips/commit/dbc36057be709daaaec576e7d9ea501b609bc7d7