Hi, Sestion 8.2(RFC 4028), indicates the following,
"If, however, the proxy remembers that the UAC did support the session timer, additional processing is needed. Because there is no Session-Expires or Require header field in the response, the proxy knows that it is the first session-timer-aware proxy to receive the response. This proxy MUST insert a Session-Expires header field into the response with the value it remembered from the forwarded request. It MUST set the value of the 'refresher' parameter to 'uac'. The proxy MUST add the 'timer' option tag to any Require header field in the response, and if none was present, add the Require header field with that value before forwarding it upstream." -As per the above statement, sateful proxy will add the session-expires and require header if UAC supports session timer. -But in Re-INVITE, i am not sure whether proxy will again add the session expires because already the UAC has been informed to refresh the session and if at all used, 422 will not be normally send by the UAC and this response will be used by proxy to indicate that session-refresh message should be send by UAC according to the time specified in the Min-SE of 422 response so that proxy will not be overloaded. Thanks, Venkatesh On 4/25/07, Song, Youngsun <[EMAIL PROTECTED]> wrote: > Hi, > > Suppose the following case: > > UA-A has established a session with UA-B and there is a dialog-stateful > proxy, P1, in the signaling path. > UA-A and P1 support session timer but UA-B doesn't. > The initial session timer is established by P1 requesting UA-A to > refresh the session (i.e., by inserting the Session-Expires and Require > headers appropriately in the 2xx response for the INVITE). > > After some time before a session refresh, UA-B sends a Re-INVITE with an > offer SDP to place the session on hold. Since UA-B doesn't support > session timer, the Re-INVITE doesn't have a Session-Expires header. When > P1 receives the Re-INVITE, P1 inserts a Session-Expires header and > Require header to request UA-A to refresh the session (P1 can safely > insert the Require header with timer because P1 knows that UA-A supports > timer via initial session establishment). When UA-A receives the > Re-INVITE, UA-A sends a 2xx provided no failure occurred and the 2xx > includes an answer SDP and the Session-Expires header. When P1 receives > the 2xx, P1 updates the session timer and forwards the 2xx to UA-B. > > I think the above Re-INVITE processings by P1 and UA-A are valid as per > RFC4028, but can any of you please verify? > > One question on UA-A processing in the above. > If UA-A sends a 422 response for the Re-INVITE and P1 forwards it to > UA-B, UA-B wouldn't know what to do as it won't understand the 422 > response. For this reason and maybe others, should P1 not insert the > Session-Expires header and Require header in the Re-INVITE and wait for > UA-A to issue another Re-INVITE for session refresh after the Re-INVITE > for session hold is completed? > Or if P1 still inserts those headers, should UA-A not send a 422 > response for the Re-INVITE for session hold and send another Re-INVITE > for session refresh immediately after the Re-INVITE for session hold is > completed? > Any thoughts? > > Thanks, > YoungSun > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
