Steve - IMO you have it quite right. People should stop trying to
classify an invite as to whether it is a session timer refresh (doing
nothing else) or some other change to the session. You just can't do
that. When you receive an invite, you cannot discern *why* it was done,
and it may have been done for multiple purposes. You must just react to
what it conveys.
Paul
Stephen Paterson wrote:
> As I understand it we are talking about 2 separate ideas. The presence of
> changed or unchanged SDP in a re-INVITE is not really anything to do with
> whether the request is a session refresh request or not. It is the presence
> of the Session-Expires header (and Min-SE if necessary) that indicates this.
> If these headers are present, it is a session refresh request, if not, any
> existing session timer should be cancelled. The offer/answer exchange is
> independent of this and should be implemented according to RFCs 3261 & 3264.
> The unchanged session version is used to indicate that the SDP is unchanged.
> Just because most of the time this will probably be the case with session
> refreshes, it does not mean that it has to be the case - i.e. a session
> refresh request may contain a new offer if it chooses but then the re-INVITE
> has 2 purposes - session refresh and SDP re-negotiation.
>
> As I have recently implemented the session timer in our SIP offering any
> corrections to my understanding gratefully received.
>
> Regards
>
> Steve
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Harmeet
> Singh
> Sent: 29 June 2006 08:18
> To: Erez Morabia
> Cc: [email protected]
> Subject: Re: [Sip-implementors] re-INVITE without SDP / Session-Timers
>
>
> I was pointing out that Re-Invite for session refresh should contain SDP
> negotiated earlier with same orgin value. This should indicate to UAS that
> this is a session refresh request. Quoting text from rfc:
>
> 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.
>
> 200 Ok should contain SDP for sure. I think we are in perfect agreement
> here. Only point we probably have not agreed upon is if origin value in
> session refresh SDP is same previously negotiated SDP, does it serves the
> purpose of indicating that this is a session refresh request.
>
> Thanks
> - Harmeet Singh
>
> On 6/29/06, Erez Morabia <[EMAIL PROTECTED]> wrote:
>> Even if the re-INVITE is intended for refreshing, you can not know if it
>> is NOT for offer/answer re-negotiation as well. As we can not ignore (or
>> break) what RFC3261 defines, I think agree with Nataraju - the OK
>> message should contain SDP.
>>
>> Thanks,
>> Erez
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Harmeet
>> Singh
>> Sent: Wednesday, June 28, 2006 5:37 PM
>> To: [email protected]
>> Subject: Re: [Sip-implementors] re-INVITE without SDP / Session-Timers
>>
>> Please Refer to Section 7.4 rfc 2408
>>
>> 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.
>>
>> I would interpret that this is indication strong enough that such a
>> invite
>> is intended for refreshing session-timer. All more so if,
>> Session-Expires
>> header is present.
>>
>> Thanks
>> - Harmeet Singh
>>
>> On 6/28/06, Frank Shearar <[EMAIL PROTECTED]> wrote:
>>> "Nataraju Basavaraju" <[EMAIL PROTECTED]> wrote:
>>>
>>>> Comments inline...
>>>>
>>>> Regards,
>>>> Nataraju A.B.
>>>>
>>>> -----Original Message-----
>>>> From: [EMAIL PROTECTED] on behalf of Erez
>> Morabia
>>>> Sent: Tue 6/27/2006 9:01 PM
>>>> To: [email protected]
>>>> Subject: [Sip-implementors] re-INVITE without SDP / Session-Timers
>>>>
>>>> Hi,
>>>>
>>>> Suppose, after a session was established using the offer/answer
>> model,
>>>> one of the UAs sends a re-INVITE without SDP.
>>>>
>>>> According to RFC3261, Section 14.1 (Modifying an Existing Session /
>> UAC
>>>> Behavior):
>>>>
>>>> "...Of course, a UAC MAY send a re-INVITE with no session
>> description,
>>>> in which case the first reliable non-failure response to the
>> re-INVITE
>>>> will contain the offer (in this specification, that is a 2xx
>> response)."
>>>> This means that the OK message should contain SDP with the offer.
>>>>
>>>> Moreover, suppose that the UA that sent the empty re-INVITE supports
>>>> Session-Timers.
>>>>
>>>> Is there any case where the other UA (the one that receives the
>> empty
>>>> re-INVITE) will issue an OK message without SDP? For example,
>> suppose it
>>>> supports Session-Timers as well and maybe knows that this empty
>>>> re-INVITE is just for refresh an not for re-negotiation.
>>>>
>>>> [ABN] As of now, the INVITE/re-INVITE transaction always perform
>>> offer/answer negotiation. If the intension was to refresh the
>>> session-timer,
>>> just put the same SDP which initial INVITE carried.
>>>> AFAIK, right now there is no way though some option or parameter
>> which
>>> can
>>> tell the recepient of re-INVITE can be sure that the particular
>> request is
>>> for session-refresh or SDP re-negotiation or BOTH.
>>>
>>> But in particular you would leave the version field in the SDP's
>> origin
>>> unchanged, yes?
>>>
>>> frank
>>>
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> [email protected]
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>
>>
>> --
>> ----------------------------------------------------
>> Harmeet Singh
>> _______________________________________________
>> 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
