SIP procondition & Long signaling

SIP so far support two kinds of procondition QoS (RFC3312, update by RFC4032) & Secure Session (RFC5027). Preconditions intend to ensure minimum possible of session establishment failure. So that, it was used before the session setup commonly.

There are three kinds of precondition attributes:

curr:

des:

conf: Used in E2E precondition, when answer contian this attribute it means that the end point generated the answer who require the offer orignator to confirm the information in 'conf'. Usually, conf was contain in provisional response like 183. Offer originator will reserve such resource (QoS or Session Secure) and then send an update offer (Usually, PRACK act as the role.)

 

Long signaling:

Long signaling used to make provisional response is sent reliably. The signaling looks like:

INVITE (Supported/Require: 100rel) ->

183 (Require: 100rel, RSeq)<-

PRACK ->

200 (PRACK)<-

180 <-

200 (INVITE) <-

 

The initial request (INVITE) contained a Supported or Require header field listing 100rel, when UAS handle such request, it may (Supported 100rel) or MUST (Require 100rel) reply with the provisional response. The provisional response

(183) the contained a Required 100rel and RSeq.