If UAS rejects re-Invite with 488, the original call, with PCMU codec, will stay up.
Sanjay >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On >Behalf Of Harsha. R >Sent: Tuesday, January 22, 2008 10:03 AM >To: [email protected] >Subject: [Sip-implementors] Rejecting an offer post answer : >call stays up > >Hi, > I have a call set-up where-in post-answer codec modification >offer needs to be rejected and the call needs to stay up. >However, i have some doubts as to how this can be achieved. > >Premise: >1. Call setup and answered using PCMU >2. SIP UAS receives an offer requesting codec change to AMR > >At this point the UAS needs to reject the offer, however the >call needs to stay up. >Before arriving at the means to achieve the above behaviour, I >consider the following. > >RFC 3264,Section 4 states the following. > > 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. > >Since the means of rejecting an offer are up to the higher >layer protocol(SIP in this case), I will interpret is as >following. This is also discussed in >draft-ietf-sipping-sip-offeranswer-05.txt, Table 2 which >states that Offer in an INVITE can be rejected in a 488 to the >INVITE. I will extrapolate the same for RE-INVITE. > >However, section 6 in RFC 3264 states the following. >"An offered stream MAY be rejected in the answer, for any >reason. If a stream is rejected, the offerer and answerer >MUST NOT generate media (or RTCP packets) for that stream" > >This effectively means setting m-line port = 0 in answer will >shut down the media?? > >With regard to the above statement regarding media stream, >does this mean that i should set a non-zero port value in the >m-line of the SDP reject that i send in 488 respone to the RE-INVITE > >Therefore should my call flow look like? >Call already set up on PCMU > > RE-INVITE(offer contains AMR only) >UAC------------------------------------------------------------ >--------------> >UAS > 488(answer has a non-zero port value in m-line) >UAC<----------------------------------------------------------- >--------------- >UAS > >This way i ensure that >- since the offer is rejected, the session reverts to previous >state i.e. call remains on PCMU >- Also since the m-line port is NOT zero, the media is not >shut down, and the call stays up. > >But then again, i come across the following section in >draft-ietf-sipping-sip-offeranswer-05.txt which further >complicates things. > >2.3. Session Description which is not Offer nor Answer > > As previously stated, a session description in a SIP message is not > necessarily an offer or an answer. For example, SIP can use a > session description to describe capabilities apart from > offer/answer exchange. Examples of this are 200 OK responses for > OPTIONS and 488 responses for INVITE > >Does this mean that the session description in 488 to >RE-INVITE in the above case is not considered an answer at >all, and therefore i should not be worrying about the >semantics of setting the port value in m-line of sdp >description in 488 ? > >Thanks for any suggestions. >Regards >Harsha >_______________________________________________ >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
