A list of SIP protocol properties, rules and exceptions.
- From and To header fields of a registration request contain the same value.
- All the registration requests send from one UA to one registrar would always have the same Call-ID.
- As pre 3261(and 3261 alone) Invite is the only request which can initiate a dialog.
- Otherwise refer and subscribe requests can also start a Dialog.
- A calling UAC might receive any number of 1xx responses.
- An invite may or may not carry SDP.
- In case of forking, the calling UAC might receive multiple 1XX and 2xx.
- ACK is the only request without a response but still a complete transaction.
- ACK is a mandatory request in the same direction in which Invite was propagated.
- ACK is mandatory for an Invite, and doesn’t become part of any other transaction other than invite.
- ACK for all non-successful responses are considered within the Invite transaction.
For more discussion on ACK visit : My Previous post on ACK
- Cancel request can’t be challenged for authentication, as these requests can’t be re-submitted.
- ACK and Cancel must have the same RR header field if RR was present in the Invite request.
- The request filed in CSEQ for ACK and CANCEL is always invite (3261)
- The CSEQ number of ACK and CANCEL is always equal to the CSEQ number of the INVITE request which they are bound with.
- Apart from INVITE (3261) the only other request which can be cancelled is an INFO request.
- As per 3261′s definition of transaction, the transaction is considered complete when a request is responded by any final response, still intermediate proxies would keep the transaction alive for a time equal to default transaction timer (if not configured otherwise).
- There can be no session without a Dialog, but this property is not orthogonal.
- you can not cancel the Invite transaction if at-least one 1xx response is not received.
- You can not cancel any invite transaction for which there are responses received other than 1xx.
- In any case (other than re-writing the complete Invite request) the To and the From header fields never change in the entire life-time of a dialog.
- “z9hG4bk” is a weird string called as magic cookie. Nothing magical about it other than the name. It is used to by proxies to identify if the request complies to 3261 or its older brother 2543.
- 3261 doesn’t restrict 100 Trying for any request, so it can be practically issued for any request. Although it makes very little sense.
- According to 3261 and 3261 alone, Register is the only request which can be sent out of dialog.
- Option request is sent to query the far end of it’s capabilities.
slight deviation, Barging into other RFCs
- If offer is sent and no answer received another offer can’t be generated.
- if offer received but answer not sent, then another offer can’t be sent.
- SDP can be carried by Invite, 200 OK, 183, ACK none other.
- SDP answer must have equal number of m-lines.
- offer can be rejected but not ignored.
Enough for now, will keep updating this list.
If worried about SIP with NAT read the rport RFC. Just google.
if there is any way in which this article can be improved, please let me know.
Thanks for stopping by.