Hi Gao, I have no doubt that the different SDP in non-reliable response violates current regulations. The behaviour of UAC is an implementation issue, I think. When UAS receives the different SDP in a reliable response from the prior one in a non-reliable response, UAS may ... 1. terminate the session. 2. keep using the SDP in a non-reliable response. 3. change to the SDP in a reliable response. It is not clear, but it is not a regular case. Regards, Shinji gao.yang2@xxxxxxxxxx Wed, 7 Apr 2010 11:14:07 +0800 >Hi Paul, > >While considering one problem in our production's interoperability >testing, I re-read some parts of offeranswer draft and find something >might be deserving discussion. > >//begin of text(part): > For example, in Figure 1, only the SDP in F6 is the answer. The SDP > in the non-reliable response (F2) is the preview of the answer and > must be the same as the answer in F6. Receiving F2, the UAC should > act as if it receives the answer. >//end of text(part) > >[Gao] In fact, UAS sending SDP in non-reliable response is for potential >early media usage. Considering some UAS may have different address for >early media channel and the final session, some UAS may send different >SDP(compare with the answer) in non-reliable response. And I really found >such equipment inside and outside of ZTE. And considering UAC, I think we >should allow the UAC ignore the SDP in non-reliable response, while some >UAC really do not handle any SDP which is not offer or answer. > >But the permissibility of the degree of the difference might be delicate. >If the non-answer SDP just has different ip address or port, it seams OK. >If the non-answer SDP has different media streams, it would be hard to >handle for UAC. > > >And I re-read correlative part of RFC3261. I don't know that whether >allowing different SDP(compare with the answer) in non-reliable response >is violation/correction of current text or not. > >//correlative part of RFC3261 > o If the initial offer is in an INVITE, the answer MUST be in a > reliable non-failure message from UAS back to UAC which is > correlated to that INVITE. For this specification, that is > only the final 2xx response to that INVITE. That same exact > answer MAY also be placed in any provisional responses sent > prior to the answer. The UAC MUST treat the first session > description it receives as the answer, and MUST ignore any > session descriptions in subsequent responses to the initial > INVITE. > >Thanks, > >Gao _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
