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
