See inline. Thanks, Neel
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:sip-implementors- > [EMAIL PROTECTED] On Behalf Of Song, Youngsun > Sent: Wednesday, April 25, 2007 12:07 PM > To: [email protected] > Subject: [Sip-implementors] Question on Session timer for Re-INVITE > > 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. Per RFC 4028, adding Require is not recommended. If the request did not contain a Supported header field with the value 'timer', the proxy MAY insert a Require header field with the value 'timer' into the request. However, this is NOT RECOMMENDED. Since Session Timer support needs only one endpoint to support, I don't see a reason why would a proxy add Require on Re-INVITE. For this call, already Session timer is enabled. One issue, is the UA-A has no idea, whether the Require in Re-INVITE is added by the UA-B or Proxy. What if UA-A wants the UA-B to do session refresh. In this case, the call could fail. > 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 You are right, this is another failure scenario. > 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? > 422 response is due to local policy. The logic should not depend on P1 adding Require: timer or not. This will make call processing logic ugly. > 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
