I’m using the MessageSend() command to reply to an incoming SIP MESSAGE. The sip debug shows that my reply uses a different “Call-ID:” than the incoming message. This seems to cause my messages to be listed in a different dialogue (for example in CSIPSimple) or to be discarded rightaway (for example in Jitsi).
I can verbose the “Call-ID” of the incoming message using MESSAGE_DATA(Call-ID). According to the docs it should be possible to use the same command to set the “Call-ID” for the outgoing messages:
same => n,Set(MESSAGE_DATA(CallID)=${MESSAGE_DATA(Call-ID)})
This however fails. How can I successfully set the “Call-ID”?
The SIP MESSAGE requests generated by MessageSend are for out of dialog messaging. The notion of attempting to create some form of pseudo-session by forming a dialog was never part of its design. As a result, you may run into a large number of problems trying to use it for that purpose.
You are setting CallID, as opposed to Call-ID. I would expect the data that you set to show up in the CallID header, as opposed to the SIP Call-ID. A SIP debug would illustrate this.
You can try setting Call-ID, but it’s quite possible that chan_sip will overwrite this with the Call-ID it generated and stored on the SIP pvt. Again, sending MESSAGE requests was always for out of call message sending, which would have a different Call-ID for each MESSAGE request that is sent.
The missing dash in “Call-ID” is a typo. In my dialplan it was always same => n,Set(MESSAGE_DATA(Call-ID)=${MESSAGE_DATA(Call-ID)}). The behavious is as you said:
setting “CallID” --> appears in header
setting “Call-ID”–> overwritten by chan_sip, chan_sip generates its own globally unique identifier
I see no reason why chan_sip should not allow this field to be set manually. Yes, this was never designed for a session but SIP MESSAGES are more like asynchronous communication anyway. You can save the “Call-ID” and resume the same “dialogue” anytime given that the peer is online.Which makes it even more essential to properly reuse the “Call-ID”.
If you feel that way, you’re more than welcome to write a patch that does this. Given the complexity of the code in chan_sip, a test would be appreciated as well to verify that there are no regressions with the existing behavior.
Call-ID is critical to the protocol. Also, if you set it manually, how can you be sure it is unique in time and space? You are basically trying to implement something in dialplan space which should be totally under control of the channel driver.