I am trying to understand how Asterisk handles an INVITE that does not contain an OFFER (i.e., the SDP body is NULL), to enable a third-party click-to-call functionality (just to provide you a brief overview of the intended application).
Network capturing (done using Wireshark) seemed to indicate that even without an explicitly defined OFFER in the initial INVITE, the SDP body contains default media codecs (specifically, for audio and video). In this context, I was wondering if Asterisk automatically assigns these default media codecs when the OFFER is empty? Further, would it be possible to change this default behavior (i.e., to maintain NULL in the SDP offer).
Cheers, Sai
PS. Will post more information should you need them
Let me attempt to rephrase my query as I feel that there’s some ambiguity in my original post. The underlying idea is to send an INVITE from Asterisk to a given client without an SDP OFFER. This sort of functionality is particularly useful in the aforementioned click-to-call applications where it is improbable to predict the codecs supported by the client. Further, it also provides an opportunity for the client to decide the order of these media codecs in the OFFER.
From what I understand, some other PBX systems such as the one from broadsoft, would allow this particular functionality.
There is no functionality built in to achieve that. The SIP channel drivers always include an SDP in the initial INVITE. Support would need to be added.
What you are describing is called late offer, and is done by Cisco products, but only under some circumstances. Asterisk only attempts to support it as a server, not as a client.
I am also looking for a way to get INVITE without SDP from asterisk when call is initiated using click-to-call. Is there configuration that will allow me to get this?
To me that is something asterisk developers should have high on priority list. Asterisk should not be sending offer when trying to initiate call between two endpoints since it has no clue what endpoints support. With current implementation for click-to-call I’ll have to accept whatever SDP I get and then re-invite to update media as soon as possible.
I think you are misunderstanding how the call origination is working here, Asterisk isn’t initiating a call between two endpoints, It’s originating two different calls each call is from the PBX to an endpoint.
The first call is from the PBX to your first endpoint, and The second call from the PBX to your second endpoint. Assuming you are handling media the calls are then bridged internally, Asterisk isn’t a Proxy it’s a B2BUA.
In your endpoint definition you configure asterisk as to what codecs to support on the calls to it.
OK, asterisk is b2bua, so it generates SDP offer with audio and video media stream. What should I do if my application does not want to use “video” but it needs “text”, “application”, or “message” media stream. I’ll have to accept initial invite and then update as soon as possible. Isn’t it easier to send invite without offer and let endpoint to send offer in 200?
Asterisk has to support each of those media streams in the first place, and it has only recently gained the ability to renegotiate in the first place. As for being high priority - Asterisk is an open source project. Everyone has their own motivations and what they would like to see in it, and what they create and contribute is what shapes Asterisk.
Asterisk is not a SIP PABX, it is a multi-protocol PABX, where the A side and B side can be completely different. Whilst there are already layering violations (in particular direct media support), looking at what is being negotiated on the other side involves Asterisk in breaking the layering that gives it its protocol independence.
You are asking for someone to put man months into something, which in spite of your views, is not a commonly perceived requirement. In fact the trouble you had in getting across the requirement reflects the fact that I don’t think I’ve ever seen anyone asking about it before.
My guess is, unless you contribute the code yourself, it is not going to happen.
Patches need to be submitted through a formal process. That used to be via issues.asterisk.org. That may still be the case, or there may be a two stage process.
The key point is that patches are only accepted if the submitter has agreed to a contributor agreement. That agreement gives Digium certain rights that go beyond the open source licence.