[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [Sip-implementors] session refresh, but without SDP ?
From:       Troy Cauble <troy () bell-labs ! com>
Date:       2005-08-24 13:58:34
Message-ID: 430C7D0A.804 () bell-labs ! com
[Download RAW message or body]

B.Dutta,

Regarding "a change in SDP is not acceptable", this is
impossible to enforce with a re-INVITE.  Even if B sends
the offer, A can change it's answer.  From RFC 3264, section 8,

    However, the answerer MUST generate a valid answer
    (which MAY be the same as the previous SDP from the
    answerer, or MAY be different), according to the
    procedures defined in Section 6.

If a change is SDP is truely not acceptable and if you must
interoperate with UAs that don't enforce that policy,
you'd be better of using UPDATE for your session refreshes
or not using session timers at all.

-troy

Banibrata Dutta wrote:
> Thanks for the excellent explanation of the "why" aspect.
> Now I can imagine as to why in my case (where a change in  
> SDP is not acceptable), "B" must include "SDP" (as a matter
> of policy).
> 
> regards,
> B.Dutta
> 
> -----Original Message-----
> From: Troy Cauble [mailto:troy@bell-labs.com] 
> Sent: Tuesday, August 23, 2005 8:51 PM
> To: sip-implementors@cs.columbia.edu; dutta@india.hp.com
> Subject: Re: [Sip-implementors] session refresh, but without SDP ?
> 
> 
> 
> 
>>From: "Neeraj Jain" <neeraj.jain@baypackets.com>
>>
>>Hi,
>>
>>As per sec 14.1 of RFC3261, both of these are valid scenarios. This 
>>says, in context of re-INVITE SDP, that - "It is important to note 
>>that the full description of the session, not just the change, is sent."
>>
>>Absence of SDP in re-INVITE means that it's a re-INVITE without an 
>>offer, in which case first reliable response to it will contain an 
>>offer and usual offer/answer process will follow.
>>
>>Regards,
>>
>>Neeraj Jain
>>BayPackets Technologies
>>
>>-----Original Message-----
>>From: sip-implementors-bounces@cs.columbia.edu
>>[mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of 
>>Banibrata Dutta
>>Sent: Tuesday, August 23, 2005 5:30 PM
>>To: 'Banibrata Dutta'; Sip-implementors@cs.columbia.edu
>>Subject: RE: [Sip-implementors] session refresh, but without SDP ?
>>
>>Additional info:
>>
>>NOTE: Here the "UAS" is the refresher.
>>
>>A                B
>>---INVITE(sdp)---> : M1
>><--200 OK--------- : M2
>>---ACK-----------> : M3
>>      ...
>><--INVITE()------- : M4
>>case1:
>>---200 OK(sdp)---> : M5
>>case2:
>>---200 OK--------> : M5'
>>
>>Is the case1 the valid scenario in case of session refresh, i.e. M5 
>>contains same "sdp" as M1 ?
>>or, is the case2 a valid scenarios ?
>>
>>- bdutta
>>
>>-----Original Message-----
>>From: sip-implementors-bounces@cs.columbia.edu
>>[mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of 
>>Banibrata Dutta
>>Sent: Tuesday, August 23, 2005 4:42 PM
>>To: Sip-implementors@cs.columbia.edu
>>Subject: [Sip-implementors] session refresh, but without SDP ?
>>
>>Hi,
>>
>>Does absence of body (SDP) in the re-INVITE used to do session-refresh 
>>(in case of Session-Timers), signify that media properties remain 
>>unchanged from the previously negotiated ones, or does it mean, no 
>>media, i.e. any established RTP sessions are to be torn down, if 
>>re-INVITE doesn't contain body ?
>>
>>thanks & regards,
>>bdutta
> 
> 
> Bdutta,
> 
> It does not mean "no media".  It means UA "A" should make an offer in a
> response.
> 
> And while a re-INVITE is a session-refresh, UA "A" can't know that that's
> the primary purpose of the re-INVITE.  A re-INVITE without offer could
> indicate a 3PCC-like flow where "A" is about to be connected to another UA.
> 
> So should the SDP offered remain unchanged from the previous negotiation?
> That's up to UA "A"; if "B" needs it to be the same, it should have sent the
> offer.
> 
> In my opinion, "A" should send an offer with all supported coders, not the
> possibly reduced set from the previous negotiation, because it may be
> opening negotiations with a new peer.  But that's not a SIP requirement,
> that's a policy.
> 
> -troy
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]