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
