Please see inline for my comments. Thanks, Neel
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:sip-implementors- > [EMAIL PROTECTED] On Behalf Of Song, Youngsun > Sent: Thursday, April 26, 2007 6:02 PM > To: [EMAIL PROTECTED]; sip- > [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] Question on Session timer for Re-INVITE > > Please see my inline comments below. > > > -----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 (proxy) such that P1 > inserts only the Session-Expires header (with the current session > interval value), 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. > I agree. > > > > 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. > > My understanding is that the session timer is renegotiated for each > Re-INVITE and UPDATE regardless of what purpose these requests are > generated for. > > If P1 didn't insert the Session-Expires header in the Re-INVITE, UA-A > may not include a Session-Expires header in a 2xx for the Re-INVITE > which will result in "turning-off" the session timer. UA-A may send a > new Re-INVITE for session-refresh immediately after the Re-INVITE for > session hold, but P1 can't know it for sure. > > Any thoughts? I agree. Yes, Session Timer can be renegotiated. The Re-INVITEs originated from UA-A will always have Session-Expires as long as UA-A wishes to do timer. But UA-B is not aware of timer, and in this case, proxy should insert Session-Expires, otherwise, UA-A can turn off timer. > Thanks, > YoungSun > > > > > 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
