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

Reply via email to