Extract from RFC 3264,

The agent receiving the offer MAY generate an answer, or it MAY
   reject the offer.  The means for rejecting an offer are dependent on
   the higher layer protocol.  The offer/answer exchange is atomic; if
   the answer is rejected, the session reverts to the state prior to the
   offer (which may be absence of a session).

Means if the offer is rejected with 488 then it should used the same "o=" line.

Thanks,
Satish



On Mon, Jul 1, 2013 at 3:28 PM, Brett Tate <[email protected]> wrote:

> > In case an Offer modification is issued after a previous
> > modification was rejected (e.g. re-INVITE answered with
> > 488), should SDP version number increase by 1 wrt the
> > previous Offer? Or should it increase by 1 wrt the SDP
> > for which the Offer/Answer model was closed before the
> > first re-INVITE?
>
> >From an Offer/Answer perspective, either would likely work.  However from
> an RFC 4566 perspective, it is incorrect to use the same origin line for a
> different SDP.  Thus assuming that the SDP is different from both the
> successful and subsequent unsuccessful offer/answer negotiation, the SDP
> origin line version number would be higher than both.
>
> And for completeness... since the UAS might not see all the prior SDP
> versions, it should allow the SDP version to increase by more than 1.
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>



-- 
Thanks & Regards
Satish Agrawal
New Delhi-24.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to