OPTIONS request not forwarded

Hi all,

I am generating OPTIONS request from calling side to check on remote end. Something like keepalive but I want to send it from endpoint instead of configuring asterisk to send it. I could not get asterisk to forward this OPTIONS request to remote side. To every my request asterisk sends 200 OK and nothing is being send to the far end.

I am running asterisk 13.13.1 on Ubuntu 16.04 LTS.

Any thoughts?

Thanks,

Ned

Asterisk is not a SIP proxy, it doesn’t forward packets. Each leg is independent so your communication is between the endpoint and Asterisk. There’s no built in way to do such a thing.

2 Likes

If i have in “To” header destination which has registered with asterisk isn’t it suppose to forward request to the destination? That is what it does with INVITE, BYE, REFER, … pretty much any other SIP request.

It’s not forwarding the SIP request itself. The SIP request comes in, gets interpreted into a common action, given to the other side, and that side may or may not do something to reflect the action.

OK, I see what you mean.

It is probably my configuration that needs something. OPTIONS is send outside of any existing dialog and asterisk is handling it within default context. Now I have set default context to match context of the extension, before that asterisk was sending 404. Is there something else I need to configure on asterisk to get request send to its destination?

No, Asterisk can’t be configured to do so. An out of dialog OPTIONS is not something that gets turned into an action.

1 Like

OK, so if i send it within existing INVITE dialog it will be forwarded to the destination?

No, it’s still not something that gets turned into an action. It is strictly between Asterisk and the endpoint.

Wow, that is weird to me. So to header is completely ignored.

OK, maybe I can solve this from the other side. I know asterisk has qualify and qualifyfreq to control OPTIONS that it generates. Is there a way to clear the call and/or BLF when one leg in a call gets unreachable? So what I want to do is asterisk to detect if one leg becomes unreachable and to send Bye to the other leg (this should clear BLF too). Can this be done?

There is no functionality built in to do that using OPTIONS. There is only rtptimeout and session timers which can be used in a call to terminate it if RTP stops flowing or if a periodic SIP request within the call is not answered.

Cannot use rtp since it goes direct. Session-timer minimum is too long, 90 sec.

I am surprised there is no builtin solution for this kind of issue. I guess only option left is to implement some kind of demon that pools extension’s state and if it finds unreachable clears active calls.

Thanks Jcolp for clarification.

Cheers

You’ve already had the consequences of using a back to back user agent explained, but I would also add that SIP I not routed based on the To header. Routing is based on the request URI. This is similar to internet email, which is also not routed based on the To header.

Also, I don’t understand why you would want to abort a call that had a valid media path, just because there was a problem with the signalling path.

OK, but request-uri in most cases is the same as to header. In my case as well. Both urls are pointing to same resources and that is far end of the call.

I want to detect if far end is alive. We could use RTP (detect missing RTP stream) but that requires complicated changes in my case which I don’t want to do right now.