Sorry, It is just an editorial mistake. "UAS" means "UAC". OKUMURA Shinji <shinji.okumura@xxxxxxxxxxxx> Fri, 09 Apr 2010 11:13:53 +0900 >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 _______________________________________________ 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
