Hi Gao,
Considering a BCP recommendation in this case,
>When UAC receives the different SDP in a reliable response from
>the prior one in a non-reliable response, UAC may ...
>1. terminate the session.
>2. keep using the SDP in a non-reliable response.
>3. change to the SDP in a reliable response.
and,
4. In case 2 or 3, it is recommended that the UAC confirms the current
offer-answer status using a reINVITE or an UPDATE request.
However I think "may" is adequate in case 3.
Regards,
Shinji
gao.yang2@xxxxxxxxxx
Fri, 9 Apr 2010 11:44:34 +0800
>Hi,
>
>Yes, considering implementation, I also find the three ways, especially
>for the last two ways.
>
>My original thought is make clarification on the third one("3. change to
>the SDP in a reliable response"), by RFC3264's rule.
>
>In fact, I think by rules, the UAC should modify the session as it is the
>lawful answer. Using early media by the SDP prior to the lawful answer is
>something outside of the lawful rules(Reliably way of using early media is
>Answer in 100rel).
>
>So, I think using or just discarding the SDP prior to the lawful answer is
>something depends on implementation. While "change to the SDP in a
>reliable response" should be normative.
>
>Thanks,
>
>Gao
>
>OKUMURA Shinji <shinji.okumura@xxxxxxxxxxxx>
>发件人: sipping-bounces@xxxxxxxx
>2010-04-09 10:13
>
>收件人
>sipping@xxxxxxxx
>抄送
>
>主题
>Re: [Sipping] About offeranswer draft:
>
>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
