(pat) Counter-intuitively, the "ACK" is a SIP Request, not a SIP Response. Therefore its first line includes a Request-URI, and the request-uri is also placed in the "To" field. RFC2234 13.1: "The procedure for sending this ACK depends on the type of response. For final responses between 300 and 699, the ACK processing is done in the transaction layer and follows one set of rules (See Section 17).
| 795 | // but the method parameter MUST be equal to "ACK". |
| 796 | // |
| 797 | void SipMOInviteClientTransactionLayer::MOCSendACK() |
| 798 | { |
| 799 | assert(! mTimerAE.isActive() && ! mTimerBF.isActive()); |
| 800 | LOG(INFO) << sbText(); |
| 801 | //LOG(INFO) << "user " << mSipUsername << " state " << getSipState() <<sbText(); |
| 802 | |
| 803 | static const string cAckstr("ACK"); |
| 804 | SipMessageAckOrCancel ack(cAckstr,mInvite); |
| 805 | ack.msmTo = *dsRequestToHeader(); // Must get the updated to-tag. |
| 806 | sipWrite(&ack); |
| 807 | // we dont care mTimerD.set(T4); |
| 808 | } |
| 809 | |
| 810 | void SipMOInviteClientTransactionLayer::MOSMSSendMESSAGE(const string &messageText, const string &contentType) |
| 811 | { |
no test coverage detected