Neel,
> -----Original Message----- > From: Bala Neelakantan [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 25, 2007 1:26 PM > To: Song, Youngsun; [email protected] > Subject: RE: [Sip-implementors] Question on Session timer for > Re-INVITE > > 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. Well, then, let me change the processing at P1 such that P1 inserts only the Session-Expires header, not the Require header, in the Re-INVITE. By doing this, P1 is requesting a session timer as part of this Re-INVITE. I believe this is allowed and from P1 perspective, this would be consistent with the initial INVITE processing. > > 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 benefit of P1 inserting the Session-Expires header in the Re-INVITE is to force the UA-A to use this Re-INVITE to reset the session timer by including the Session-Expires header in the 2xx response, not requiring to generate another Re-INVITE for session refresh. > > 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. UA-A doesn't need to know whether the Require is added by UA-B or Proxy. Since the Re-INVITE doesn't include the Supported header with timer (for this example), UA-A knows that UA-B doesn't support timer. > > > 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
