SIP Messages are discarded to send when we try to send succesive SIP INFO messages

[keremcadirci]

When we want to successively send SIP INFO (DTMF) messages, the first message is sent but those who continue are missed,

The reason is that the TransactionID (SIPTransaction.GetRequestTransactionId) is calculated from Branch and CSeqMethod, therefor the successive SIP INFO messages are discarded.

Our Proposal is to add Header.Cseq into SIPTransaction.GetRequestTransactionId calculation.

[sipsorcery]

I don't think this will work. It's been too long but but for invites I have a vague recollection the transaction logic needs to be able to match different CSeq values.

But that aside why is the branch ID not changing? That should be different for every new INFO request.

[sipsorcery]

I've refamiliarised myself with the SIP transaciton logic and it's not just a matter of adding extra properties to the GetRequestTransactionId method as a workaround. SIP transactions have very specific requirements when matching requests, particularly INVITE transactions that need to be able to match INVITE, ACK and CANCEL requests.

There ishould be no issue sending mutliple SIP INFO requests. Perhaps you are trying to reuse the same Via header. That will fail due to a duplicate transaction.