Thanks all, I sort of came to realise half way through that actually, my query has nothing to do with the session timer. It's entirely about how to handle a badly formatted response, i.e., unchanged session version should mean unchanged SDP. What to do when it's not is the problem. Anyway, I agree with you Paul, this seems to be pretty much down to the implementation to decide how to handle it which means talking to my boss not you guys. Thanks again Steve
-----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: 12 June 2006 15:43 To: Uttam Kumar Sarkar Cc: Stephen Paterson; SIP Implementors (E-mail) Subject: Re: [Sip-implementors] Session timer - how to indicate the sessio nhasnot changed I see a lot of confusion in this conversation. reINVITEs to refresh a session timer and reINVITEs to accomplish some other purpose are not mutually exclusive. *Every* successful reINVITE (regardless of the sender's intent) determines anew whether there will subsequently be a session timer or not. The way I think of session timer is that, for the refresher, it establishes a deadline for when a reINVITE or UPDATE must be sent. If a reINVITE or UPDATE happens to be sent earlier, for some other purpose, then it will reestablish, or cancel the session timer, so the UA must be certain to insert session timer parameters in that request according to what outcome it desires, in addition to whatever content it places in the request to achieve the purpose that caused to to be sent. If the deadline is reached, then presumably there is no other purpose for the reINVITE or UPDATE than to refresh the session timer. In that case it can be formatted minimally to achieve that purpose. For UPDATE, no SDP is required, so it makes sense not to include it. For reINVITE, SDP must be exchanged. Since the originator has no desire to change it, sending the same (unchanged) SDP makes sense. The use of an unchanged o-line to indicate unchanged SDP is unrelated to session timer. It is simply an optimization. Paul Uttam Kumar Sarkar wrote: > Hi Steve, > Re-INVITE's SDP should be same for the origin field as did previous SDP > messages to its peer. > Please see below. > Thanks, > Uttam > Section 7 of RFC 4028. > > A re-INVITE generated to refresh the session is a normal re-INVITE, > and an UPDATE generated to refresh a session is a normal UPDATE. If > a UAC knows that its peer supports the UPDATE method, it is > RECOMMENDED that UPDATE be used instead of a re-INVITE. A UA can > make this determination if it has seen an Allow header field from its > peer with the value 'UPDATE', or through a mid-dialog OPTIONS > request. It is RECOMMENDED that the UPDATE request not contain an > offer [4], but a re-INVITE SHOULD contain one, even if the details of > the session have not changed. In that case, the offer MUST indicate > that it has not changed. In the case of SDP, this is accomplished by > including the same value for the origin field as did previous SDP > messages to its peer. The same is true for an answer exchanged as a > result of a session refresh request; if it has not changed, that MUST > be indicated. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Stephen > Paterson > Sent: Monday, June 12, 2006 9:07 AM > To: SIP Implementors (E-mail) > Subject: Re: [Sip-implementors] Session timer - how to indicate the > sessio nhasnot changed > > > Thanks Uttam, > > Sorry, I don't see how that conclusion can be drawn from RFC 4028. As > far as I can see, an unchanged 'o=' means an unchanged session, not a > session refresh. The two are distinct although admittedly I am unaware > of any other use for it. > > I think I can answer part of my question having looked through RFC 3264 > again, 3rd paragraph in section 8 states: > > 'When issuing an offer that modifies the session, > the "o=" line of the new SDP MUST be identical to that in the > previous SDP, except that the version in the origin field MUST > increment by one from the previous SDP. If the version in the origin > line does not increment, the SDP MUST be identical to the SDP with > that version number.' > > So, going by the last sentence, in this situation the SDP must be > identical to that in the most recent offer/answer. > > The question then becomes, how should the UAC behave in this case? The > dialog identifier will be correct so the UAC must ACK the response - if > it could ignore the 200, the session would at least eventually expire > due to the session timer. The nearest I can find in RFC 3261 is that I > should send ACK and then BYE but that is only when the 200 contains an > unacceptable offer. It is not an offer here and as an answer there is > nothing necessarily unacceptable about it other than it has changed when > it shouldn't have. Should I ignore the fact that the SDP has changed? > That strikes me as a somewhat dangerous precedent - I don't like to > disregard SHOULD or RECOMMENDED, let alone MUST. > > Regards > > Steve Paterson > > -----Original Message----- > From: Uttam Kumar Sarkar [mailto:[EMAIL PROTECTED] > Sent: 12 June 2006 13:01 > To: Stephen Paterson; SIP Implementors (E-mail) > Subject: RE: [Sip-implementors] Session timer - how to indicate the > session hasnot changed > > > If "o=" line is not changed in the re-INVITE then it's for Session Timer > re-INVITE. Otherwise the re-INVITE is for media change. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Stephen > Paterson > Sent: Monday, June 12, 2006 6:31 AM > To: SIP Implementors (E-mail) > Subject: [Sip-implementors] Session timer - how to indicate the session > hasnot changed > > > Hi all, > > The last paragraph of section 7.4 of RFC 4028 states: > > 'It is RECOMMENDED that the UPDATE request not contain an offer [4], but > a re-INVITE SHOULD contain one, even if the details of the session have > not changed. In that case, the offer MUST indicate that it has not > changed. In the case of SDP, this is accomplished by including the same > value for the origin field as did previous SDP messages to its peer. The > same is true for an answer exchanged as a result of a session refresh > request; if it has not changed, that MUST be indicated.' > > What happens when the refresher sends an offer with an unchanged origin > field, receives a 200 OK with an unchanged origin field but an 'm=' line > that was present in the most recent offer/answer exchange is missing > from the UAS response? > > My gut feeling is that the UAS is out of spec (and the entire SDP should > be > unchanged) but according to the quote above, only the origin field needs > to be unchanged in order to indicate that the session details are also > unchanged. > > At the moment this causes problem for our SIP implementation as it has > no control over the media. It simply raises an event to the application > that is controlling the media to indicate that the session parameters > have changed. We don't want to be doing this for session refresh > requests unless a genuine offer/answer exchange has been negotiated > during the transaction. > > If the UAS is out of spec, how should the UAC behave? > If not, is there anywhere in the RFCs that specifies more clearly how to > identify that a media session is unchanged? I haven't been able to find > anything in SIP, SDP, Session Timer or Offer Answer (which isn't to say > the answers aren't there somewhere). > > It may well be the case that I just have to change our logic and ignore > all of the SDP if the 'o=' is unchanged. Part of my query is to ensure > that, if I do this, I don't break anything elsewhere. > > Cheers > > Steve > > Steve Paterson > Software Engineer > Aculab > Tel: +44 (0) 1908 273866 > Fax: +44 (0) 1908 273801 > Email: mailto:[EMAIL PROTECTED] > Website: http://www.aculab.com > > _______________________________________________ > 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 > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
