Steve,
AFAIK there is no spec on how to handle this case. My feelings are
similar to yours. IMO if the o-line is unchanged but something in the
rest of the SDP *is* changed, then there has been a malfunction. How to
deal with such a malfunction is an implementation choice.
If this is detected, I think I am inclined to just proceed as if the
o-line had a new value in it - acting on the changed SDP. But of course
the whole point of this seems to be to provide an optimization, so that
the SDP doesn't need to be reprocessed if it is unchanged. Detecting the
change requires extra work.
Paul
Stephen Paterson wrote:
> 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
