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
