About offeranswer draft:

[g***@zte.com.cn]

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



Kyzivat & Sawada Expires September 9, 2010 [Page 8]

Internet-Draft SIP Usage of the Offer/Answer Model March 2010


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

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[OKUMURA Shinji]

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

***@zte.com.cn
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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[OKUMURA Shinji]

Sorry,

It is just an editorial mistake.
"UAS" means "UAC".

OKUMURA Shinji <***@softfront.jp>
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
>
>***@zte.com.cn
>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-***@cs.columbia.edu for questions on current sip
>Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[g***@zte.com.cn]

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

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================



OKUMURA Shinji <***@softfront.jp>
·¢ŒþÈË: sipping-***@ietf.org
2010-04-09 10:13

ÊÕŒþÈË
***@ietf.org
³­ËÍ

Ö÷Ìâ
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

***@zte.com.cn
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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP





--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[OKUMURA Shinji]

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

***@zte.com.cn
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 <***@softfront.jp>
>发件人: sipping-***@ietf.org
>2010-04-09 10:13
>
>收件人
>***@ietf.org
>抄送
>
>主题
>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
>
>***@zte.com.cn
>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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments

[g***@zte.com.cn]

Hi Shinji,

By myself, I am OK with the three ways. But if there's no normative
definition here, there would be some interworking fight for this issue.

Thanks,

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================



OKUMURA Shinji <***@softfront.jp>
·¢ŒþÈË: sipping-***@ietf.org
2010-04-09 14:23

ÊÕŒþÈË
***@ietf.org
³­ËÍ

Ö÷Ìâ
Re: [Sipping] About offeranswer draft:






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

***@zte.com.cn
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 <***@softfront.jp>
>·¢ŒþÈË: sipping-***@ietf.org
>2010-04-09 10:13
>
>ÊÕŒþÈË
>***@ietf.org
>³­ËÍ
>
>Ö÷Ìâ
>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
>
>***@zte.com.cn
>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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[OKUMURA Shinji]

Hi Gao,

In this case it is no doubt the UAS is a cause of the problem.
All you have to do is say "Your UAS is against the rules".
You will surely win the fight.

Regards,
Shinji

***@zte.com.cn
Fri, 9 Apr 2010 15:25:58 +0800
>Hi Shinji,
>
>By myself, I am OK with the three ways. But if there's no normative
>definition here, there would be some interworking fight for this issue.
>
>Thanks,
>
>Gao
>
>OKUMURA Shinji <***@softfront.jp>
>发件人: sipping-***@ietf.org
>2010-04-09 14:23
>
>收件人
>***@ietf.org
>抄送
>
>主题
>Re: [Sipping] About offeranswer draft:
>
>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
>
>***@zte.com.cn
>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 <***@softfront.jp>
>>发件人: sipping-***@ietf.org
>>2010-04-09 10:13
>>
>>收件人
>>***@ietf.org
>>抄送
>>
>>主题
>>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
>>
>>***@zte.com.cn
>>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-***@cs.columbia.edu for questions on current sip
Use ***@i

[g***@zte.com.cn]

Hi Shinji,

Thanks firstly.

But the UAS do not think it throws the problem. RFC3261 said UAS may send
the same SDP before the answer, but there is not normative words of to
forbid the different SDPs.

And if the equipment has been in the network, unless we using the evident
standard, we has no way to request their correction.

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================



OKUMURA Shinji <***@softfront.jp>
·¢ŒþÈË: sipping-***@ietf.org
2010-04-09 16:30

ÊÕŒþÈË
***@ietf.org
³­ËÍ

Ö÷Ìâ
Re: [Sipping] About offeranswer draft:






Hi Gao,

In this case it is no doubt the UAS is a cause of the problem.
All you have to do is say "Your UAS is against the rules".
You will surely win the fight.

Regards,
Shinji

***@zte.com.cn
Fri, 9 Apr 2010 15:25:58 +0800
>Hi Shinji,
>
>By myself, I am OK with the three ways. But if there's no normative
>definition here, there would be some interworking fight for this issue.
>
>Thanks,
>
>Gao
>
>OKUMURA Shinji <***@softfront.jp>
>·¢ŒþÈË: sipping-***@ietf.org
>2010-04-09 14:23
>
>ÊÕŒþÈË
>***@ietf.org
>³­ËÍ
>
>Ö÷Ìâ
>Re: [Sipping] About offeranswer draft:
>
>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
>
>***@zte.com.cn
>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 <***@softfront.jp>
>>·¢ŒþÈË: sipping-***@ietf.org
>>2010-04-09 10:13
>>
>>ÊÕŒþÈË
>>***@ietf.org
>>³­ËÍ
>>
>>Ö÷Ìâ
>>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
>>
>>***@zte.com.cn
>>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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[OKUMURA Shinji]

Hi Gao,

The clarifications for the section 13.2.1 of RFC 3261 is
one of the major purposes in this draft.

In the section 3.1 of this draft,
| 3.1. Offer/Answer for the INVITE method with 100rel extension
| (snip) All the session
| descriptions in the unreliable responses to the INVITE request must
| be identical to the answer which is included in the reliable
| response.

Do you doubt this clarification?
In my understanding, this has already reached the consensus in WG.

I'm confused.
Do you have something a concrete proposal?

Just to be sure, this draft is not a normative document but
an informational one as you no doubt know.

Regards,
Shinji

***@zte.com.cn
Fri, 9 Apr 2010 16:50:12 +0800
>Hi Shinji,
>
>Thanks firstly.
>
>But the UAS do not think it throws the problem. RFC3261 said UAS may send
>the same SDP before the answer, but there is not normative words of to
>forbid the different SDPs.
>
>And if the equipment has been in the network, unless we using the evident
>standard, we has no way to request their correction.
>
>Gao
>
>OKUMURA Shinji <***@softfront.jp>
>发件人: sipping-***@ietf.org
>2010-04-09 16:30
>
>收件人
>***@ietf.org
>抄送
>
>主题
>Re: [Sipping] About offeranswer draft:
>
>Hi Gao,
>
>In this case it is no doubt the UAS is a cause of the problem.
>All you have to do is say "Your UAS is against the rules".
>You will surely win the fight.
>
>Regards,
>Shinji
>
>***@zte.com.cn
>Fri, 9 Apr 2010 15:25:58 +0800
>>Hi Shinji,
>>
>>By myself, I am OK with the three ways. But if there's no normative
>>definition here, there would be some interworking fight for this issue.
>>
>>Thanks,
>>
>>Gao
>>
>>OKUMURA Shinji <***@softfront.jp>
>>发件人: sipping-***@ietf.org
>>2010-04-09 14:23
>>
>>收件人
>>***@ietf.org
>>抄送
>>
>>主题
>>Re: [Sipping] About offeranswer draft:
>>
>>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
>>
>>***@zte.com.cn
>>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 <***@softfront.jp>
>>>发件人: sipping-***@ietf.org
>>>2010-04-09 10:13
>>>
>>>收件人
>>>***@ietf.org
>>>抄送
>>>
>>>主题
>>>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
>>>
>>>***@zte.com.cn
>>>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-***@cs.columbia.edu for questions on current sip
>Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use si

[g***@zte.com.cn]

Hi Shinji,

Please see inlines.

Thanks,

Gao

sipping-***@ietf.org ÐŽÓÚ 2010-04-12 10:55:47:

> Hi Gao,
>
> The clarifications for the section 13.2.1 of RFC 3261 is
> one of the major purposes in this draft.
>
> In the section 3.1 of this draft,
> | 3.1. Offer/Answer for the INVITE method with 100rel extension
> | (snip) All the session
> | descriptions in the unreliable responses to the INVITE request must
> | be identical to the answer which is included in the reliable
> | response.
>
> Do you doubt this clarification?
> In my understanding, this has already reached the consensus in WG.

[Gao] I am not want to *challenge* the consensus we have reached in WG.
But as this draft is aims for clarification, not for normative correction,
I have no way to convince the *UAS*.

>
> I'm confused.
> Do you have something a concrete proposal?

[Gao] I think the original illegibility is from RFC3261. So, I sended
mails about it in SIPCore ML:

http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html

To be honest, I think there are two options here:
1. Forbid different SDP(compare with the answer) before the answer
normatively.
2. Allowing different SDP(compare with the answer) before the answer
normatively.

>
> Just to be sure, this draft is not a normative document but
> an informational one as you no doubt know.

[Gao] Sure, I know it is informative.

>
> Regards,
> Shinji
>
> ***@zte.com.cn
> Fri, 9 Apr 2010 16:50:12 +0800
> >Hi Shinji,
> >
> >Thanks firstly.
> >
> >But the UAS do not think it throws the problem. RFC3261 said UAS may
send
> >the same SDP before the answer, but there is not normative words of to
> >forbid the different SDPs.
> >
> >And if the equipment has been in the network, unless we using the
evident
> >standard, we has no way to request their correction.
> >
> >Gao
> >
> >OKUMURA Shinji <***@softfront.jp>
> >·¢ŒþÈË: sipping-***@ietf.org
> >2010-04-09 16:30
> >
> >ÊÕŒþÈË
> >***@ietf.org
> >³­ËÍ
> >
> >Ö÷Ìâ
> >Re: [Sipping] About offeranswer draft:
> >
> >Hi Gao,
> >
> >In this case it is no doubt the UAS is a cause of the problem.
> >All you have to do is say "Your UAS is against the rules".
> >You will surely win the fight.
> >
> >Regards,
> >Shinji
> >
> >***@zte.com.cn
> >Fri, 9 Apr 2010 15:25:58 +0800
> >>Hi Shinji,
> >>
> >>By myself, I am OK with the three ways. But if there's no normative
> >>definition here, there would be some interworking fight for this
issue.
> >>
> >>Thanks,
> >>
> >>Gao
> >>
> >>OKUMURA Shinji <***@softfront.jp>
> >>·¢ŒþÈË: sipping-***@ietf.org
> >>2010-04-09 14:23
> >>
> >>ÊÕŒþÈË
> >>***@ietf.org
> >>³­ËÍ
> >>
> >>Ö÷Ìâ
> >>Re: [Sipping] About offeranswer draft:
> >>
> >>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
> >>
> >>***@zte.com.cn
> >>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
earlymedia 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 <***@softfront.jp>
> >>>·¢ŒþÈË: sipping-***@ietf.org
> >>>2010-04-09 10:13
> >>>
> >>>ÊÕŒþÈË
> >>>***@ietf.org
> >>>³­ËÍ
> >>>
> >>>Ö÷Ìâ
> >>>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
> >>>
> >>>***@zte.com.cn
> >>>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,
Ithink 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-***@cs.columbia.edu for questions on current sip
> >Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org for new developments of core SIP


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[OKUMURA Shinji]

Hi Gao,

In the following case,

UAC UAS
| F1 INVITE (SDP1) | <-- offer
|-------------------->|
| F2 1xx (SDP2) |
|<--------------------|
| F3 1xx (SDP3) |
|<--------------------|
| F4 1xx-rel (SDP4) | <-- answer
|<--------------------|
| F5 1xx-rel (SDP5) |
|<--------------------|
| F6 1xxl (SDP6) |
|<--------------------|
| F7 2xx INV(SDP7) |
|<--------------------|
| F8 ACK |
|-------------------->|
(PRACK transactions are not shown)

I tried to arrange the rules.
(small letters mean informational)

UAC,
(Rc1) MUST treat SDP2 as the answer.
(Rc2) MUST ignore SDP5, SDP6 and SDP7.
(Rc3) may treat SDP3 as the answer.
(Rc4) should treat SDP4 as the answer and confirm the current O/A status by sending new offer.

UAS,
(Rs1) should not send SDP5, SDP6 and SDP7.
(Rs2) must not send SDP2 and SDP3 if these are not the same as SDP4.

Rc3 and Rc4 are new added descriptions.
Rs1 and Rs2 are current descriptions in this draft.

I think "MUST NOT" is suitable for (Rs1).
Because RFC3261 says
Once the UAS has sent or received an answer to the initial
offer, it MUST NOT generate subsequent offers in any responses
to the initial INVITE. This means that a UAS based on this
specification alone can never generate subsequent offers until
completion of the initial transaction.

SDP5 and SDP7 are regarded as "subsequent offers".

What do you think of these?

Regards,
Shinji

***@zte.com.cn
Mon, 12 Apr 2010 11:37:09 +0800
>Hi Shinji,
>
>Please see inlines.
>
>Thanks,
>
>Gao
>
>sipping-***@ietf.org 写于 2010-04-12 10:55:47:
>
>> Hi Gao,
>>
>> The clarifications for the section 13.2.1 of RFC 3261 is
>> one of the major purposes in this draft.
>>
>> In the section 3.1 of this draft,
>> | 3.1. Offer/Answer for the INVITE method with 100rel extension
>> | (snip) All the session
>> | descriptions in the unreliable responses to the INVITE request must
>> | be identical to the answer which is included in the reliable
>> | response.
>>
>> Do you doubt this clarification?
>> In my understanding, this has already reached the consensus in WG.
>
>[Gao] I am not want to *challenge* the consensus we have reached in WG.
>But as this draft is aims for clarification, not for normative correction,
>I have no way to convince the *UAS*.
>
>>
>> I'm confused.
>> Do you have something a concrete proposal?
>
>[Gao] I think the original illegibility is from RFC3261. So, I sended
>mails about it in SIPCore ML:
>
>http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
>http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html
>
>To be honest, I think there are two options here:
>1. Forbid different SDP(compare with the answer) before the answer
>normatively.
>2. Allowing different SDP(compare with the answer) before the answer
>normatively.
>
>>
>> Just to be sure, this draft is not a normative document but
>> an informational one as you no doubt know.
>
>[Gao] Sure, I know it is informative.
>
>>
>> Regards,
>> Shinji
>>
>> ***@zte.com.cn
>> Fri, 9 Apr 2010 16:50:12 +0800
>> >Hi Shinji,
>> >
>> >Thanks firstly.
>> >
>> >But the UAS do not think it throws the problem. RFC3261 said UAS may send
>> >the same SDP before the answer, but there is not normative words of to
>> >forbid the different SDPs.
>> >
>> >And if the equipment has been in the network, unless we using the evident
>> >standard, we has no way to request their correction.
>> >
>> >Gao
>> >
>> >OKUMURA Shinji <***@softfront.jp>
>> >发件人: sipping-***@ietf.org
>> >2010-04-09 16:30
>> >
>> >收件人
>> >***@ietf.org
>> >抄送
>> >
>> >主题
>> >Re: [Sipping] About offeranswer draft:
>> >
>> >Hi Gao,
>> >
>> >In this case it is no doubt the UAS is a cause of the problem.
>> >All you have to do is say "Your UAS is against the rules".
>> >You will surely win the fight.
>> >
>> >Regards,
>> >Shinji
>> >
>> >***@zte.com.cn
>> >Fri, 9 Apr 2010 15:25:58 +0800
>> >>Hi Shinji,
>> >>
>> >>By myself, I am OK with the three ways. But if there's no normative
>> >>definition here, there would be some interworking fight for this issue.
>> >>
>> >>Thanks,
>> >>
>> >>Gao
>> >>
>> >>OKUMURA Shinji <***@softfront.jp>
>> >>发件人: sipping-***@ietf.org
>> >>2010-04-09 14:23
>> >>
>> >>收件人
>> >>***@ietf.org
>> >>抄送
>> >>
>> >>主题
>> >>Re: [Sipping] About offeranswer draft:
>> >>
>> >>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
>> >>
>> >>***@zte.com.cn
>> >>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 earlymedia 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 <***@softfront.jp>
>> >>>发件人: sipping-***@ietf.org
>> >>>2010-04-09 10:13
>> >>>
>> >>>收件人
>> >>>***@ietf.org
>> >>>抄送
>> >>>
>> >>>主题
>> >>>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
>> >>>
>> >>>***@zte.com.cn
>> >>>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, Ithink 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org

[g***@zte.com.cn]

sipping-***@ietf.org ÐŽÓÚ 2010-04-14 11:17:23:

> Hi Gao,
>
> In the following case,
>
> UAC UAS
> | F1 INVITE (SDP1) | <-- offer
> |-------------------->|
> | F2 1xx (SDP2) |
> |<--------------------|
> | F3 1xx (SDP3) |
> |<--------------------|
> | F4 1xx-rel (SDP4) | <-- answer
> |<--------------------|
> | F5 1xx-rel (SDP5) |
> |<--------------------|
> | F6 1xxl (SDP6) |
> |<--------------------|
> | F7 2xx INV(SDP7) |
> |<--------------------|
> | F8 ACK |
> |-------------------->|
> (PRACK transactions are not shown)
>
> I tried to arrange the rules.
> (small letters mean informational)
>
> UAC,
> (Rc1) MUST treat SDP2 as the answer.
> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> (Rc3) may treat SDP3 as the answer.

[Gao] OK

> (Rc4) should treat SDP4 as the answer and confirm the current O/A
> status by sending new offer.

[Gao] support of this, though this may be modification of current RFC3261.

>
> UAS,
> (Rs1) should not send SDP5, SDP6 and SDP7.
> (Rs2) must not send SDP2 and SDP3 if these are not the same as SDP4.
>
> Rc3 and Rc4 are new added descriptions.
> Rs1 and Rs2 are current descriptions in this draft.
>
> I think "MUST NOT" is suitable for (Rs1).
> Because RFC3261 says
> Once the UAS has sent or received an answer to the initial
> offer, it MUST NOT generate subsequent offers in any responses
> to the initial INVITE. This means that a UAS based on this
> specification alone can never generate subsequent offers until
> completion of the initial transaction.
>

[Gao] Yes.

> SDP5 and SDP7 are regarded as "subsequent offers".

[Gao] as "MUST NOT" is suitable for (Rs1), so there must be no "subsequent
offers" in subsequent response.

>
> What do you think of these?
>
> Regards,
> Shinji
>
> ***@zte.com.cn
> Mon, 12 Apr 2010 11:37:09 +0800
> >Hi Shinji,
> >
> >Please see inlines.
> >
> >Thanks,
> >
> >Gao
> >
> >sipping-***@ietf.org ÐŽÓÚ 2010-04-12 10:55:47:
> >
> >> Hi Gao,
> >>
> >> The clarifications for the section 13.2.1 of RFC 3261 is
> >> one of the major purposes in this draft.
> >>
> >> In the section 3.1 of this draft,
> >> | 3.1. Offer/Answer for the INVITE method with 100rel extension
> >> | (snip) All the session
> >> | descriptions in the unreliable responses to the INVITE request
must
> >> | be identical to the answer which is included in the reliable
> >> | response.
> >>
> >> Do you doubt this clarification?
> >> In my understanding, this has already reached the consensus in WG.
> >
> >[Gao] I am not want to *challenge* the consensus we have reached in WG.

> >But as this draft is aims for clarification, not for normative
correction,
> >I have no way to convince the *UAS*.
> >
> >>
> >> I'm confused.
> >> Do you have something a concrete proposal?
> >
> >[Gao] I think the original illegibility is from RFC3261. So, I sended
> >mails about it in SIPCore ML:
> >
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html
> >
> >To be honest, I think there are two options here:
> >1. Forbid different SDP(compare with the answer) before the answer
> >normatively.
> >2. Allowing different SDP(compare with the answer) before the answer
> >normatively.
> >
> >>
> >> Just to be sure, this draft is not a normative document but
> >> an informational one as you no doubt know.
> >
> >[Gao] Sure, I know it is informative.
> >
> >>
> >> Regards,
> >> Shinji
> >>
> >> ***@zte.com.cn
> >> Fri, 9 Apr 2010 16:50:12 +0800
> >> >Hi Shinji,
> >> >
> >> >Thanks firstly.
> >> >
> >> >But the UAS do not think it throws the problem. RFC3261 said UASmay
send
> >> >the same SDP before the answer, but there is not normative words of
to
> >> >forbid the different SDPs.
> >> >
> >> >And if the equipment has been in the network, unless we using the
evident
> >> >standard, we has no way to request their correction.
> >> >
> >> >Gao
> >> >
> >> >OKUMURA Shinji <***@softfront.jp>
> >> >·¢ŒþÈË: sipping-***@ietf.org
> >> >2010-04-09 16:30
> >> >
> >> >ÊÕŒþÈË
> >> >***@ietf.org
> >> >³­ËÍ
> >> >
> >> >Ö÷Ìâ
> >> >Re: [Sipping] About offeranswer draft:
> >> >
> >> >Hi Gao,
> >> >
> >> >In this case it is no doubt the UAS is a cause of the problem.
> >> >All you have to do is say "Your UAS is against the rules".
> >> >You will surely win the fight.
> >> >
> >> >Regards,
> >> >Shinji
> >> >
> >> >***@zte.com.cn
> >> >Fri, 9 Apr 2010 15:25:58 +0800
> >> >>Hi Shinji,
> >> >>
> >> >>By myself, I am OK with the three ways. But if there's no normative

> >> >>definition here, there would be some interworking fight for this
issue.
> >> >>
> >> >>Thanks,
> >> >>
> >> >>Gao
> >> >>
> >> >>OKUMURA Shinji <***@softfront.jp>
> >> >>·¢ŒþÈË: sipping-***@ietf.org
> >> >>2010-04-09 14:23
> >> >>
> >> >>ÊÕŒþÈË
> >> >>***@ietf.org
> >> >>³­ËÍ
> >> >>
> >> >>Ö÷Ìâ
> >> >>Re: [Sipping] About offeranswer draft:
> >> >>
> >> >>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
> >> >>
> >> >>***@zte.com.cn
> >> >>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
> earlymedia 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 <***@softfront.jp>
> >> >>>·¢ŒþÈË: sipping-***@ietf.org
> >> >>>2010-04-09 10:13
> >> >>>
> >> >>>ÊÕŒþÈË
> >> >>>***@ietf.org
> >> >>>³­ËÍ
> >> >>>
> >> >>>Ö÷Ìâ
> >> >>>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
> >> >>>
> >> >>>***@zte.com.cn
> >> >>>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, Ithink 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-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org for new developments of core SIP


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[OKUMURA Shinji]

Hi Gao,

***@zte.com.cn
Wed, 14 Apr 2010 12:21:45 +0800
>sipping-***@ietf.org 写于 2010-04-14 11:17:23:
>
>> Hi Gao,
>>
>> In the following case,
>>
>> UAC UAS
>> | F1 INVITE (SDP1) | <-- offer
>> |-------------------->|
>> | F2 1xx (SDP2) |
>> |<--------------------|
>> | F3 1xx (SDP3) |
>> |<--------------------|
>> | F4 1xx-rel (SDP4) | <-- answer
>> |<--------------------|
>> | F5 1xx-rel (SDP5) |
>> |<--------------------|
>> | F6 1xxl (SDP6) |
>> |<--------------------|
>> | F7 2xx INV(SDP7) |
>> |<--------------------|
>> | F8 ACK |
>> |-------------------->|
>> (PRACK transactions are not shown)
>>
>> I tried to arrange the rules.
>> (small letters mean informational)
>>
>> UAC,
>> (Rc1) MUST treat SDP2 as the answer.
>> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
>> (Rc3) may treat SDP3 as the answer.
>
>[Gao] OK
>
>> (Rc4) should treat SDP4 as the answer and confirm the current O/A
>> status by sending new offer.
>
>[Gao] support of this, though this may be modification of current RFC3261.

You will probably think of the following statements,
RFC3261/13.2.1 Creating the Initial INVITE
(snip) "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."

No doubt this is one of the cussword built in this document.
It is a personal interpretation of mine,
"as the answer" is associated with not "treat" but "receives",
and "treat" means "not ignore".

Just putting that aside for now, I think there is a consensus that
Rc4 does not need a modification of current RFC3261.

>> UAS,
>> (Rs1) should not send SDP5, SDP6 and SDP7.
>> (Rs2) must not send SDP2 and SDP3 if these are not the same as SDP4.
>>
>> Rc3 and Rc4 are new added descriptions.
>> Rs1 and Rs2 are current descriptions in this draft.
>>
>> I think "MUST NOT" is suitable for (Rs1).
>> Because RFC3261 says
>> Once the UAS has sent or received an answer to the initial
>> offer, it MUST NOT generate subsequent offers in any responses
>> to the initial INVITE. This means that a UAS based on this
>> specification alone can never generate subsequent offers until
>> completion of the initial transaction.
>>
>
>[Gao] Yes.
>
>> SDP5 and SDP7 are regarded as "subsequent offers".
>
>[Gao] as "MUST NOT" is suitable for (Rs1), so there must be no "subsequent
>offers" in subsequent response.

Certainly UAC MUST ignore SDPs no matter what these are.

Regards,
Shinji
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new develo

[g***@zte.com.cn]

Hi Shinji,


sipping-***@ietf.org ÐŽÓÚ 2010-04-14 15:31:54:

> Hi Gao,
>
> ***@zte.com.cn
> Wed, 14 Apr 2010 12:21:45 +0800
> >sipping-***@ietf.org ÐŽÓÚ 2010-04-14 11:17:23:
> >
> >> Hi Gao,
> >>
> >> In the following case,
> >>
> >> UAC UAS
> >> | F1 INVITE (SDP1) | <-- offer
> >> |-------------------->|
> >> | F2 1xx (SDP2) |
> >> |<--------------------|
> >> | F3 1xx (SDP3) |
> >> |<--------------------|
> >> | F4 1xx-rel (SDP4) | <-- answer
> >> |<--------------------|
> >> | F5 1xx-rel (SDP5) |
> >> |<--------------------|
> >> | F6 1xxl (SDP6) |
> >> |<--------------------|
> >> | F7 2xx INV(SDP7) |
> >> |<--------------------|
> >> | F8 ACK |
> >> |-------------------->|
> >> (PRACK transactions are not shown)
> >>
> >> I tried to arrange the rules.
> >> (small letters mean informational)
> >>
> >> UAC,
> >> (Rc1) MUST treat SDP2 as the answer.
> >> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> >> (Rc3) may treat SDP3 as the answer.
> >
> >[Gao] OK
> >
> >> (Rc4) should treat SDP4 as the answer and confirm the current O/A
> >> status by sending new offer.
> >
> >[Gao] support of this, though this may be modification of current
RFC3261.
>
> You will probably think of the following statements,
> RFC3261/13.2.1 Creating the Initial INVITE
> (snip) "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."
>
> No doubt this is one of the cussword built in this document.
> It is a personal interpretation of mine,
> "as the answer" is associated with not "treat" but "receives",
> and "treat" means "not ignore".
>
> Just putting that aside for now, I think there is a consensus that
> Rc4 does not need a modification of current RFC3261.

I see. But if there's memo of such consensus, it would be quite useful in
interworking testing.

>
> >> UAS,
> >> (Rs1) should not send SDP5, SDP6 and SDP7.
> >> (Rs2) must not send SDP2 and SDP3 if these are not the same as
SDP4.
> >>
> >> Rc3 and Rc4 are new added descriptions.
> >> Rs1 and Rs2 are current descriptions in this draft.
> >>
> >> I think "MUST NOT" is suitable for (Rs1).
> >> Because RFC3261 says
> >> Once the UAS has sent or received an answer to the initial
> >> offer, it MUST NOT generate subsequent offers in any responses
> >> to the initial INVITE. This means that a UAS based on this
> >> specification alone can never generate subsequent offers until
> >> completion of the initial transaction.
> >>
> >
> >[Gao] Yes.
> >
> >> SDP5 and SDP7 are regarded as "subsequent offers".
> >
> >[Gao] as "MUST NOT" is suitable for (Rs1), so there must be no
"subsequent
> >offers" in subsequent response.
>
> Certainly UAC MUST ignore SDPs no matter what these are.
>
> Regards,
> Shinji



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[Somogyi, Gabor (NSN - HU/Budapest)]

Hi,

RFC3261: "...MUST ignore any session descriptions in subsequent responses..."
I think that the common industry understanding of RFC3261 is that 1 offer has 1 answer, even though that 1 answer may be transmitted several times. And the 1st transmission is used (treated as THE answer). While you are speaking about several answers with 1 matching offer. That is a fundamental difference.

In your chart SDP4 is a reliable answer. Therefore SDP5 might be interpreted as a new offer, hence UAC could send an answer in PRACK. Quite similarly to 3PCC cases, where 200 contains the offer and ACK the answer.

In my opinion it is better not to allow an answer updating a prior answer of the same offer. If early meadia is a real issue, implement support for 100rel and send update using UPDATE method. Or UAC could play ring-back tone locally. That is another cheap and easy solution. I do not see any reason for hacking.

BR,
Som

________________________________

From: sipping-***@ietf.org [mailto:sipping-***@ietf.org] On Behalf Of ext ***@zte.com.cn
Sent: Wednesday, April 14, 2010 11:19
To: OKUMURA Shinji
Cc: sipping-***@ietf.org; ***@ietf.org
Subject: [Sipping] ŽðžŽ: Re: About offeranswer draft:



Hi Shinji,


sipping-***@ietf.org ÐŽÓÚ 2010-04-14 15:31:54:

> Hi Gao,
>
> ***@zte.com.cn
> Wed, 14 Apr 2010 12:21:45 +0800
> >sipping-***@ietf.org ÐŽÓÚ 2010-04-14 11:17:23:
> >
> >> Hi Gao,
> >>
> >> In the following case,
> >>
> >> UAC UAS
> >> | F1 INVITE (SDP1) | <-- offer
> >> |-------------------->|
> >> | F2 1xx (SDP2) |
> >> |<--------------------|
> >> | F3 1xx (SDP3) |
> >> |<--------------------|
> >> | F4 1xx-rel (SDP4) | <-- answer
> >> |<--------------------|
> >> | F5 1xx-rel (SDP5) |
> >> |<--------------------|
> >> | F6 1xxl (SDP6) |
> >> |<--------------------|
> >> | F7 2xx INV(SDP7) |
> >> |<--------------------|
> >> | F8 ACK |
> >> |-------------------->|
> >> (PRACK transactions are not shown)
> >>
> >> I tried to arrange the rules.
> >> (small letters mean informational)
> >>
> >> UAC,
> >> (Rc1) MUST treat SDP2 as the answer.
> >> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> >> (Rc3) may treat SDP3 as the answer.
> >
> >[Gao] OK
> >
> >> (Rc4) should treat SDP4 as the answer and confirm the current O/A
> >> status by sending new offer.
> >
> >[Gao] support of this, though this may be modification of current RFC3261.
>
> You will probably think of the following statements,
> RFC3261/13.2.1 Creating the Initial INVITE
> (snip) "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."
>
> No doubt this is one of the cussword built in this document.
> It is a personal interpretation of mine,
> "as the answer" is associated with not "treat" but "receives",
> and "treat" means "not ignore".
>
> Just putting that aside for now, I think there is a consensus that
> Rc4 does not need a modification of current RFC3261.

I see. But if there's memo of such consensus, it would be quite useful in interworking testing.

>
> >> UAS,
> >> (Rs1) should not send SDP5, SDP6 and SDP7.
> >> (Rs2) must not send SDP2 and SDP3 if these are not the same as SDP4.
> >>
> >> Rc3 and Rc4 are new added descriptions.
> >> Rs1 and Rs2 are current descriptions in this draft.
> >>
> >> I think "MUST NOT" is suitable for (Rs1).
> >> Because RFC3261 says
> >> Once the UAS has sent or received an answer to the initial
> >> offer, it MUST NOT generate subsequent offers in any responses
> >> to the initial INVITE. This means that a UAS based on this
> >> specification alone can never generate subsequent offers until
> >> completion of the initial transaction.
> >>
> >
> >[Gao] Yes.
> >
> >> SDP5 and SDP7 are regarded as "subsequent offers".
> >
> >[Gao] as "MUST NOT" is suitable for (Rs1), so there must be no "subsequent
> >offers" in subsequent response.
>
> Certainly UAC MUST ignore SDPs no matter what these are.
>
> Regards,
> Shinji


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[Paul Kyzivat]

Somogyi, Gabor (NSN - HU/Budapest) wrote:
> Hi,
>
> RFC3261: "...MUST ignore any session descriptions in subsequent
> responses..."
> I think that the common industry understanding of RFC3261 is that 1
> offer has 1 answer, even though that 1 answer may be transmitted several
> times.

Yes. Well, actually one answer per dialog. (With forking, an offer in
the initial invite will get a separate answer per-forked-dialog.)

> And the 1st transmission is used (treated as THE answer). While
> you are speaking about several answers with 1 matching offer. That is a
> fundamental difference.

This of course only makes sense if the sdp in all unreliable responses
is the same as the sdp in the first reliable response. That is so
because any/all of the unreliable responses may be lost. You cannot
count on the UAC using the SDP from the first transmission.

And because of that, a valid implementation could drop all the SDP
received unreliably and only process the one received reliably.

> In your chart SDP4 is a reliable answer. Therefore SDP5 might be
> interpreted as a new offer, hence UAC could send an answer in PRACK.
> Quite similarly to 3PCC cases, where 200 contains the offer and ACK the
> answer.

That has been investigated. Its not allowed. (Unfortunately I cannot
recall the chain of reasoning that derived its illegality - it wasn't
obvious but it was sound. It was worked out a *long* time ago.)

Thanks,
Paul

> In my opinion it is better not to allow an answer updating a prior
> answer of the same offer. If early meadia is a real issue, implement
> support for 100rel and send update using UPDATE method. Or UAC could
> play ring-back tone locally. That is another cheap and easy solution. I
> do not see any reason for hacking.
>
> BR,
> Som
>
> ------------------------------------------------------------------------
> *From:* sipping-***@ietf.org [mailto:sipping-***@ietf.org] *On
> Behalf Of *ext ***@zte.com.cn
> *Sent:* Wednesday, April 14, 2010 11:19
> *To:* OKUMURA Shinji
> *Cc:* sipping-***@ietf.org; ***@ietf.org
> *Subject:* [Sipping] 答复: Re: About offeranswer draft:
>
>
> Hi Shinji,
>
>
> sipping-***@ietf.org 写于 2010-04-14 15:31:54:
>
> > Hi Gao,
> >
> > ***@zte.com.cn
> > Wed, 14 Apr 2010 12:21:45 +0800
> > >sipping-***@ietf.org 写于 2010-04-14 11:17:23:
> > >
> > >> Hi Gao,
> > >>
> > >> In the following case,
> > >>
> > >> UAC UAS
> > >> | F1 INVITE (SDP1) | <-- offer
> > >> |-------------------->|
> > >> | F2 1xx (SDP2) |
> > >> |<--------------------|
> > >> | F3 1xx (SDP3) |
> > >> |<--------------------|
> > >> | F4 1xx-rel (SDP4) | <-- answer
> > >> |<--------------------|
> > >> | F5 1xx-rel (SDP5) |
> > >> |<--------------------|
> > >> | F6 1xxl (SDP6) |
> > >> |<--------------------|
> > >> | F7 2xx INV(SDP7) |
> > >> |<--------------------|
> > >> | F8 ACK |
> > >> |-------------------->|
> > >> (PRACK transactions are not shown)
> > >>
> > >> I tried to arrange the rules.
> > >> (small letters mean informational)
> > >>
> > >> UAC,
> > >> (Rc1) MUST treat SDP2 as the answer.
> > >> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> > >> (Rc3) may treat SDP3 as the answer.
> > >
> > >[Gao] OK
> > >
> > >> (Rc4) should treat SDP4 as the answer and confirm the current O/A
> > >> status by sending new offer.
> > >
> > >[Gao] support of this, though this may be modification of current
> RFC3261.
> >
> > You will probably think of the following statements,
> > RFC3261/13.2.1 Creating the Initial INVITE
> > (snip) "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."
> >
> > No doubt this is one of the cussword built in this document.
> > It is a personal interpretation of mine,
> > "as the answer" is associated with not "treat" but "receives",
> > and "treat" means "not ignore".
> >
> > Just putting that aside for now, I think there is a consensus that
> > Rc4 does not need a modification of current RFC3261.
>
> I see. But if there's memo of such consensus, it would be quite useful
> in interworking testing.
>
> >
> > >> UAS,
> > >> (Rs1) should not send SDP5, SDP6 and SDP7.
> > >> (Rs2) must not send SDP2 and SDP3 if these are not the same as SDP4.
> > >>
> > >> Rc3 and Rc4 are new added descriptions.
> > >> Rs1 and Rs2 are current descriptions in this draft.
> > >>
> > >> I think "MUST NOT" is suitable for (Rs1).
> > >> Because RFC3261 says
> > >> Once the UAS has sent or received an answer to the initial
> > >> offer, it MUST NOT generate subsequent offers in any responses
> > >> to the initial INVITE. This means that a UAS based on this
> > >> specification alone can never generate subsequent offers until
> > >> completion of the initial transaction.
> > >>
> > >
> > >[Gao] Yes.
> > >
> > >> SDP5 and SDP7 are regarded as "subsequent offers".
> > >
> > >[Gao] as "MUST NOT" is suitable for (Rs1), so there must be no
> "subsequent
> > >offers" in subsequent response.
> >
> > Certainly UAC MUST ignore SDPs no matter what these are.
> >
> > Regards,
> > Shinji
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip

[Christer Holmberg]

Hi,

>> In your chart SDP4 is a reliable answer. Therefore SDP5 might be
>> interpreted as a new offer, hence UAC could send an answer in PRACK.
>> Quite similarly to 3PCC cases, where 200 contains the offer and ACK the
>> answer.
>
>That has been investigated. Its not allowed. (Unfortunately I cannot
>recall the chain of reasoning that derived its illegality - it wasn't
>obvious but it was sound. It was worked out a *long* time ago.)

The rule we have agreed to is very simple: at most one offer/answer exchange per SIP transaction.

Whether it's clearly specified somewhere needs to be checked, though.

I know there are implementations that "update" the SDP answer from one reliable response to another (within the same transaction), for the same transaction, but that is certainly nothing we have standardized.

Regards,

Christer




> ------------------------------------------------------------------------
> *From:* sipping-***@ietf.org [mailto:sipping-***@ietf.org] *On
> Behalf Of *ext ***@zte.com.cn
> *Sent:* Wednesday, April 14, 2010 11:19
> *To:* OKUMURA Shinji
> *Cc:* sipping-***@ietf.org; ***@ietf.org
> *Subject:* [Sipping] 答复: Re: About offeranswer draft:
>
>
> Hi Shinji,
>
>
> sipping-***@ietf.org 写于 2010-04-14 15:31:54:
>
> > Hi Gao,
> >
> > ***@zte.com.cn
> > Wed, 14 Apr 2010 12:21:45 +0800
> > >sipping-***@ietf.org 写于 2010-04-14 11:17:23:
> > >
> > >> Hi Gao,
> > >>
> > >> In the following case,
> > >>
> > >> UAC UAS
> > >> | F1 INVITE (SDP1) | <-- offer
> > >> |-------------------->|
> > >> | F2 1xx (SDP2) |
> > >> |<--------------------|
> > >> | F3 1xx (SDP3) |
> > >> |<--------------------|
> > >> | F4 1xx-rel (SDP4) | <-- answer
> > >> |<--------------------|
> > >> | F5 1xx-rel (SDP5) |
> > >> |<--------------------|
> > >> | F6 1xxl (SDP6) |
> > >> |<--------------------|
> > >> | F7 2xx INV(SDP7) |
> > >> |<--------------------|
> > >> | F8 ACK |
> > >> |-------------------->|
> > >> (PRACK transactions are not shown)
> > >>
> > >> I tried to arrange the rules.
> > >> (small letters mean informational)
> > >>
> > >> UAC,
> > >> (Rc1) MUST treat SDP2 as the answer.
> > >> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> > >> (Rc3) may treat SDP3 as the answer.
> > >
> > >[Gao] OK
> > >
> > >> (Rc4) should treat SDP4 as the answer and confirm the current O/A
> > >> status by sending new offer.
> > >
> > >[Gao] support of this, though this may be modification of current
> RFC3261.
> >
> > You will probably think of the following statements,
> > RFC3261/13.2.1 Creating the Initial INVITE
> > (snip) "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."
> >
> > No doubt this is one of the cussword built in this document.
> > It is a personal interpretation of mine,
> > "as the answer" is associated with not "treat" but "receives",
> > and "treat" means "not ignore".
> >
> > Just putting that aside for now, I think there is a consensus that
> > Rc4 does not need a modification of current RFC3261.
>
> I see. But if there's memo of such consensus, it would be quite useful
> in interworking testing.
>
> >
> > >> UAS,
> > >> (Rs1) should not send SDP5, SDP6 and SDP7.
> > >> (Rs2) must not send SDP2 and SDP3 if these are not the same as SDP4.
> > >>
> > >> Rc3 and Rc4 are new added descriptions.
> > >> Rs1 and Rs2 are current descriptions in this draft.
> > >>
> > >> I think "MUST NOT" is suitable for (Rs1).
> > >> Because RFC3261 says
> > >> Once the UAS has sent or received an answer to the initial
> > >> offer, it MUST NOT generate subsequent offers in any responses
> > >> to the initial INVITE. This means that a UAS based on this
> > >> specification alone can never generate subsequent offers until
> > >> completion of the initial transaction.
> > >>
> > >
> > >[Gao] Yes.
> > >
> > >> SDP5 and SDP7 are regarded as "subsequent offers".
> > >
> > >[Gao] as "MUST NOT" is suitable for (Rs1), so there must be no
> "subsequent
> > >offers" in subsequent response.
> >
> > Certainly UAC MUST ignore SDPs no matter what these are.
> >
> > Regards,
> > Shinji
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@iet

[g***@zte.com.cn]

sipping-***@ietf.org ÐŽÓÚ 2010-04-15 04:38:21:

> Hi,
>
> >> In your chart SDP4 is a reliable answer. Therefore SDP5 might be
> >> interpreted as a new offer, hence UAC could send an answer in PRACK.
> >> Quite similarly to 3PCC cases, where 200 contains the offer and ACK
the
> >> answer.
> >
> >That has been investigated. Its not allowed. (Unfortunately I cannot
> >recall the chain of reasoning that derived its illegality - it wasn't
> >obvious but it was sound. It was worked out a *long* time ago.)
>
> The rule we have agreed to is very simple: at most one offer/answer
> exchange per SIP transaction.

Yes, it is. And what I talked here is also under this basic rule.

>
> Whether it's clearly specified somewhere needs to be checked, though.
>
> I know there are implementations that "update" the SDP answer from
> one reliable response to another (within the same transaction), for
> the same transaction, but that is certainly nothing we have
standardized.

I think it should be mentioned here, what is the *lawful* answer?
It is the one in the first reliable response.

As it is the *lawful* answer, I think the UAC should using it when it get
the answer. And this seems *should* be made normative.
While how UAC handle SDP(from UAS) before the real answer, it can be BCP
issue.

Why I think this should be clarified, is that during interworking testing,
we should know which side is reasonable.


Thanks,

Gao

>
> Regards,
>
> Christer
>
>
>
>
> >
------------------------------------------------------------------------
> > *From:* sipping-***@ietf.org [mailto:sipping-***@ietf.org] *On
> > Behalf Of *ext ***@zte.com.cn
> > *Sent:* Wednesday, April 14, 2010 11:19
> > *To:* OKUMURA Shinji
> > *Cc:* sipping-***@ietf.org; ***@ietf.org
> > *Subject:* [Sipping] ŽðžŽ: Re: About offeranswer draft:
> >
> >
> > Hi Shinji,
> >
> >
> > sipping-***@ietf.org ÐŽÓÚ 2010-04-14 15:31:54:
> >
> > > Hi Gao,
> > >
> > > ***@zte.com.cn
> > > Wed, 14 Apr 2010 12:21:45 +0800
> > > >sipping-***@ietf.org ÐŽÓÚ 2010-04-14 11:17:23:
> > > >
> > > >> Hi Gao,
> > > >>
> > > >> In the following case,
> > > >>
> > > >> UAC UAS
> > > >> | F1 INVITE (SDP1) | <-- offer
> > > >> |-------------------->|
> > > >> | F2 1xx (SDP2) |
> > > >> |<--------------------|
> > > >> | F3 1xx (SDP3) |
> > > >> |<--------------------|
> > > >> | F4 1xx-rel (SDP4) | <-- answer
> > > >> |<--------------------|
> > > >> | F5 1xx-rel (SDP5) |
> > > >> |<--------------------|
> > > >> | F6 1xxl (SDP6) |
> > > >> |<--------------------|
> > > >> | F7 2xx INV(SDP7) |
> > > >> |<--------------------|
> > > >> | F8 ACK |
> > > >> |-------------------->|
> > > >> (PRACK transactions are not shown)
> > > >>
> > > >> I tried to arrange the rules.
> > > >> (small letters mean informational)
> > > >>
> > > >> UAC,
> > > >> (Rc1) MUST treat SDP2 as the answer.
> > > >> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> > > >> (Rc3) may treat SDP3 as the answer.
> > > >
> > > >[Gao] OK
> > > >
> > > >> (Rc4) should treat SDP4 as the answer and confirm the current
O/A
> > > >> status by sending new offer.
> > > >
> > > >[Gao] support of this, though this may be modification of current
> > RFC3261.
> > >
> > > You will probably think of the following statements,
> > > RFC3261/13.2.1 Creating the Initial INVITE
> > > (snip) "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."
> > >
> > > No doubt this is one of the cussword built in this document.
> > > It is a personal interpretation of mine,
> > > "as the answer" is associated with not "treat" but "receives",
> > > and "treat" means "not ignore".
> > >
> > > Just putting that aside for now, I think there is a consensus that
> > > Rc4 does not need a modification of current RFC3261.
> >
> > I see. But if there's memo of such consensus, it would be quite useful
> > in interworking testing.
> >
> > >
> > > >> UAS,
> > > >> (Rs1) should not send SDP5, SDP6 and SDP7.
> > > >> (Rs2) must not send SDP2 and SDP3 if these are not the same as
SDP4.
> > > >>
> > > >> Rc3 and Rc4 are new added descriptions.
> > > >> Rs1 and Rs2 are current descriptions in this draft.
> > > >>
> > > >> I think "MUST NOT" is suitable for (Rs1).
> > > >> Because RFC3261 says
> > > >> Once the UAS has sent or received an answer to the initial
> > > >> offer, it MUST NOT generate subsequent offers in any
responses
> > > >> to the initial INVITE. This means that a UAS based on this
> > > >> specification alone can never generate subsequent offers
until
> > > >> completion of the initial transaction.
> > > >>
> > > >
> > > >[Gao] Yes.
> > > >
> > > >> SDP5 and SDP7 are regarded as "subsequent offers".
> > > >
> > > >[Gao] as "MUST NOT" is suitable for (Rs1), so there must be no
> > "subsequent
> > > >offers" in subsequent response.
> > >
> > > Certainly UAC MUST ignore SDPs no matter what these are.
> > >
> > > Regards,
> > > Shinji
> >
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in this
> mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated
> to maintain secrecy and are not permitted to disclose the contents
> of this communication to others.
> > This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please
> notify the originator of the message. Any views expressed in this
> message are those of the individual sender.
> > This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.
> >
> >
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-***@cs.columbia.edu for questions on current sip
> > Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org for new developments of core SIP


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[Paul Kyzivat]

inline

***@zte.com.cn wrote:
>
>
> sipping-***@ietf.org 写于 2010-04-15 04:38:21:
>
> > Hi,
> >
> > >> In your chart SDP4 is a reliable answer. Therefore SDP5 might be
> > >> interpreted as a new offer, hence UAC could send an answer in PRACK.
> > >> Quite similarly to 3PCC cases, where 200 contains the offer and
> ACK the
> > >> answer.
> > >
> > >That has been investigated. Its not allowed. (Unfortunately I cannot
> > >recall the chain of reasoning that derived its illegality - it wasn't
> > >obvious but it was sound. It was worked out a *long* time ago.)
> >
> > The rule we have agreed to is very simple: at most one offer/answer
> > exchange per SIP transaction.
>
> Yes, it is. And what I talked here is also under this basic rule.
>
> >
> > Whether it's clearly specified somewhere needs to be checked, though.
> >
> > I know there are implementations that "update" the SDP answer from
> > one reliable response to another (within the same transaction), for
> > the same transaction, but that is certainly nothing we have
> standardized.
>
> I think it should be mentioned here, what is the *lawful* answer?
> It is the one in the first reliable response.
>
> As it is the *lawful* answer, I think the UAC should using it when it
> get the answer. And this seems *should* be made normative.
> While how UAC handle SDP(from UAS) before the real answer, it can be BCP
> issue.

I think you are arguing that it is "lawful" for the UAS to send
differing values for the SDP successive unreliable responses and in the
subsequent reliable response. And that it is then the responsibility of
the UAC to make this work "right" and "deterministically" by honoring
the first and ignoring the subsequent ones. Is that right?

But that makes no sense. The UAS cannot know if the UAC will receive the
first, or any of, the unreliable responses. So if it were to do this odd
behavior it must be satisfied that *any* of then are the one that the
UAC uses. Or else it must be assuming that the UAC *might* use one or
more of the unreliable ones, and eventually *switch* to the one in the
reliable response.

But 3261 is clear that the UAC should use the first one it receives, and
ignore the remainder, *including* the reliable one. There is no
provision for *switching*.

Hence, its a corollary that the only behavior that the UAC can follow
that is valid and consistent in the face of loss of unreliable responses
is for them all to contain the same SDP. So that is the *lawful*
behavior - a UAS that violates this is unreasonable.

Thanks,
Paul

> Why I think this should be clarified, is that during interworking
> testing, we should know which side is reasonable.



> Thanks,
>
> Gao
>
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> > >
> ------------------------------------------------------------------------
> > > *From:* sipping-***@ietf.org [mailto:sipping-***@ietf.org] *On
> > > Behalf Of *ext ***@zte.com.cn
> > > *Sent:* Wednesday, April 14, 2010 11:19
> > > *To:* OKUMURA Shinji
> > > *Cc:* sipping-***@ietf.org; ***@ietf.org
> > > *Subject:* [Sipping] 答复: Re: About offeranswer draft:
> > >
> > >
> > > Hi Shinji,
> > >
> > >
> > > sipping-***@ietf.org 写于 2010-04-14 15:31:54:
> > >
> > > > Hi Gao,
> > > >
> > > > ***@zte.com.cn
> > > > Wed, 14 Apr 2010 12:21:45 +0800
> > > > >sipping-***@ietf.org 写于 2010-04-14 11:17:23:
> > > > >
> > > > >> Hi Gao,
> > > > >>
> > > > >> In the following case,
> > > > >>
> > > > >> UAC UAS
> > > > >> | F1 INVITE (SDP1) | <-- offer
> > > > >> |-------------------->|
> > > > >> | F2 1xx (SDP2) |
> > > > >> |<--------------------|
> > > > >> | F3 1xx (SDP3) |
> > > > >> |<--------------------|
> > > > >> | F4 1xx-rel (SDP4) | <-- answer
> > > > >> |<--------------------|
> > > > >> | F5 1xx-rel (SDP5) |
> > > > >> |<--------------------|
> > > > >> | F6 1xxl (SDP6) |
> > > > >> |<--------------------|
> > > > >> | F7 2xx INV(SDP7) |
> > > > >> |<--------------------|
> > > > >> | F8 ACK |
> > > > >> |-------------------->|
> > > > >> (PRACK transactions are not shown)
> > > > >>
> > > > >> I tried to arrange the rules.
> > > > >> (small letters mean informational)
> > > > >>
> > > > >> UAC,
> > > > >> (Rc1) MUST treat SDP2 as the answer.
> > > > >> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> > > > >> (Rc3) may treat SDP3 as the answer.
> > > > >
> > > > >[Gao] OK
> > > > >
> > > > >> (Rc4) should treat SDP4 as the answer and confirm the
> current O/A
> > > > >> status by sending new offer.
> > > > >
> > > > >[Gao] support of this, though this may be modification of current
> > > RFC3261.
> > > >
> > > > You will probably think of the following statements,
> > > > RFC3261/13.2.1 Creating the Initial INVITE
> > > > (snip) "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."
> > > >
> > > > No doubt this is one of the cussword built in this document.
> > > > It is a personal interpretation of mine,
> > > > "as the answer" is associated with not "treat" but "receives",
> > > > and "treat" means "not ignore".
> > > >
> > > > Just putting that aside for now, I think there is a consensus that
> > > > Rc4 does not need a modification of current RFC3261.
> > >
> > > I see. But if there's memo of such consensus, it would be quite useful
> > > in interworking testing.
> > >
> > > >
> > > > >> UAS,
> > > > >> (Rs1) should not send SDP5, SDP6 and SDP7.
> > > > >> (Rs2) must not send SDP2 and SDP3 if these are not the same
> as SDP4.
> > > > >>
> > > > >> Rc3 and Rc4 are new added descriptions.
> > > > >> Rs1 and Rs2 are current descriptions in this draft.
> > > > >>
> > > > >> I think "MUST NOT" is suitable for (Rs1).
> > > > >> Because RFC3261 says
> > > > >> Once the UAS has sent or received an answer to the initial
> > > > >> offer, it MUST NOT generate subsequent offers in any responses
> > > > >> to the initial INVITE. This means that a UAS based on this
> > > > >> specification alone can never generate subsequent offers until
> > > > >> completion of the initial transaction.
> > > > >>
> > > > >
> > > > >[Gao] Yes.
> > > > >
> > > > >> SDP5 and SDP7 are regarded as "subsequent offers".
> > > > >
> > > > >[Gao] as "MUST NOT" is suitable for (Rs1), so there must be no
> > > "subsequent
> > > > >offers" in subsequent response.
> > > >
> > > > Certainly UAC MUST ignore SDPs no matter what these are.
> > > >
> > > > Regards,
> > > > Shinji
> > >
> > > --------------------------------------------------------
> > > ZTE Information Security Notice: The information contained in this
> > mail is solely property of the sender's organization. This mail
> > communication is confidential. Recipients named above are obligated
> > to maintain secrecy and are not permitted to disclose the contents
> > of this communication to others.
> > > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> > are addressed. If you have received this email in error please
> > notify the originator of the message. Any views expressed in this
> > message are those of the individual sender.
> > > This message has been scanned for viruses and Spam by ZTE Anti-Spam
> system.
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use sip-***@cs.columbia.edu for questions on current sip
> > > Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
> > Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
> > Use ***@ietf.org for new developments of core SIP
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current s

[Paul Kyzivat]

Correction:

Paul Kyzivat wrote:

> Hence, its a corollary that the only behavior that the UAC can follow

I meant to say UAS above.

> that is valid and consistent in the face of loss of unreliable responses
> is for them all to contain the same SDP. So that is the *lawful*
> behavior - a UAS that violates this is unreasonable.
>
> Thanks,
> Paul
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Christer Holmberg]

Hi,

>>Whether it's clearly specified somewhere needs to be checked, though.
>>
>>I know there are implementations that "update" the SDP answer from
>>one reliable response to another (within the same transaction), for
>>the same transaction, but that is certainly nothing we have standardized.
>>
>I think it should be mentioned here, what is the *lawful* answer?
>It is the one in the first reliable response.

Agree. Whatever comes before that (unreliably), and after that (reliably OR unreliably),
has no meaning.

>>As it is the *lawful* answer, I think the UAC should using it when it
>>get the answer. And this seems *should* be made normative.
>>While how UAC handle SDP(from UAS) before the real answer, it can be BCP
>>issue.
>
>I think you are arguing that it is "lawful" for the UAS to send
>differing values for the SDP successive unreliable responses and in the
>subsequent reliable response. And that it is then the responsibility of
>the UAC to make this work "right" and "deterministically" by honoring
>the first and ignoring the subsequent ones. Is that right?
>
>But that makes no sense. The UAS cannot know if the UAC will receive the
>first, or any of, the unreliable responses. So if it were to do this odd
>behavior it must be satisfied that *any* of then are the one that the
>UAC uses. Or else it must be assuming that the UAC *might* use one or
>more of the unreliable ones, and eventually *switch* to the one in the
>reliable response.
>
>But 3261 is clear that the UAC should use the first one it receives, and
>ignore the remainder, *including* the reliable one. There is no
>provision for *switching*.

Agree.

I am aware of implementations that, once they have received a reliable SDP answer,
they don't even parse additional SDPs for the same transaction. So, they don't even
know whether the additional SDPs are identical or not.

>Hence, its a corollary that the only behavior that the UAC can follow
>that is valid and consistent in the face of loss of unreliable responses
>is for them all to contain the same SDP. So that is the *lawful*
>behavior - a UAS that violates this is unreasonable.

Yes.

Regards,

Christer








> ------------------------------------------------------------------------
> > > *From:* sipping-***@ietf.org [mailto:sipping-***@ietf.org] *On
> > > Behalf Of *ext ***@zte.com.cn
> > > *Sent:* Wednesday, April 14, 2010 11:19
> > > *To:* OKUMURA Shinji
> > > *Cc:* sipping-***@ietf.org; ***@ietf.org
> > > *Subject:* [Sipping] 答复: Re: About offeranswer draft:
> > >
> > >
> > > Hi Shinji,
> > >
> > >
> > > sipping-***@ietf.org 写于 2010-04-14 15:31:54:
> > >
> > > > Hi Gao,
> > > >
> > > > ***@zte.com.cn
> > > > Wed, 14 Apr 2010 12:21:45 +0800
> > > > >sipping-***@ietf.org 写于 2010-04-14 11:17:23:
> > > > >
> > > > >> Hi Gao,
> > > > >>
> > > > >> In the following case,
> > > > >>
> > > > >> UAC UAS
> > > > >> | F1 INVITE (SDP1) | <-- offer
> > > > >> |-------------------->|
> > > > >> | F2 1xx (SDP2) |
> > > > >> |<--------------------|
> > > > >> | F3 1xx (SDP3) |
> > > > >> |<--------------------|
> > > > >> | F4 1xx-rel (SDP4) | <-- answer
> > > > >> |<--------------------|
> > > > >> | F5 1xx-rel (SDP5) |
> > > > >> |<--------------------|
> > > > >> | F6 1xxl (SDP6) |
> > > > >> |<--------------------|
> > > > >> | F7 2xx INV(SDP7) |
> > > > >> |<--------------------|
> > > > >> | F8 ACK |
> > > > >> |-------------------->|
> > > > >> (PRACK transactions are not shown)
> > > > >>
> > > > >> I tried to arrange the rules.
> > > > >> (small letters mean informational)
> > > > >>
> > > > >> UAC,
> > > > >> (Rc1) MUST treat SDP2 as the answer.
> > > > >> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> > > > >> (Rc3) may treat SDP3 as the answer.
> > > > >
> > > > >[Gao] OK
> > > > >
> > > > >> (Rc4) should treat SDP4 as the answer and confirm the
> current O/A
> > > > >> status by sending new offer.
> > > > >
> > > > >[Gao] support of this, though this may be modification of current
> > > RFC3261.
> > > >
> > > > You will probably think of the following statements,
> > > > RFC3261/13.2.1 Creating the Initial INVITE
> > > > (snip) "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."
> > > >
> > > > No doubt this is one of the cussword built in this document.
> > > > It is a personal interpretation of mine,
> > > > "as the answer" is associated with not "treat" but "receives",
> > > > and "treat" means "not ignore".
> > > >
> > > > Just putting that aside for now, I think there is a consensus that
> > > > Rc4 does not need a modification of current RFC3261.
> > >
> > > I see. But if there's memo of such consensus, it would be quite useful
> > > in interworking testing.
> > >
> > > >
> > > > >> UAS,
> > > > >> (Rs1) should not send SDP5, SDP6 and SDP7.
> > > > >> (Rs2) must not send SDP2 and SDP3 if these are not the same
> as SDP4.
> > > > >>
> > > > >> Rc3 and Rc4 are new added descriptions.
> > > > >> Rs1 and Rs2 are current descriptions in this draft.
> > > > >>
> > > > >> I think "MUST NOT" is suitable for (Rs1).
> > > > >> Because RFC3261 says
> > > > >> Once the UAS has sent or received an answer to the initial
> > > > >> offer, it MUST NOT generate subsequent offers in any responses
> > > > >> to the initial INVITE. This means that a UAS based on this
> > > > >> specification alone can never generate subsequent offers until
> > > > >> completion of the initial transaction.
> > > > >>
> > > > >
> > > > >[Gao] Yes.
> > > > >
> > > > >> SDP5 and SDP7 are regarded as "subsequent offers".
> > > > >
> > > > >[Gao] as "MUST NOT" is suitable for (Rs1), so there must be no
> > > "subsequent
> > > > >offers" in subsequent response.
> > > >
> > > > Certainly UAC MUST ignore SDPs no matter what these are.
> > > >
> > > > Regards,
> > > > Shinji
> > >
> > > --------------------------------------------------------
> > > ZTE Information Security Notice: The information contained in this
> > mail is solely property of the sender's organization. This mail
> > communication is confidential. Recipients named above are obligated
> > to maintain secrecy and are not permitted to disclose the contents
> > of this communication to others.
> > > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> > are addressed. If you have received this email in error please
> > notify the originator of the message. Any views expressed in this
> > message are those of the individual sender.
> > > This message has been scanned for viruses and Spam by ZTE Anti-Spam
> system.
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use sip-***@cs.columbia.edu for questions on current sip
> > > Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
> > Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
> > Use ***@ietf.org for new developments of core SIP
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for n

[g***@zte.com.cn]

Christer Holmberg <***@ericsson.com>
2010-04-16 01:16

ÊÕŒþÈË
Paul Kyzivat <***@cisco.com>, "***@zte.com.cn"
<***@zte.com.cn>
³­ËÍ
"***@ietf.org" <***@ietf.org>, OKUMURA Shinji
<***@softfront.jp>
Ö÷Ìâ
RE: [Sipping] About offeranswer draft:






Hi,

>>Whether it's clearly specified somewhere needs to be checked, though.
>>
>>I know there are implementations that "update" the SDP answer from
>>one reliable response to another (within the same transaction), for
>>the same transaction, but that is certainly nothing we have
standardized.
>>
>I think it should be mentioned here, what is the *lawful* answer?
>It is the one in the first reliable response.

Agree. Whatever comes before that (unreliably), and after that (reliably
OR unreliably),
has no meaning.

>>As it is the *lawful* answer, I think the UAC should using it when it
>>get the answer. And this seems *should* be made normative.
>>While how UAC handle SDP(from UAS) before the real answer, it can be BCP
>>issue.
>
>I think you are arguing that it is "lawful" for the UAS to send
>differing values for the SDP successive unreliable responses and in the
>subsequent reliable response. And that it is then the responsibility of
>the UAC to make this work "right" and "deterministically" by honoring
>the first and ignoring the subsequent ones. Is that right?
>
>But that makes no sense. The UAS cannot know if the UAC will receive the
>first, or any of, the unreliable responses. So if it were to do this odd
>behavior it must be satisfied that *any* of then are the one that the
>UAC uses. Or else it must be assuming that the UAC *might* use one or
>more of the unreliable ones, and eventually *switch* to the one in the
>reliable response.
>
>But 3261 is clear that the UAC should use the first one it receives, and
>ignore the remainder, *including* the reliable one. There is no
>provision for *switching*.

Agree.

I am aware of implementations that, once they have received a reliable SDP
answer,
they don't even parse additional SDPs for the same transaction. So, they
don't even
know whether the additional SDPs are identical or not.

[Gao] Yes.
But when the UAC have received the SDP in one unreliable response, could
it ignore subsequent SDP, even the REAL ANSWER. By current RFC3261, it
should ignore subsequent SDP, even the REAL ANSWER.

Now, we also have other signal rules on O/A, such as sending UPDATE after
the ini-O/A. The key here is, IS the SDP (in unreliable before the real
ANSWER) answer?
If it is answer, then signal rules on O/A need to be corrected.
If it is not answer, the RFC3261's text seems need correction.

As O/A draft does not aim for normative correction, so I just feel it
seams need a normative one. I guess Paul has the prestige to draft such
text:)

>Hence, its a corollary that the only behavior that the UAC can follow
>that is valid and consistent in the face of loss of unreliable responses
>is for them all to contain the same SDP. So that is the *lawful*
>behavior - a UAS that violates this is unreasonable.

Yes.

Regards,

Christer



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[g***@zte.com.cn]

Hi Paul,

My previous mail to Christer is about the same topic.


To be honest, your agree almost all of your reply. And I once have the
same understanding of RFC3261.
But when I reviewed again during the interworking-testing(in new
interworking-testing, we always face some new equipment and hear some new
understanding of RFC3261 from them), I feel it seams need correction.

Thanks,

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================



Paul Kyzivat <***@cisco.com>
2010-04-15 22:59

ÊÕŒþÈË
***@zte.com.cn
³­ËÍ
Christer Holmberg <***@ericsson.com>, "Somogyi, Gabor (NSN -
HU/Budapest)" <***@nsn.com>, OKUMURA Shinji
<***@softfront.jp>, "***@ietf.org" <***@ietf.org>
Ö÷Ìâ
Re: [Sipping] About offeranswer draft:






inline

***@zte.com.cn wrote:
>
>
> sipping-***@ietf.org ÐŽÓÚ 2010-04-15 04:38:21:
>
> > Hi,
> >
> > >> In your chart SDP4 is a reliable answer. Therefore SDP5 might be
> > >> interpreted as a new offer, hence UAC could send an answer in
PRACK.
> > >> Quite similarly to 3PCC cases, where 200 contains the offer and
> ACK the
> > >> answer.
> > >
> > >That has been investigated. Its not allowed. (Unfortunately I cannot
> > >recall the chain of reasoning that derived its illegality - it
wasn't
> > >obvious but it was sound. It was worked out a *long* time ago.)
> >
> > The rule we have agreed to is very simple: at most one offer/answer
> > exchange per SIP transaction.
>
> Yes, it is. And what I talked here is also under this basic rule.
>
> >
> > Whether it's clearly specified somewhere needs to be checked, though.
> >
> > I know there are implementations that "update" the SDP answer from
> > one reliable response to another (within the same transaction), for
> > the same transaction, but that is certainly nothing we have
> standardized.
>
> I think it should be mentioned here, what is the *lawful* answer?
> It is the one in the first reliable response.
>
> As it is the *lawful* answer, I think the UAC should using it when it
> get the answer. And this seems *should* be made normative.
> While how UAC handle SDP(from UAS) before the real answer, it can be BCP

> issue.

I think you are arguing that it is "lawful" for the UAS to send
differing values for the SDP successive unreliable responses and in the
subsequent reliable response. And that it is then the responsibility of
the UAC to make this work "right" and "deterministically" by honoring
the first and ignoring the subsequent ones. Is that right?

But that makes no sense. The UAS cannot know if the UAC will receive the
first, or any of, the unreliable responses. So if it were to do this odd
behavior it must be satisfied that *any* of then are the one that the
UAC uses. Or else it must be assuming that the UAC *might* use one or
more of the unreliable ones, and eventually *switch* to the one in the
reliable response.

But 3261 is clear that the UAC should use the first one it receives, and
ignore the remainder, *including* the reliable one. There is no
provision for *switching*.

Hence, its a corollary that the only behavior that the UAC can follow
that is valid and consistent in the face of loss of unreliable responses
is for them all to contain the same SDP. So that is the *lawful*
behavior - a UAS that violates this is unreasonable.

Thanks,
Paul



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[Christer Holmberg]

Hi,

>My previous mail to Christer is about the same topic.
>
>
>To be honest, your agree almost all of your reply. And I once have the same understanding of RFC3261.
>But when I reviewed again during the interworking-testing(in new interworking-testing, we always face some new equipment and hear some new understanding of RFC3261 from them), I feel it seams need correction.

That is why we are working with the o/a draft, which hopefully will clarify things for people.

Regards,

Christer




Thanks,

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================



Paul Kyzivat <***@cisco.com>

2010-04-15 22:59


收件人
***@zte.com.cn
抄送
Christer Holmberg <***@ericsson.com>, "Somogyi, Gabor (NSN - HU/Budapest)" <***@nsn.com>, OKUMURA Shinji <***@softfront.jp>, "***@ietf.org" <***@ietf.org>
主题
Re: [Sipping] About offeranswer draft:






inline

***@zte.com.cn wrote:
>
>
> sipping-***@ietf.org 写于 2010-04-15 04:38:21:
>
> > Hi,
> >
> > >> In your chart SDP4 is a reliable answer. Therefore SDP5 might be
> > >> interpreted as a new offer, hence UAC could send an answer in PRACK.
> > >> Quite similarly to 3PCC cases, where 200 contains the offer and
> ACK the
> > >> answer.
> > >
> > >That has been investigated. Its not allowed. (Unfortunately I cannot
> > >recall the chain of reasoning that derived its illegality - it wasn't
> > >obvious but it was sound. It was worked out a *long* time ago.)
> >
> > The rule we have agreed to is very simple: at most one offer/answer
> > exchange per SIP transaction.
>
> Yes, it is. And what I talked here is also under this basic rule.
>
> >
> > Whether it's clearly specified somewhere needs to be checked, though.
> >
> > I know there are implementations that "update" the SDP answer from
> > one reliable response to another (within the same transaction), for
> > the same transaction, but that is certainly nothing we have
> standardized.
>
> I think it should be mentioned here, what is the *lawful* answer?
> It is the one in the first reliable response.
>
> As it is the *lawful* answer, I think the UAC should using it when it
> get the answer. And this seems *should* be made normative.
> While how UAC handle SDP(from UAS) before the real answer, it can be BCP
> issue.

I think you are arguing that it is "lawful" for the UAS to send
differing values for the SDP successive unreliable responses and in the
subsequent reliable response. And that it is then the responsibility of
the UAC to make this work "right" and "deterministically" by honoring
the first and ignoring the subsequent ones. Is that right?

But that makes no sense. The UAS cannot know if the UAC will receive the
first, or any of, the unreliable responses. So if it were to do this odd
behavior it must be satisfied that *any* of then are the one that the
UAC uses. Or else it must be assuming that the UAC *might* use one or
more of the unreliable ones, and eventually *switch* to the one in the
reliable response.

But 3261 is clear that the UAC should use the first one it receives, and
ignore the remainder, *including* the reliable one. There is no
provision for *switching*.

Hence, its a corollary that the only behavior that the UAC can follow
that is valid and consistent in the face of loss of unreliable responses
is for them all to contain the same SDP. So that is the *lawful*
behavior - a UAS that violates this is unreasonable.

Thanks,
Paul


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.


_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current

[g***@zte.com.cn]

Hi,

But as we know, O/A draft is just for clarification, not for correction.

Thanks,

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================



Christer Holmberg <***@ericsson.com>
2010-04-16 13:39

ÊÕŒþÈË
"***@zte.com.cn" <***@zte.com.cn>, Paul Kyzivat
<***@cisco.com>
³­ËÍ
"***@ietf.org" <***@ietf.org>
Ö÷Ìâ
RE: [Sipping] About offeranswer draft:







Hi,

>My previous mail to Christer is about the same topic.
>
>
>To be honest, your agree almost all of your reply. And I once have the
same understanding of RFC3261.
>But when I reviewed again during the interworking-testing(in new
interworking-testing, we always face some new equipment and hear some new
understanding of RFC3261 from them), I feel it seams need correction.

That is why we are working with the o/a draft, which hopefully will
clarify things for people.

Regards,

Christer




Thanks,

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================



Paul Kyzivat <***@cisco.com>

2010-04-15 22:59


ÊÕŒþÈË
***@zte.com.cn
³­ËÍ
Christer Holmberg
<***@ericsson.com>, "Somogyi, Gabor (NSN - HU/Budapest)"
<***@nsn.com>, OKUMURA Shinji <***@softfront.jp>,
"***@ietf.org" <***@ietf.org>
Ö÷Ìâ
Re: [Sipping] About offeranswer draft:






inline

***@zte.com.cn wrote:
>
>
> sipping-***@ietf.org ÐŽÓÚ 2010-04-15 04:38:21:
>
> > Hi,
> >
> > >> In your chart SDP4 is a reliable answer.
Therefore SDP5 might be
> > >> interpreted as a new offer, hence UAC could send
an answer in PRACK.
> > >> Quite similarly to 3PCC cases, where 200 contains
the offer and
> ACK the
> > >> answer.
> > >
> > >That has been investigated. Its not allowed.
(Unfortunately I cannot
> > >recall the chain of reasoning that derived its
illegality - it wasn't
> > >obvious but it was sound. It was worked out a
*long* time ago.)
> >
> > The rule we have agreed to is very simple: at most
one offer/answer
> > exchange per SIP transaction.
>
> Yes, it is. And what I talked here is also under this
basic rule.
>
> >
> > Whether it's clearly specified somewhere needs to be
checked, though.
> >
> > I know there are implementations that "update" the
SDP answer from
> > one reliable response to another (within the same
transaction), for
> > the same transaction, but that is certainly nothing
we have
> standardized.
>
> I think it should be mentioned here, what is the
*lawful* answer?
> It is the one in the first reliable response.
>
> As it is the *lawful* answer, I think the UAC should
using it when it
> get the answer. And this seems *should* be made
normative.
> While how UAC handle SDP(from UAS) before the real
answer, it can be BCP
> issue.

I think you are arguing that it is "lawful" for the UAS
to send
differing values for the SDP successive unreliable
responses and in the
subsequent reliable response. And that it is then the
responsibility of
the UAC to make this work "right" and "deterministically"
by honoring
the first and ignoring the subsequent ones. Is that
right?

But that makes no sense. The UAS cannot know if the UAC
will receive the
first, or any of, the unreliable responses. So if it were
to do this odd
behavior it must be satisfied that *any* of then are the
one that the
UAC uses. Or else it must be assuming that the UAC
*might* use one or
more of the unreliable ones, and eventually *switch* to
the one in the
reliable response.

But 3261 is clear that the UAC should use the first one
it receives, and
ignore the remainder, *including* the reliable one. There
is no
provision for *switching*.

Hence, its a corollary that the only behavior that the
UAC can follow
that is valid and consistent in the face of loss of
unreliable responses
is for them all to contain the same SDP. So that is the
*lawful*
behavior - a UAS that violates this is unreasonable.

Thanks,
Paul


--------------------------------------------------------
ZTE Information Security Notice: The information
contained in this mail is solely property of the sender's organization.
This mail communication is confidential. Recipients named above are
obligated to maintain secrecy and are not permitted to disclose the
contents of this communication to others.
This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity
to whom they are addressed. If you have received this email in error
please notify the originator of the message. Any views expressed in this
message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE
Anti-Spam system.






--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[Christer Holmberg]

So, what is it actually that you want to correct?

________________________________
From: ***@zte.com.cn [mailto:***@zte.com.cn]
Sent: 16. huhtikuuta 2010 8:44
To: Christer Holmberg
Cc: Paul Kyzivat; ***@ietf.org
Subject: RE: [Sipping] About offeranswer draft:


Hi,

But as we know, O/A draft is just for clarification, not for correction.

Thanks,

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================


Christer Holmberg <***@ericsson.com>

2010-04-16 13:39

ÊÕŒþÈË
"***@zte.com.cn" <***@zte.com.cn>, Paul Kyzivat <***@cisco.com>
³­ËÍ
"***@ietf.org" <***@ietf.org>
Ö÷Ìâ
RE: [Sipping] About offeranswer draft:






Hi,

>My previous mail to Christer is about the same topic.
>
>
>To be honest, your agree almost all of your reply. And I once have the same understanding of RFC3261.
>But when I reviewed again during the interworking-testing(in new interworking-testing, we always face some new equipment and hear some new understanding of RFC3261 from them), I feel it seams need correction.

That is why we are working with the o/a draft, which hopefully will clarify things for people.

Regards,

Christer




Thanks,

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================



Paul Kyzivat <***@cisco.com>

2010-04-15 22:59


ÊÕŒþÈË
***@zte.com.cn
³­ËÍ
Christer Holmberg <***@ericsson.com>, "Somogyi, Gabor (NSN - HU/Budapest)" <***@nsn.com>, OKUMURA Shinji <***@softfront.jp>, "***@ietf.org" <***@ietf.org>
Ö÷Ìâ
Re: [Sipping] About offeranswer draft:






inline

***@zte.com.cn wrote:
>
>
> sipping-***@ietf.org ÐŽÓÚ 2010-04-15 04:38:21:
>
> > Hi,
> >
> > >> In your chart SDP4 is a reliable answer. Therefore SDP5 might be
> > >> interpreted as a new offer, hence UAC could send an answer in PRACK.
> > >> Quite similarly to 3PCC cases, where 200 contains the offer and
> ACK the
> > >> answer.
> > >
> > >That has been investigated. Its not allowed. (Unfortunately I cannot
> > >recall the chain of reasoning that derived its illegality - it wasn't
> > >obvious but it was sound. It was worked out a *long* time ago.)
> >
> > The rule we have agreed to is very simple: at most one offer/answer
> > exchange per SIP transaction.
>
> Yes, it is. And what I talked here is also under this basic rule.
>
> >
> > Whether it's clearly specified somewhere needs to be checked, though.
> >
> > I know there are implementations that "update" the SDP answer from
> > one reliable response to another (within the same transaction), for
> > the same transaction, but that is certainly nothing we have
> standardized.
>
> I think it should be mentioned here, what is the *lawful* answer?
> It is the one in the first reliable response.
>
> As it is the *lawful* answer, I think the UAC should using it when it
> get the answer. And this seems *should* be made normative.
> While how UAC handle SDP(from UAS) before the real answer, it can be BCP
> issue.

I think you are arguing that it is "lawful" for the UAS to send
differing values for the SDP successive unreliable responses and in the
subsequent reliable response. And that it is then the responsibility of
the UAC to make this work "right" and "deterministically" by honoring
the first and ignoring the subsequent ones. Is that right?

But that makes no sense. The UAS cannot know if the UAC will receive the
first, or any of, the unreliable responses. So if it were to do this odd
behavior it must be satisfied that *any* of then are the one that the
UAC uses. Or else it must be assuming that the UAC *might* use one or
more of the unreliable ones, and eventually *switch* to the one in the
reliable response.

But 3261 is clear that the UAC should use the first one it receives, and
ignore the remainder, *including* the reliable one. There is no
provision for *switching*.

Hence, its a corollary that the only behavior that the UAC can follow
that is valid and consistent in the face of loss of unreliable responses
is for them all to contain the same SDP. So that is the *lawful*
behavior - a UAS that violates this is unreasonable.

Thanks,
Paul


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.





--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[g***@zte.com.cn]

Please see
http://www.ietf.org/mail-archive/web/sipping/current/msg17552.html

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================



Christer Holmberg <***@ericsson.com>
2010-04-16 13:47

ÊÕŒþÈË
"***@zte.com.cn" <***@zte.com.cn>
³­ËÍ
Paul Kyzivat <***@cisco.com>, "***@ietf.org" <***@ietf.org>
Ö÷Ìâ
RE: [Sipping] About offeranswer draft:






So, what is it actually that you want to correct?

From: ***@zte.com.cn [mailto:***@zte.com.cn]
Sent: 16. huhtikuuta 2010 8:44
To: Christer Holmberg
Cc: Paul Kyzivat; ***@ietf.org
Subject: RE: [Sipping] About offeranswer draft:


Hi,

But as we know, O/A draft is just for clarification, not for correction.

Thanks,

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================


Christer Holmberg <***@ericsson.com>
2010-04-16 13:39


ÊÕŒþÈË
"***@zte.com.cn" <***@zte.com.cn>, Paul Kyzivat
<***@cisco.com>
³­ËÍ
"***@ietf.org" <***@ietf.org>
Ö÷Ìâ
RE: [Sipping] About offeranswer draft:









Hi,

>My previous mail to Christer is about the same topic.
>
>
>To be honest, your agree almost all of your reply. And I once have the
same understanding of RFC3261.
>But when I reviewed again during the interworking-testing(in new
interworking-testing, we always face some new equipment and hear some new
understanding of RFC3261 from them), I feel it seams need correction.

That is why we are working with the o/a draft, which hopefully will
clarify things for people.

Regards,

Christer




Thanks,

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================



Paul Kyzivat <***@cisco.com>

2010-04-15 22:59


ÊÕŒþÈË
***@zte.com.cn
³­ËÍ
Christer Holmberg
<***@ericsson.com>, "Somogyi, Gabor (NSN - HU/Budapest)"
<***@nsn.com>, OKUMURA Shinji <***@softfront.jp>,
"***@ietf.org" <***@ietf.org>
Ö÷Ìâ
Re: [Sipping] About offeranswer draft:






inline

***@zte.com.cn wrote:
>
>
> sipping-***@ietf.org ÐŽÓÚ 2010-04-15 04:38:21:
>
> > Hi,
> >
> > >> In your chart SDP4 is a reliable answer. Therefore
SDP5 might be
> > >> interpreted as a new offer, hence UAC could send
an answer in PRACK.
> > >> Quite similarly to 3PCC cases, where 200 contains
the offer and
> ACK the
> > >> answer.
> > >
> > >That has been investigated. Its not allowed.
(Unfortunately I cannot
> > >recall the chain of reasoning that derived its
illegality - it wasn't
> > >obvious but it was sound. It was worked out a *long*
time ago.)
> >
> > The rule we have agreed to is very simple: at most
one offer/answer
> > exchange per SIP transaction.
>
> Yes, it is. And what I talked here is also under this
basic rule.
>
> >
> > Whether it's clearly specified somewhere needs to be
checked, though.
> >
> > I know there are implementations that "update" the
SDP answer from
> > one reliable response to another (within the same
transaction), for
> > the same transaction, but that is certainly nothing
we have
> standardized.
>
> I think it should be mentioned here, what is the
*lawful* answer?
> It is the one in the first reliable response.
>
> As it is the *lawful* answer, I think the UAC should
using it when it
> get the answer. And this seems *should* be made
normative.
> While how UAC handle SDP(from UAS) before the real
answer, it can be BCP
> issue.

I think you are arguing that it is "lawful" for the UAS to
send
differing values for the SDP successive unreliable
responses and in the
subsequent reliable response. And that it is then the
responsibility of
the UAC to make this work "right" and "deterministically"
by honoring
the first and ignoring the subsequent ones. Is that right?

But that makes no sense. The UAS cannot know if the UAC
will receive the
first, or any of, the unreliable responses. So if it were
to do this odd
behavior it must be satisfied that *any* of then are the
one that the
UAC uses. Or else it must be assuming that the UAC *might*
use one or
more of the unreliable ones, and eventually *switch* to
the one in the
reliable response.

But 3261 is clear that the UAC should use the first one it
receives, and
ignore the remainder, *including* the reliable one. There
is no
provision for *switching*.

Hence, its a corollary that the only behavior that the UAC
can follow
that is valid and consistent in the face of loss of
unreliable responses
is for them all to contain the same SDP. So that is the
*lawful*
behavior - a UAS that violates this is unreasonable.

Thanks,
Paul


--------------------------------------------------------
ZTE Information Security Notice: The information contained
in this mail is solely property of the sender's organization. This mail
communication is confidential. Recipients named above are obligated to
maintain secrecy and are not permitted to disclose the contents of this
communication to others.
This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity
to whom they are addressed. If you have received this email in error
please notify the originator of the message. Any views expressed in this
message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE
Anti-Spam system.




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is
solely property of the sender's organization. This mail communication is
confidential. Recipients named above are obligated to maintain secrecy and
are not permitted to disclose the contents of this communication to
others.
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the originator of
the message. Any views expressed in this message are those of the
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[Christer Holmberg]

Hi,

I think you need to separate things.

Since the SDP in the unreliable and reliable responses shall be the same, the UAC should not have to look at the SDP in the reliable response, if it is already "using" the SDP from an unreliable answer.

However, even if the UAC is using the SDP from an unreliable response, the UAC can not initiate a new offer/answer transaction before it has received the reliable response, because the reliable response terminates the offer/answer transaction.

So, just because the UAC is using an SDP from an unrelaible response, it doesn't mean that the offer/answer transaction is finished.

Regards,

Christer

________________________________
From: ***@zte.com.cn [mailto:***@zte.com.cn]
Sent: 16. huhtikuuta 2010 8:49
To: Christer Holmberg
Cc: Paul Kyzivat; ***@ietf.org
Subject: ŽðžŽ: RE: [Sipping] About offeranswer draft:


Please see http://www.ietf.org/mail-archive/web/sipping/current/msg17552.html

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================


Christer Holmberg <***@ericsson.com>

2010-04-16 13:47

ÊÕŒþÈË
"***@zte.com.cn" <***@zte.com.cn>
³­ËÍ
Paul Kyzivat <***@cisco.com>, "***@ietf.org" <***@ietf.org>
Ö÷Ìâ
RE: [Sipping] About offeranswer draft:





So, what is it actually that you want to correct?

________________________________
From: ***@zte.com.cn [mailto:***@zte.com.cn]
Sent: 16. huhtikuuta 2010 8:44
To: Christer Holmberg
Cc: Paul Kyzivat; ***@ietf.org
Subject: RE: [Sipping] About offeranswer draft:


Hi,

But as we know, O/A draft is just for clarification, not for correction.

Thanks,

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================

Christer Holmberg <***@ericsson.com>

2010-04-16 13:39

ÊÕŒþÈË
"***@zte.com.cn" <***@zte.com.cn>, Paul Kyzivat <***@cisco.com>
³­ËÍ
"***@ietf.org" <***@ietf.org>
Ö÷Ìâ
RE: [Sipping] About offeranswer draft:








Hi,

>My previous mail to Christer is about the same topic.
>
>
>To be honest, your agree almost all of your reply. And I once have the same understanding of RFC3261.
>But when I reviewed again during the interworking-testing(in new interworking-testing, we always face some new equipment and hear some new understanding of RFC3261 from them), I feel it seams need correction.

That is why we are working with the o/a draft, which hopefully will clarify things for people.

Regards,

Christer




Thanks,

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================



Paul Kyzivat <***@cisco.com>

2010-04-15 22:59


ÊÕŒþÈË
***@zte.com.cn
³­ËÍ
Christer Holmberg <***@ericsson.com>, "Somogyi, Gabor (NSN - HU/Budapest)" <***@nsn.com>, OKUMURA Shinji <***@softfront.jp>, "***@ietf.org" <***@ietf.org>
Ö÷Ìâ
Re: [Sipping] About offeranswer draft:






inline

***@zte.com.cn wrote:
>
>
> sipping-***@ietf.org ÐŽÓÚ 2010-04-15 04:38:21:
>
> > Hi,
> >
> > >> In your chart SDP4 is a reliable answer. Therefore SDP5 might be
> > >> interpreted as a new offer, hence UAC could send an answer in PRACK.
> > >> Quite similarly to 3PCC cases, where 200 contains the offer and
> ACK the
> > >> answer.
> > >
> > >That has been investigated. Its not allowed. (Unfortunately I cannot
> > >recall the chain of reasoning that derived its illegality - it wasn't
> > >obvious but it was sound. It was worked out a *long* time ago.)
> >
> > The rule we have agreed to is very simple: at most one offer/answer
> > exchange per SIP transaction.
>
> Yes, it is. And what I talked here is also under this basic rule.
>
> >
> > Whether it's clearly specified somewhere needs to be checked, though.
> >
> > I know there are implementations that "update" the SDP answer from
> > one reliable response to another (within the same transaction), for
> > the same transaction, but that is certainly nothing we have
> standardized.
>
> I think it should be mentioned here, what is the *lawful* answer?
> It is the one in the first reliable response.
>
> As it is the *lawful* answer, I think the UAC should using it when it
> get the answer. And this seems *should* be made normative.
> While how UAC handle SDP(from UAS) before the real answer, it can be BCP
> issue.

I think you are arguing that it is "lawful" for the UAS to send
differing values for the SDP successive unreliable responses and in the
subsequent reliable response. And that it is then the responsibility of
the UAC to make this work "right" and "deterministically" by honoring
the first and ignoring the subsequent ones. Is that right?

But that makes no sense. The UAS cannot know if the UAC will receive the
first, or any of, the unreliable responses. So if it were to do this odd
behavior it must be satisfied that *any* of then are the one that the
UAC uses. Or else it must be assuming that the UAC *might* use one or
more of the unreliable ones, and eventually *switch* to the one in the
reliable response.

But 3261 is clear that the UAC should use the first one it receives, and
ignore the remainder, *including* the reliable one. There is no
provision for *switching*.

Hence, its a corollary that the only behavior that the UAC can follow
that is valid and consistent in the face of loss of unreliable responses
is for them all to contain the same SDP. So that is the *lawful*
behavior - a UAS that violates this is unreasonable.

Thanks,
Paul


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[g***@zte.com.cn]

Hi,

Christer Holmberg <***@ericsson.com> ÐŽÓÚ 2010-04-16
14:24:33:

> Hi,
>
> I think you need to separate things.
>
> Since the SDP in the unreliable and reliable responses shall be the
> same, the UAC should not have to look at the SDP in the reliable
> response, if it is already "using" the SDP from an unreliable answer.
>
> However, even if the UAC is using the SDP from an unreliable
> response, the UAC can not initiate a new offer/answer transaction
> before it has received the reliable response, because the reliable
> response terminates the offer/answer transaction.

[Gao] I know it well.
But RFC3261 said UAC MUST treat the SDP(which we think should not be the
ANSWER, at most treat it as if answer) as answer.

During interworking testing, the other side's people said it is answer,
then it(the UAC) has finished it's Ini-O/A, what's normative text can you
use to convince them?

So, first we should correct RFC3261 clearly that the SDP in unreliable
response is not ANSWER, even it is the first SDP UAC got.

Until finishing of the correction, we *MAY* do BCP thing on the handling
of such SDP. And about BCP, I think there still are two alternative:
1. as O/A draft says, such SDP MUST be the same as the subsequent real
answer. And UAC MUST using it AS IF answer.

2. Do not do such MUST/MUST NOT restrict, just let UAC's free to handle
the SDP. If the UAC use it, OK; just ignore it, also OK. But the UAC MUST
handle the real ANSWER as answer.

Thanks,

Gao

>
> So, just because the UAC is using an SDP from an unrelaible
> response, it doesn't mean that the offer/answer transaction is finished.
>
> Regards,
>
> Christer
>
> From: ***@zte.com.cn [mailto:***@zte.com.cn]
> Sent: 16. huhtikuuta 2010 8:49
> To: Christer Holmberg
> Cc: Paul Kyzivat; ***@ietf.org
> Subject: ŽðžŽ: RE: [Sipping] About offeranswer draft:

>
> Please see
http://www.ietf.org/mail-archive/web/sipping/current/msg17552.html
>
> ===================================
> Zip : 210012
> Tel : 87211
> Tel2 :([phone]
> e_mail : ***@zte.com.cn
> ===================================
>




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[Christer Holmberg]

Hi,

> I think you need to separate things.
>
> Since the SDP in the unreliable and reliable responses shall be the
> same, the UAC should not have to look at the SDP in the reliable
> response, if it is already "using" the SDP from an unreliable answer.
>
> However, even if the UAC is using the SDP from an unreliable
> response, the UAC can not initiate a new offer/answer transaction
> before it has received the reliable response, because the reliable
> response terminates the offer/answer transaction.
>
>[Gao] I know it well.
>But RFC3261 said UAC MUST treat the SDP(which we think should not be the ANSWER, at most treat it as if answer) as answer.
>
>During interworking testing, the other side's people said it is answer, then it(the UAC) has finished it's Ini-O/A, what's normative text can you use to convince them?

You tell them that an offer/answer transaction is not finished until the answer has been delivered reliably.

>So, first we should correct RFC3261 clearly that the SDP in unreliable response is not ANSWER, even it is the first SDP UAC got.

Could you please show the text in 3261 which says that the SDP in an unreliable response is the SDP answer?

>Until finishing of the correction, we *MAY* do BCP thing on the handling of such SDP. And about BCP, I think there still are two alternative:
>1. as O/A draft says, such SDP MUST be the same as the subsequent real answer. And UAC MUST using it AS IF answer.

Since it has to be the same, it doesn't really matter which the UAC uses. But still, the offer/answer transaction is not finished until the SDP has been received reliably.

>2. Do not do such MUST/MUST NOT restrict, just let UAC's free to handle the SDP. If the UAC use it, OK; just ignore it, also OK. But the UAC MUST handle the real ANSWER as answer.

I am not really sure what you mean, but I am the first one to agree that offer/answer, and usage of SDP in SIP, is a big mess. We use SIP message to carry SDP, mix together session control and media control, but there is not always a one-to-one mapping between SIP transactions and offer/answer exchanges, and therefor we need to define rules on what you can insert where, etc.

Regards,

Christer


>
> So, just because the UAC is using an SDP from an unrelaible
> response, it doesn't mean that the offer/answer transaction is finished.
>
> Regards,
>
> Christer
>
> From: ***@zte.com.cn [mailto:***@zte.com.cn]
> Sent: 16. huhtikuuta 2010 8:49
> To: Christer Holmberg
> Cc: Paul Kyzivat; ***@ietf.org
> Subject: 答复: RE: [Sipping] About offeranswer draft:

>
> Please see http://www.ietf.org/mail-archive/web/sipping/current/msg17552.html
>
> ===================================
> Zip : 210012
> Tel : 87211
> Tel2 :([phone]
> e_mail : ***@zte.com.cn
> ===================================
>



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.


_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for ne

[g***@zte.com.cn]

Christer Holmberg <***@ericsson.com> ÐŽÓÚ 2010-04-16
15:00:43:

>
> Hi,
>
> > I think you need to separate things.
> >
> > Since the SDP in the unreliable and reliable responses shall be the
> > same, the UAC should not have to look at the SDP in the reliable
> > response, if it is already "using" the SDP from an unreliable answer.
> >
> > However, even if the UAC is using the SDP from an unreliable
> > response, the UAC can not initiate a new offer/answer transaction
> > before it has received the reliable response, because the reliable
> > response terminates the offer/answer transaction.
> >
> >[Gao] I know it well.
> >But RFC3261 said UAC MUST treat the SDP(which we think should not
> be the ANSWER, at most treat it as if answer) as answer.
> >
> >During interworking testing, the other side's people said it is
> answer, then it(the UAC) has finished it's Ini-O/A, what's
> normative text can you use to convince them?
>
> You tell them that an offer/answer transaction is not finished until
> the answer has been delivered reliably.
>
> >So, first we should correct RFC3261 clearly that the SDP in
> unreliable response is not ANSWER, even it is the first SDP UAC got.
>
> Could you please show the text in 3261 which says that the SDP in an
> unreliable response is the SDP answer?

[Gao]: text from 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.

And, considering UAS send SDP in unreliable response before the answer,
then the SDP would be the the first session
description it receives.

RFC3261 using the word "AS THE ANSWER", not as if.

>
> >Until finishing of the correction, we *MAY* do BCP thing on the
> handling of such SDP. And about BCP, I think there still are two
alternative:
> >1. as O/A draft says, such SDP MUST be the same as the subsequent
> real answer. And UAC MUST using it AS IF answer.
>
> Since it has to be the same, it doesn't really matter which the UAC
> uses. But still, the offer/answer transaction is not finished until
> the SDP has been received reliably.
>
> >2. Do not do such MUST/MUST NOT restrict, just let UAC's free to
> handle the SDP. If the UAC use it, OK; just ignore it, also OK. But
> the UAC MUST handle the real ANSWER as answer.
>
> I am not really sure what you mean, but I am the first one to agree
> that offer/answer, and usage of SDP in SIP, is a big mess. We use
> SIP message to carry SDP, mix together session control and media
> control, but there is not always a one-to-one mapping between SIP
> transactions and offer/answer exchanges, and therefor we need to
> define rules on what you can insert where, etc.
>
> Regards,
>
> Christer
>
>
> >
> > So, just because the UAC is using an SDP from an unrelaible
> > response, it doesn't mean that the offer/answer transaction is
finished.
> >
> > Regards,
> >
> > Christer
> >
> > From: ***@zte.com.cn [mailto:***@zte.com.cn]
> > Sent: 16. huhtikuuta 2010 8:49
> > To: Christer Holmberg
> > Cc: Paul Kyzivat; ***@ietf.org
> > Subject: ŽðžŽ: RE: [Sipping] About offeranswer draft:
>
> >
> > Please see http://www.ietf.org/mail-
> archive/web/sipping/current/msg17552.html
> >
> > ===================================
> > Zip : 210012
> > Tel : 87211
> > Tel2 :([phone]
> > e_mail : ***@zte.com.cn
> > ===================================
> >
>
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in
> this mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated
> to maintain secrecy and are not permitted to disclose the contents
> of this communication to others.
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please
> notify the originator of the message. Any views expressed in this
> message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.
>
>



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[Paul Kyzivat]

I think we are now down to the essence of the question:

***@zte.com.cn wrote:

> > Could you please show the text in 3261 which says that the SDP in an
> > unreliable response is the SDP answer?
>
> [Gao]: text from 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.
>
> And, considering UAS send SDP in unreliable response before the answer,
> then the SDP would be the *the first session*
> * description it receives*.
>
> RFC3261 using the word "AS THE ANSWER", not as if.

At this point, we are arguing about the *intent* of the text - it is
clearly confusing to some people.

And AFAIK we (me, Gao, Shinji, and Christer) are all in agreement that
the intent of the existing text is that:

- *if* the UAC receives SDP in an unreliable response before
receiving it in a reliable response, it MUST begin to use it
in the same way that it would use it if that SDP had been
received in a reliable response,

- but that it is not officially "the answer", and so it is not
yet permissible to initiate another o/a exchange until a reliable
response containing "the answer" is received.

- but when "the answer" is received, it MUST be ignored
(rather than "used") if an earlier SDP has already been
received and so "treated as the answer".

Are *we* all in agreement that this is the one and only *intended*
meaning of the text?

Then the issue is that *someone else* (who Gao has had occasion to do
interop testing with) is claiming that there is a different, yet
legitimate, interpretation of the exiting text. Namely:

- *if* the UAC receives SDP in an unreliable response before
receiving it in a reliable response, it MUST begin to use it
in the same way that it would use it if it had been received
in a reliable response,

- the UAC MUST (or SHOULD?) consider this SDP to be "the answer",
and hence it MAY send another offer, even before receiving
another copy of that answer SDP in a *reliable* response.

- still it MUST ignore SDP in subsequent responses to the
INVITE.

If so, then the question comes down to:

Is this alternate interpretation a valid and legitimate interpretation
of the existing text, or not?

I agree that this is a fair question to ask, and I am not yet settled on
an answer to it.

I am approaching this in the manner of a mathematical proof by
contradiction: If this alternative interpretation leads to some sort of
inconsistency, then it is not valid. If we can find no inconsistencies,
then it is a valid interpretation. And if it is, then the text is
ambiguous and will require normative changes to fix.

So, we can either seek out such an inconsistency, OR we can simply
concede that the text is ambiguous and begin work on a normative
correction to address it.

I'm pretty sure that we are going to reach the same endpoint either way.
So its a matter of whether we need a normative document to convince
everyone or not.

I'd appreciate feedback on my logic above.

Thank you,
Paul
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Anders Kristensen]

Inline...

On 4/16/2010 3:14 PM, Paul Kyzivat wrote:
> I think we are now down to the essence of the question:
>
> ***@zte.com.cn wrote:
>
>> > Could you please show the text in 3261 which says that the SDP in an
>> > unreliable response is the SDP answer?
>>
>> [Gao]: text from 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.
>>
>> And, considering UAS send SDP in unreliable response before the answer,
>> then the SDP would be the *the first session*
>> * description it receives*.
>>
>> RFC3261 using the word "AS THE ANSWER", not as if.
>
> At this point, we are arguing about the *intent* of the text - it is
> clearly confusing to some people.
>
> And AFAIK we (me, Gao, Shinji, and Christer) are all in agreement that
> the intent of the existing text is that:
>
> - *if* the UAC receives SDP in an unreliable response before
> receiving it in a reliable response, it MUST begin to use it
> in the same way that it would use it if that SDP had been
> received in a reliable response,
>
> - but that it is not officially "the answer", and so it is not
> yet permissible to initiate another o/a exchange until a reliable
> response containing "the answer" is received.
>
> - but when "the answer" is received, it MUST be ignored
> (rather than "used") if an earlier SDP has already been
> received and so "treated as the answer".
>
> Are *we* all in agreement that this is the one and only *intended*
> meaning of the text?
>
> Then the issue is that *someone else* (who Gao has had occasion to do
> interop testing with) is claiming that there is a different, yet
> legitimate, interpretation of the exiting text. Namely:
>
> - *if* the UAC receives SDP in an unreliable response before
> receiving it in a reliable response, it MUST begin to use it
> in the same way that it would use it if it had been received
> in a reliable response,
>
> - the UAC MUST (or SHOULD?) consider this SDP to be "the answer",
> and hence it MAY send another offer, even before receiving
> another copy of that answer SDP in a *reliable* response.
>
> - still it MUST ignore SDP in subsequent responses to the
> INVITE.
>
> If so, then the question comes down to:
>
> Is this alternate interpretation a valid and legitimate interpretation
> of the existing text, or not?
>
> I agree that this is a fair question to ask, and I am not yet settled on
> an answer to it.

Sure, it's fair to ask but IMHO it's wrong. The second clause in your
first list above (saying SDP in an unreliable response is not the
"official" answer) is not just an opinion. 3261 says:

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.

Seems pretty clear: SDP in the unreliable response is to be *treated as*
the answer although (based on the first sentence) it isn't actually the
answer. Elsewhere it is said that the SDP can't change from unreliable
to reliable response so you could say that the unreliable SDP *might as
well* have been the answer. In my view that doesn't change the fact that
the official answer is the one in the first reliable response.

So I agree with "we" and I see no need for any fixes.

Thanks,
Anders

>
> I am approaching this in the manner of a mathematical proof by
> contradiction: If this alternative interpretation leads to some sort of
> inconsistency, then it is not valid. If we can find no inconsistencies,
> then it is a valid interpretation. And if it is, then the text is
> ambiguous and will require normative changes to fix.
>
> So, we can either seek out such an inconsistency, OR we can simply
> concede that the text is ambiguous and begin work on a normative
> correction to address it.
>
> I'm pretty sure that we are going to reach the same endpoint either way.
> So its a matter of whether we need a normative document to convince
> everyone or not.
>
> I'd appreciate feedback on my logic above.
>
> Thank you,
> Paul
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Brett Tate]

> At this point, we are arguing about the *intent* of the text - it is
> clearly confusing to some people.
>
> And AFAIK we (me, Gao, Shinji, and Christer) are all in agreement that
> the intent of the existing text is that:
>
> - *if* the UAC receives SDP in an unreliable response before
> receiving it in a reliable response, it MUST begin to use it
> in the same way that it would use it if that SDP had been
> received in a reliable response,
>
> - but that it is not officially "the answer", and so it is not
> yet permissible to initiate another o/a exchange until a reliable
> response containing "the answer" is received.
>
> - but when "the answer" is received, it MUST be ignored
> (rather than "used") if an earlier SDP has already been
> received and so "treated as the answer".
>
> Are *we* all in agreement that this is the one and only *intended*
> meaning of the text?

Yes.

_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[OKUMURA Shinji]

Hi Paul,

Paul Kyzivat <***@cisco.com>
Fri, 16 Apr 2010 18:14:28 -0400
>I think we are now down to the essence of the question:
>
>***@zte.com.cn wrote:
>
>> > Could you please show the text in 3261 which says that the SDP in an
>> > unreliable response is the SDP answer?
>>
>> [Gao]: text from 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.
>>
>> And, considering UAS send SDP in unreliable response before the answer,
>> then the SDP would be the *the first session*
>> * description it receives*.
>>
>> RFC3261 using the word "AS THE ANSWER", not as if.
>
>At this point, we are arguing about the *intent* of the text - it is
>clearly confusing to some people.
>
>And AFAIK we (me, Gao, Shinji, and Christer) are all in agreement that
>the intent of the existing text is that:
>
>- *if* the UAC receives SDP in an unreliable response before
> receiving it in a reliable response, it MUST begin to use it
> in the same way that it would use it if that SDP had been
> received in a reliable response,
>
>- but that it is not officially "the answer", and so it is not
> yet permissible to initiate another o/a exchange until a reliable
> response containing "the answer" is received.
>
>- but when "the answer" is received, it MUST be ignored
> (rather than "used") if an earlier SDP has already been
> received and so "treated as the answer".
>
>Are *we* all in agreement that this is the one and only *intended*
>meaning of the text?

I agree.
And then

- UAS MAY include the same SDP as the answer into
any provisional responses before sending the answer.

- UAS MUST NOT include the different SDP from the answer into
any provisional responses before sending the answer.

- UAS MUST NOT include the any SDP into any provisional
responses after sending the answer.

we agree all of the above, don't we?

>Then the issue is that *someone else* (who Gao has had occasion to do
>interop testing with) is claiming that there is a different, yet
>legitimate, interpretation of the exiting text. Namely:
>
>- *if* the UAC receives SDP in an unreliable response before
> receiving it in a reliable response, it MUST begin to use it
> in the same way that it would use it if it had been received
> in a reliable response,
>
>- the UAC MUST (or SHOULD?) consider this SDP to be "the answer",
> and hence it MAY send another offer, even before receiving
> another copy of that answer SDP in a *reliable* response.
>
>- still it MUST ignore SDP in subsequent responses to the
> INVITE.
>
>If so, then the question comes down to:
>
>Is this alternate interpretation a valid and legitimate interpretation
>of the existing text, or not?
>
>I agree that this is a fair question to ask, and I am not yet settled on
>an answer to it.
>
>I am approaching this in the manner of a mathematical proof by
>contradiction: If this alternative interpretation leads to some sort of
>inconsistency, then it is not valid. If we can find no inconsistencies,
>then it is a valid interpretation. And if it is, then the text is
>ambiguous and will require normative changes to fix.

Even though I do not have the conviction to fill the
precondition of the proof by contradiction...

At that time if UAC sends an UPDATE with new offer, UAS probably
rejects it with 500 response.

Is it a contradiction?

Regards,
Shinji

>So, we can either seek out such an inconsistency, OR we can simply
>concede that the text is ambiguous and begin work on a normative
>correction to address it.
>
>I'm pretty sure that we are going to reach the same endpoint either way.
>So its a matter of whether we need a normative document to convince
>everyone or not.
>
>I'd appreciate feedback on my logic above.
>
> Thank you,
> Paul
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Christer Holmberg]

Hi,

Do we really need 3 bullets to say that all SDPs included in the responses have to be the same???

Wording like "different SDP from the answer into before sending the answer" is also very confusing.

Why not simply say something like:

- A UAS MAY insert a SDP body that is identfical to the SDP answer, in a response before and after the SDP answer has been sent. The UAS MUST NOT insert a SDP body that is not identical to the SDP answer.

Regards,

Christer

> -----Original Message-----
> From: sipping-***@ietf.org
> [mailto:sipping-***@ietf.org] On Behalf Of OKUMURA Shinji
> Sent: 19. huhtikuuta 2010 12:07
> To: ***@ietf.org
> Cc: ***@cisco.com
> Subject: Re: [Sipping] Is SDP in an unreliable response "the
> answer" ???
>
> Hi Paul,
>
> Paul Kyzivat <***@cisco.com>
> Fri, 16 Apr 2010 18:14:28 -0400
> >I think we are now down to the essence of the question:
> >
> >***@zte.com.cn wrote:
> >
> >> > Could you please show the text in 3261 which says that
> the SDP in
> >> an > unreliable response is the SDP answer?
> >>
> >> [Gao]: text from 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.
> >>
> >> And, considering UAS send SDP in unreliable response before the
> >> answer, then the SDP would be the *the first session*
> >> * description it receives*.
> >>
> >> RFC3261 using the word "AS THE ANSWER", not as if.
> >
> >At this point, we are arguing about the *intent* of the text - it is
> >clearly confusing to some people.
> >
> >And AFAIK we (me, Gao, Shinji, and Christer) are all in
> agreement that
> >the intent of the existing text is that:
> >
> >- *if* the UAC receives SDP in an unreliable response before
> > receiving it in a reliable response, it MUST begin to use it
> > in the same way that it would use it if that SDP had been
> > received in a reliable response,
> >
> >- but that it is not officially "the answer", and so it is not
> > yet permissible to initiate another o/a exchange until a reliable
> > response containing "the answer" is received.
> >
> >- but when "the answer" is received, it MUST be ignored
> > (rather than "used") if an earlier SDP has already been
> > received and so "treated as the answer".
> >
> >Are *we* all in agreement that this is the one and only *intended*
> >meaning of the text?
>
> I agree.
> And then
>
> - UAS MAY include the same SDP as the answer into
> any provisional responses before sending the answer.
>
> - UAS MUST NOT include the different SDP from the answer into
> any provisional responses before sending the answer.
>
> - UAS MUST NOT include the any SDP into any provisional
> responses after sending the answer.
>
> we agree all of the above, don't we?
>
> >Then the issue is that *someone else* (who Gao has had
> occasion to do
> >interop testing with) is claiming that there is a different, yet
> >legitimate, interpretation of the exiting text. Namely:
> >
> >- *if* the UAC receives SDP in an unreliable response before
> > receiving it in a reliable response, it MUST begin to use it
> > in the same way that it would use it if it had been received
> > in a reliable response,
> >
> >- the UAC MUST (or SHOULD?) consider this SDP to be "the answer",
> > and hence it MAY send another offer, even before receiving
> > another copy of that answer SDP in a *reliable* response.
> >
> >- still it MUST ignore SDP in subsequent responses to the
> > INVITE.
> >
> >If so, then the question comes down to:
> >
> >Is this alternate interpretation a valid and legitimate
> interpretation
> >of the existing text, or not?
> >
> >I agree that this is a fair question to ask, and I am not
> yet settled
> >on an answer to it.
> >
> >I am approaching this in the manner of a mathematical proof by
> >contradiction: If this alternative interpretation leads to
> some sort of
> >inconsistency, then it is not valid. If we can find no
> inconsistencies,
> >then it is a valid interpretation. And if it is, then the text is
> >ambiguous and will require normative changes to fix.
>
> Even though I do not have the conviction to fill the
> precondition of the proof by contradiction...
>
> At that time if UAC sends an UPDATE with new offer, UAS
> probably rejects it with 500 response.
>
> Is it a contradiction?
>
> Regards,
> Shinji
>
> >So, we can either seek out such an inconsistency, OR we can simply
> >concede that the text is ambiguous and begin work on a normative
> >correction to address it.
> >
> >I'm pretty sure that we are going to reach the same endpoint
> either way.
> >So its a matter of whether we need a normative document to convince
> >everyone or not.
> >
> >I'd appreciate feedback on my logic above.
> >
> > Thank you,
> > Paul
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-***@cs.columbia.edu for questions on current
> sip Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[OKUMURA Shinji]

Christer,

I wanted to describe the condition strictly.
But my wording was not strict and not simple. I'm sorry.

However IMO we need 3 statements.

- An UAS MAY insert a SDP body that is identical to the SDP
answer, in an unreliable provisional response before the SDP
answer has been sent.

- The UAS MUST NOT insert a SDP body that is not identical to
the SDP answer, in an unreliable provisional response before
the SDP answer has been sent.

- The UAS MUST NOT insert a SDP body in any response after the
SDP answer has been sent.

Regards,
Shinji

Christer Holmberg <***@ericsson.com>
Mon, 19 Apr 2010 11:20:52 +0200
>
>Hi,
>
>Do we really need 3 bullets to say that all SDPs included in the responses have to be the same???
>
>Wording like "different SDP from the answer into before sending the answer" is also very confusing.
>
>Why not simply say something like:
>
>- A UAS MAY insert a SDP body that is identfical to the SDP answer, in a response before and after the SDP answer has been
>sent. The UAS MUST NOT insert a SDP body that is not identical to the SDP answer.
>
>Regards,
>
>Christer
>
>> -----Original Message-----
>> From: sipping-***@ietf.org
>> [mailto:sipping-***@ietf.org] On Behalf Of OKUMURA Shinji
>> Sent: 19. huhtikuuta 2010 12:07
>> To: ***@ietf.org
>> Cc: ***@cisco.com
>> Subject: Re: [Sipping] Is SDP in an unreliable response "the
>> answer" ???
>>
>> Hi Paul,
>>
>> Paul Kyzivat <***@cisco.com>
>> Fri, 16 Apr 2010 18:14:28 -0400
>> >I think we are now down to the essence of the question:
>> >
>> >***@zte.com.cn wrote:
>> >
>> >> > Could you please show the text in 3261 which says that
>> the SDP in
>> >> an > unreliable response is the SDP answer?
>> >>
>> >> [Gao]: text from 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.
>> >>
>> >> And, considering UAS send SDP in unreliable response before the
>> >> answer, then the SDP would be the *the first session*
>> >> * description it receives*.
>> >>
>> >> RFC3261 using the word "AS THE ANSWER", not as if.
>> >
>> >At this point, we are arguing about the *intent* of the text - it is
>> >clearly confusing to some people.
>> >
>> >And AFAIK we (me, Gao, Shinji, and Christer) are all in
>> agreement that
>> >the intent of the existing text is that:
>> >
>> >- *if* the UAC receives SDP in an unreliable response before
>> > receiving it in a reliable response, it MUST begin to use it
>> > in the same way that it would use it if that SDP had been
>> > received in a reliable response,
>> >
>> >- but that it is not officially "the answer", and so it is not
>> > yet permissible to initiate another o/a exchange until a reliable
>> > response containing "the answer" is received.
>> >
>> >- but when "the answer" is received, it MUST be ignored
>> > (rather than "used") if an earlier SDP has already been
>> > received and so "treated as the answer".
>> >
>> >Are *we* all in agreement that this is the one and only *intended*
>> >meaning of the text?
>>
>> I agree.
>> And then
>>
>> - UAS MAY include the same SDP as the answer into
>> any provisional responses before sending the answer.
>>
>> - UAS MUST NOT include the different SDP from the answer into
>> any provisional responses before sending the answer.
>>
>> - UAS MUST NOT include the any SDP into any provisional
>> responses after sending the answer.
>>
>> we agree all of the above, don't we?
>>
>> >Then the issue is that *someone else* (who Gao has had
>> occasion to do
>> >interop testing with) is claiming that there is a different, yet
>> >legitimate, interpretation of the exiting text. Namely:
>> >
>> >- *if* the UAC receives SDP in an unreliable response before
>> > receiving it in a reliable response, it MUST begin to use it
>> > in the same way that it would use it if it had been received
>> > in a reliable response,
>> >
>> >- the UAC MUST (or SHOULD?) consider this SDP to be "the answer",
>> > and hence it MAY send another offer, even before receiving
>> > another copy of that answer SDP in a *reliable* response.
>> >
>> >- still it MUST ignore SDP in subsequent responses to the
>> > INVITE.
>> >
>> >If so, then the question comes down to:
>> >
>> >Is this alternate interpretation a valid and legitimate
>> interpretation
>> >of the existing text, or not?
>> >
>> >I agree that this is a fair question to ask, and I am not
>> yet settled
>> >on an answer to it.
>> >
>> >I am approaching this in the manner of a mathematical proof by
>> >contradiction: If this alternative interpretation leads to
>> some sort of
>> >inconsistency, then it is not valid. If we can find no
>> inconsistencies,
>> >then it is a valid interpretation. And if it is, then the text is
>> >ambiguous and will require normative changes to fix.
>>
>> Even though I do not have the conviction to fill the
>> precondition of the proof by contradiction...
>>
>> At that time if UAC sends an UPDATE with new offer, UAS
>> probably rejects it with 500 response.
>>
>> Is it a contradiction?
>>
>> Regards,
>> Shinji
>>
>> >So, we can either seek out such an inconsistency, OR we can simply
>> >concede that the text is ambiguous and begin work on a normative
>> >correction to address it.
>> >
>> >I'm pretty sure that we are going to reach the same endpoint
>> either way.
>> >So its a matter of whether we need a normative document to convince
>> >everyone or not.
>> >
>> >I'd appreciate feedback on my logic above.
>> >
>> > Thank you,
>> > Paul
>> _______________________________________________
>> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use sip-***@cs.columbia.edu for questions on current
>> sip Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
>Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Christer Holmberg]

Hi,

>I wanted to describe the condition strictly.
>But my wording was not strict and not simple. I'm sorry.
>
>However IMO we need 3 statements.
>
>- An UAS MAY insert a SDP body that is identical to the SDP
> answer, in an unreliable provisional response before the SDP
> answer has been sent.
>
>- The UAS MUST NOT insert a SDP body that is not identical to
> the SDP answer, in an unreliable provisional response before
> the SDP answer has been sent.
>
> - The UAS MUST NOT insert a SDP body in any response after the
> SDP answer has been sent.

I don't think we can have the last bullet as MUST NOT, because there are implementations doing it, and I don't think there is any existing specification which forbids it.

Regards,

Christer


> Christer Holmberg <***@ericsson.com> Mon, 19
> Apr 2010 11:20:52 +0200
> >
> >Hi,
> >
> >Do we really need 3 bullets to say that all SDPs included in
> the responses have to be the same???
> >
> >Wording like "different SDP from the answer into before
> sending the answer" is also very confusing.
> >
> >Why not simply say something like:
> >
> >- A UAS MAY insert a SDP body that is identfical to the SDP
> answer, in
> >a response before and after the SDP answer has been sent.
> The UAS MUST NOT insert a SDP body that is not identical to
> the SDP answer.
> >
> >Regards,
> >
> >Christer
> >
> >> -----Original Message-----
> >> From: sipping-***@ietf.org
> >> [mailto:sipping-***@ietf.org] On Behalf Of OKUMURA Shinji
> >> Sent: 19. huhtikuuta 2010 12:07
> >> To: ***@ietf.org
> >> Cc: ***@cisco.com
> >> Subject: Re: [Sipping] Is SDP in an unreliable response
> "the answer"
> >> ???
> >>
> >> Hi Paul,
> >>
> >> Paul Kyzivat <***@cisco.com>
> >> Fri, 16 Apr 2010 18:14:28 -0400
> >> >I think we are now down to the essence of the question:
> >> >
> >> >***@zte.com.cn wrote:
> >> >
> >> >> > Could you please show the text in 3261 which says that
> >> the SDP in
> >> >> an > unreliable response is the SDP answer?
> >> >>
> >> >> [Gao]: text from 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.
> >> >>
> >> >> And, considering UAS send SDP in unreliable response before the
> >> >> answer, then the SDP would be the *the first session*
> >> >> * description it receives*.
> >> >>
> >> >> RFC3261 using the word "AS THE ANSWER", not as if.
> >> >
> >> >At this point, we are arguing about the *intent* of the
> text - it is
> >> >clearly confusing to some people.
> >> >
> >> >And AFAIK we (me, Gao, Shinji, and Christer) are all in
> >> agreement that
> >> >the intent of the existing text is that:
> >> >
> >> >- *if* the UAC receives SDP in an unreliable response before
> >> > receiving it in a reliable response, it MUST begin to use it
> >> > in the same way that it would use it if that SDP had been
> >> > received in a reliable response,
> >> >
> >> >- but that it is not officially "the answer", and so it is not
> >> > yet permissible to initiate another o/a exchange until
> a reliable
> >> > response containing "the answer" is received.
> >> >
> >> >- but when "the answer" is received, it MUST be ignored
> >> > (rather than "used") if an earlier SDP has already been
> >> > received and so "treated as the answer".
> >> >
> >> >Are *we* all in agreement that this is the one and only
> *intended*
> >> >meaning of the text?
> >>
> >> I agree.
> >> And then
> >>
> >> - UAS MAY include the same SDP as the answer into
> >> any provisional responses before sending the answer.
> >>
> >> - UAS MUST NOT include the different SDP from the answer into
> >> any provisional responses before sending the answer.
> >>
> >> - UAS MUST NOT include the any SDP into any provisional
> >> responses after sending the answer.
> >>
> >> we agree all of the above, don't we?
> >>
> >> >Then the issue is that *someone else* (who Gao has had
> >> occasion to do
> >> >interop testing with) is claiming that there is a different, yet
> >> >legitimate, interpretation of the exiting text. Namely:
> >> >
> >> >- *if* the UAC receives SDP in an unreliable response before
> >> > receiving it in a reliable response, it MUST begin to use it
> >> > in the same way that it would use it if it had been received
> >> > in a reliable response,
> >> >
> >> >- the UAC MUST (or SHOULD?) consider this SDP to be "the answer",
> >> > and hence it MAY send another offer, even before receiving
> >> > another copy of that answer SDP in a *reliable* response.
> >> >
> >> >- still it MUST ignore SDP in subsequent responses to the
> >> > INVITE.
> >> >
> >> >If so, then the question comes down to:
> >> >
> >> >Is this alternate interpretation a valid and legitimate
> >> interpretation
> >> >of the existing text, or not?
> >> >
> >> >I agree that this is a fair question to ask, and I am not
> >> yet settled
> >> >on an answer to it.
> >> >
> >> >I am approaching this in the manner of a mathematical proof by
> >> >contradiction: If this alternative interpretation leads to
> >> some sort of
> >> >inconsistency, then it is not valid. If we can find no
> >> inconsistencies,
> >> >then it is a valid interpretation. And if it is, then the text is
> >> >ambiguous and will require normative changes to fix.
> >>
> >> Even though I do not have the conviction to fill the
> precondition of
> >> the proof by contradiction...
> >>
> >> At that time if UAC sends an UPDATE with new offer, UAS probably
> >> rejects it with 500 response.
> >>
> >> Is it a contradiction?
> >>
> >> Regards,
> >> Shinji
> >>
> >> >So, we can either seek out such an inconsistency, OR we
> can simply
> >> >concede that the text is ambiguous and begin work on a normative
> >> >correction to address it.
> >> >
> >> >I'm pretty sure that we are going to reach the same endpoint
> >> either way.
> >> >So its a matter of whether we need a normative document
> to convince
> >> >everyone or not.
> >> >
> >> >I'd appreciate feedback on my logic above.
> >> >
> >> > Thank you,
> >> > Paul
> >> _______________________________________________
> >> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> >> This list is for NEW development of the application of SIP Use
> >> sip-***@cs.columbia.edu for questions on current sip Use
> >> ***@ietf.org 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-***@cs.columbia.edu for questions on current sip Use
> >***@ietf.org 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-***@cs.columbia.edu for questions on current
> sip Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[OKUMURA Shinji]

Christer,

I don't intend to be strongly particular about the last "MUST NOT".

But RFC3261 say,
o Once the UAS has sent or received an answer to the initial
offer, it MUST NOT generate subsequent offers in any responses
to the initial INVITE. This means that a UAS based on this
specification alone can never generate subsequent offers until
completion of the initial transaction.

What do the above statements forbid?

Regards,
Shinji

Christer Holmberg <***@ericsson.com>
Mon, 19 Apr 2010 13:32:12 +0200
>
>Hi,
>
>>I wanted to describe the condition strictly.
>>But my wording was not strict and not simple. I'm sorry.
>>
>>However IMO we need 3 statements.
>>
>>- An UAS MAY insert a SDP body that is identical to the SDP
>> answer, in an unreliable provisional response before the SDP
>> answer has been sent.
>>
>>- The UAS MUST NOT insert a SDP body that is not identical to
>> the SDP answer, in an unreliable provisional response before
>> the SDP answer has been sent.
>>
>> - The UAS MUST NOT insert a SDP body in any response after the
>> SDP answer has been sent.
>
>I don't think we can have the last bullet as MUST NOT, because there are implementations doing it, and I don't think there is
>any existing specification which forbids it.
>
>Regards,
>
>Christer
>
>
>> Christer Holmberg <***@ericsson.com> Mon, 19
>> Apr 2010 11:20:52 +0200
>> >
>> >Hi,
>> >
>> >Do we really need 3 bullets to say that all SDPs included in
>> the responses have to be the same???
>> >
>> >Wording like "different SDP from the answer into before
>> sending the answer" is also very confusing.
>> >
>> >Why not simply say something like:
>> >
>> >- A UAS MAY insert a SDP body that is identfical to the SDP
>> answer, in
>> >a response before and after the SDP answer has been sent.
>> The UAS MUST NOT insert a SDP body that is not identical to
>> the SDP answer.
>> >
>> >Regards,
>> >
>> >Christer
>> >
>> >> -----Original Message-----
>> >> From: sipping-***@ietf.org
>> >> [mailto:sipping-***@ietf.org] On Behalf Of OKUMURA Shinji
>> >> Sent: 19. huhtikuuta 2010 12:07
>> >> To: ***@ietf.org
>> >> Cc: ***@cisco.com
>> >> Subject: Re: [Sipping] Is SDP in an unreliable response
>> "the answer"
>> >> ???
>> >>
>> >> Hi Paul,
>> >>
>> >> Paul Kyzivat <***@cisco.com>
>> >> Fri, 16 Apr 2010 18:14:28 -0400
>> >> >I think we are now down to the essence of the question:
>> >> >
>> >> >***@zte.com.cn wrote:
>> >> >
>> >> >> > Could you please show the text in 3261 which says that
>> >> the SDP in
>> >> >> an > unreliable response is the SDP answer?
>> >> >>
>> >> >> [Gao]: text from 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.
>> >> >>
>> >> >> And, considering UAS send SDP in unreliable response before the
>> >> >> answer, then the SDP would be the *the first session*
>> >> >> * description it receives*.
>> >> >>
>> >> >> RFC3261 using the word "AS THE ANSWER", not as if.
>> >> >
>> >> >At this point, we are arguing about the *intent* of the
>> text - it is
>> >> >clearly confusing to some people.
>> >> >
>> >> >And AFAIK we (me, Gao, Shinji, and Christer) are all in
>> >> agreement that
>> >> >the intent of the existing text is that:
>> >> >
>> >> >- *if* the UAC receives SDP in an unreliable response before
>> >> > receiving it in a reliable response, it MUST begin to use it
>> >> > in the same way that it would use it if that SDP had been
>> >> > received in a reliable response,
>> >> >
>> >> >- but that it is not officially "the answer", and so it is not
>> >> > yet permissible to initiate another o/a exchange until
>> a reliable
>> >> > response containing "the answer" is received.
>> >> >
>> >> >- but when "the answer" is received, it MUST be ignored
>> >> > (rather than "used") if an earlier SDP has already been
>> >> > received and so "treated as the answer".
>> >> >
>> >> >Are *we* all in agreement that this is the one and only
>> *intended*
>> >> >meaning of the text?
>> >>
>> >> I agree.
>> >> And then
>> >>
>> >> - UAS MAY include the same SDP as the answer into
>> >> any provisional responses before sending the answer.
>> >>
>> >> - UAS MUST NOT include the different SDP from the answer into
>> >> any provisional responses before sending the answer.
>> >>
>> >> - UAS MUST NOT include the any SDP into any provisional
>> >> responses after sending the answer.
>> >>
>> >> we agree all of the above, don't we?
>> >>
>> >> >Then the issue is that *someone else* (who Gao has had
>> >> occasion to do
>> >> >interop testing with) is claiming that there is a different, yet
>> >> >legitimate, interpretation of the exiting text. Namely:
>> >> >
>> >> >- *if* the UAC receives SDP in an unreliable response before
>> >> > receiving it in a reliable response, it MUST begin to use it
>> >> > in the same way that it would use it if it had been received
>> >> > in a reliable response,
>> >> >
>> >> >- the UAC MUST (or SHOULD?) consider this SDP to be "the answer",
>> >> > and hence it MAY send another offer, even before receiving
>> >> > another copy of that answer SDP in a *reliable* response.
>> >> >
>> >> >- still it MUST ignore SDP in subsequent responses to the
>> >> > INVITE.
>> >> >
>> >> >If so, then the question comes down to:
>> >> >
>> >> >Is this alternate interpretation a valid and legitimate
>> >> interpretation
>> >> >of the existing text, or not?
>> >> >
>> >> >I agree that this is a fair question to ask, and I am not
>> >> yet settled
>> >> >on an answer to it.
>> >> >
>> >> >I am approaching this in the manner of a mathematical proof by
>> >> >contradiction: If this alternative interpretation leads to
>> >> some sort of
>> >> >inconsistency, then it is not valid. If we can find no
>> >> inconsistencies,
>> >> >then it is a valid interpretation. And if it is, then the text is
>> >> >ambiguous and will require normative changes to fix.
>> >>
>> >> Even though I do not have the conviction to fill the
>> precondition of
>> >> the proof by contradiction...
>> >>
>> >> At that time if UAC sends an UPDATE with new offer, UAS probably
>> >> rejects it with 500 response.
>> >>
>> >> Is it a contradiction?
>> >>
>> >> Regards,
>> >> Shinji
>> >>
>> >> >So, we can either seek out such an inconsistency, OR we
>> can simply
>> >> >concede that the text is ambiguous and begin work on a normative
>> >> >correction to address it.
>> >> >
>> >> >I'm pretty sure that we are going to reach the same endpoint
>> >> either way.
>> >> >So its a matter of whether we need a normative document
>> to convince
>> >> >everyone or not.
>> >> >
>> >> >I'd appreciate feedback on my logic above.
>> >> >
>> >> > Thank you,
>> >> > Paul
>> >> _______________________________________________
>> >> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
>> >> This list is for NEW development of the application of SIP Use
>> >> sip-***@cs.columbia.edu for questions on current sip Use
>> >> ***@ietf.org 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-***@cs.columbia.edu for questions on current sip Use
>> >***@ietf.org 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-***@cs.columbia.edu for questions on current
>> sip Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
>Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Christer Holmberg]

Hi,

The text talks about generating additional offers, but not about including a copy of previously sent ones.

Regards,

Christer

> -----Original Message-----
> From: sipping-***@ietf.org
> [mailto:sipping-***@ietf.org] On Behalf Of OKUMURA Shinji
> Sent: 19. huhtikuuta 2010 14:50
> To: ***@ietf.org
> Subject: Re: [Sipping] Is SDP in an unreliable response "the
> answer" ???
>
> Christer,
>
> I don't intend to be strongly particular about the last "MUST NOT".
>
> But RFC3261 say,
> o Once the UAS has sent or received an answer to the initial
> offer, it MUST NOT generate subsequent offers in any
> responses
> to the initial INVITE. This means that a UAS based on this
> specification alone can never generate subsequent
> offers until
> completion of the initial transaction.
>
> What do the above statements forbid?
>
> Regards,
> Shinji
>
> Christer Holmberg <***@ericsson.com> Mon, 19
> Apr 2010 13:32:12 +0200
> >
> >Hi,
> >
> >>I wanted to describe the condition strictly.
> >>But my wording was not strict and not simple. I'm sorry.
> >>
> >>However IMO we need 3 statements.
> >>
> >>- An UAS MAY insert a SDP body that is identical to the SDP
> >> answer, in an unreliable provisional response before the SDP
> >> answer has been sent.
> >>
> >>- The UAS MUST NOT insert a SDP body that is not identical to
> >> the SDP answer, in an unreliable provisional response before
> >> the SDP answer has been sent.
> >>
> >> - The UAS MUST NOT insert a SDP body in any response after the
> >> SDP answer has been sent.
> >
> >I don't think we can have the last bullet as MUST NOT, because there
> >are implementations doing it, and I don't think there is any
> existing specification which forbids it.
> >
> >Regards,
> >
> >Christer
> >
> >
> >> Christer Holmberg <***@ericsson.com> Mon, 19
> Apr 2010
> >> 11:20:52 +0200
> >> >
> >> >Hi,
> >> >
> >> >Do we really need 3 bullets to say that all SDPs included in
> >> the responses have to be the same???
> >> >
> >> >Wording like "different SDP from the answer into before
> >> sending the answer" is also very confusing.
> >> >
> >> >Why not simply say something like:
> >> >
> >> >- A UAS MAY insert a SDP body that is identfical to the SDP
> >> answer, in
> >> >a response before and after the SDP answer has been sent.
> >> The UAS MUST NOT insert a SDP body that is not identical
> to the SDP
> >> answer.
> >> >
> >> >Regards,
> >> >
> >> >Christer
> >> >
> >> >> -----Original Message-----
> >> >> From: sipping-***@ietf.org
> >> >> [mailto:sipping-***@ietf.org] On Behalf Of OKUMURA Shinji
> >> >> Sent: 19. huhtikuuta 2010 12:07
> >> >> To: ***@ietf.org
> >> >> Cc: ***@cisco.com
> >> >> Subject: Re: [Sipping] Is SDP in an unreliable response
> >> "the answer"
> >> >> ???
> >> >>
> >> >> Hi Paul,
> >> >>
> >> >> Paul Kyzivat <***@cisco.com>
> >> >> Fri, 16 Apr 2010 18:14:28 -0400
> >> >> >I think we are now down to the essence of the question:
> >> >> >
> >> >> >***@zte.com.cn wrote:
> >> >> >
> >> >> >> > Could you please show the text in 3261 which says that
> >> >> the SDP in
> >> >> >> an > unreliable response is the SDP answer?
> >> >> >>
> >> >> >> [Gao]: text from 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.
> >> >> >>
> >> >> >> And, considering UAS send SDP in unreliable response
> before the
> >> >> >> answer, then the SDP would be the *the first session*
> >> >> >> * description it receives*.
> >> >> >>
> >> >> >> RFC3261 using the word "AS THE ANSWER", not as if.
> >> >> >
> >> >> >At this point, we are arguing about the *intent* of the
> >> text - it is
> >> >> >clearly confusing to some people.
> >> >> >
> >> >> >And AFAIK we (me, Gao, Shinji, and Christer) are all in
> >> >> agreement that
> >> >> >the intent of the existing text is that:
> >> >> >
> >> >> >- *if* the UAC receives SDP in an unreliable response before
> >> >> > receiving it in a reliable response, it MUST begin to use it
> >> >> > in the same way that it would use it if that SDP had been
> >> >> > received in a reliable response,
> >> >> >
> >> >> >- but that it is not officially "the answer", and so it is not
> >> >> > yet permissible to initiate another o/a exchange until
> >> a reliable
> >> >> > response containing "the answer" is received.
> >> >> >
> >> >> >- but when "the answer" is received, it MUST be ignored
> >> >> > (rather than "used") if an earlier SDP has already been
> >> >> > received and so "treated as the answer".
> >> >> >
> >> >> >Are *we* all in agreement that this is the one and only
> >> *intended*
> >> >> >meaning of the text?
> >> >>
> >> >> I agree.
> >> >> And then
> >> >>
> >> >> - UAS MAY include the same SDP as the answer into
> >> >> any provisional responses before sending the answer.
> >> >>
> >> >> - UAS MUST NOT include the different SDP from the answer into
> >> >> any provisional responses before sending the answer.
> >> >>
> >> >> - UAS MUST NOT include the any SDP into any provisional
> >> >> responses after sending the answer.
> >> >>
> >> >> we agree all of the above, don't we?
> >> >>
> >> >> >Then the issue is that *someone else* (who Gao has had
> >> >> occasion to do
> >> >> >interop testing with) is claiming that there is a
> different, yet
> >> >> >legitimate, interpretation of the exiting text. Namely:
> >> >> >
> >> >> >- *if* the UAC receives SDP in an unreliable response before
> >> >> > receiving it in a reliable response, it MUST begin to use it
> >> >> > in the same way that it would use it if it had been received
> >> >> > in a reliable response,
> >> >> >
> >> >> >- the UAC MUST (or SHOULD?) consider this SDP to be
> "the answer",
> >> >> > and hence it MAY send another offer, even before receiving
> >> >> > another copy of that answer SDP in a *reliable* response.
> >> >> >
> >> >> >- still it MUST ignore SDP in subsequent responses to the
> >> >> > INVITE.
> >> >> >
> >> >> >If so, then the question comes down to:
> >> >> >
> >> >> >Is this alternate interpretation a valid and legitimate
> >> >> interpretation
> >> >> >of the existing text, or not?
> >> >> >
> >> >> >I agree that this is a fair question to ask, and I am not
> >> >> yet settled
> >> >> >on an answer to it.
> >> >> >
> >> >> >I am approaching this in the manner of a mathematical proof by
> >> >> >contradiction: If this alternative interpretation leads to
> >> >> some sort of
> >> >> >inconsistency, then it is not valid. If we can find no
> >> >> inconsistencies,
> >> >> >then it is a valid interpretation. And if it is, then
> the text is
> >> >> >ambiguous and will require normative changes to fix.
> >> >>
> >> >> Even though I do not have the conviction to fill the
> >> precondition of
> >> >> the proof by contradiction...
> >> >>
> >> >> At that time if UAC sends an UPDATE with new offer, UAS
> probably
> >> >> rejects it with 500 response.
> >> >>
> >> >> Is it a contradiction?
> >> >>
> >> >> Regards,
> >> >> Shinji
> >> >>
> >> >> >So, we can either seek out such an inconsistency, OR we
> >> can simply
> >> >> >concede that the text is ambiguous and begin work on a
> normative
> >> >> >correction to address it.
> >> >> >
> >> >> >I'm pretty sure that we are going to reach the same endpoint
> >> >> either way.
> >> >> >So its a matter of whether we need a normative document
> >> to convince
> >> >> >everyone or not.
> >> >> >
> >> >> >I'd appreciate feedback on my logic above.
> >> >> >
> >> >> > Thank you,
> >> >> > Paul
> >> >> _______________________________________________
> >> >> Sipping mailing list
> >> >> https://www.ietf.org/mailman/listinfo/sipping
> >> >> This list is for NEW development of the application of SIP Use
> >> >> sip-***@cs.columbia.edu for questions on
> current sip Use
> >> >> ***@ietf.org 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-***@cs.columbia.edu for questions on current sip Use
> >> >***@ietf.org 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-***@cs.columbia.edu for questions on current sip Use
> >> ***@ietf.org 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-***@cs.columbia.edu for questions on current sip Use
> >***@ietf.org 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-***@cs.columbia.edu for questions on current
> sip Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Brett Tate]

> I don't intend to be strongly particular about the last "MUST NOT".
>
> But RFC3261 say,
> o Once the UAS has sent or received an answer to the initial
> offer, it MUST NOT generate subsequent offers in any responses
> to the initial INVITE. This means that a UAS based on this
> specification alone can never generate subsequent offers until
> completion of the initial transaction.
>
> What do the above statements forbid?

Very little since from UAC perspective, the SDP MUST be ignored. Thus if UAS places a modified SDP within a subsequent response, it isn't an offer SDP or an updated answer SDP.

_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[OKUMURA Shinji]

Hi Christer, Brett,

This bullet might mean what you say.

Overall I can understand it. But reading the specs carefully,
I'm confused a little.

IMO The first statement in this bullet is not necessary, it is
the cause of trouble more than the explanation.

Lets get the discussion back to the 3rd bullet, I think it is
necessary, but "should not" is better than "MUST NOT".

Regards,
Shinji

Christer Holmberg <***@ericsson.com>
Mon, 19 Apr 2010 13:55:26 +0200
>The text talks about generating additional offers, but not
>about including a copy of previously sent ones.

Brett Tate <***@broadsoft.com>
Mon, 19 Apr 2010 07:54:08 -0700
>Very little since from UAC perspective, the SDP MUST be ignored.
>Thus if UAS places a modified SDP within a subsequent response,
>it isn't an offer SDP or an updated answer SDP.

>> I don't intend to be strongly particular about the last "MUST NOT".
>>
>> But RFC3261 say,
>> o Once the UAS has sent or received an answer to the initial
>> offer, it MUST NOT generate subsequent offers in any responses
>> to the initial INVITE. This means that a UAS based on this
>> specification alone can never generate subsequent offers until
>> completion of the initial transaction.
>>
>> What do the above statements forbid?
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Hans Erik van Elburg]

> - An UAS MAY insert a SDP body that is identical to the SDP
>  answer, in an unreliable provisional response before the SDP
>  answer has been sent.
>
> - The UAS MUST NOT insert a SDP body that is not identical to
>  the SDP answer, in an unreliable provisional response before
>  the SDP answer has been sent.
>
This is terribly confusing. Very probabe that noone will get it right.
Triple negation. And talking about sending and answer before the
answer has been sent. ???


> - The UAS MUST NOT insert a SDP body in any response after the
>  SDP answer has been sent.
>
This means that you can't send it again after you've send it in an
unreliable provisional response. Do you want tto say that?

/Hans Erik van Elburg
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Christer Holmberg]

Hi,

I'm afraid we're over-engineering this whole thing, and we'll end up with something which is even more complicated than what we are trying to clarify :)

Regards,

Christer

> -----Original Message-----
> From: sipping-***@ietf.org
> [mailto:sipping-***@ietf.org] On Behalf Of Hans Erik van Elburg
> Sent: 19. huhtikuuta 2010 14:56
> To: OKUMURA Shinji
> Cc: ***@ietf.org
> Subject: Re: [Sipping] Is SDP in an unreliable response "the
> answer" ???
>
> > - An UAS MAY insert a SDP body that is identical to the SDP
> >  answer, in an unreliable provisional response before the SDP
> >  answer has been sent.
> >
> > - The UAS MUST NOT insert a SDP body that is not identical to
> >  the SDP answer, in an unreliable provisional response before
> >  the SDP answer has been sent.
> >
> This is terribly confusing. Very probabe that noone will get it right.
> Triple negation. And talking about sending and answer before
> the answer has been sent. ???
>
>
> > - The UAS MUST NOT insert a SDP body in any response after the
> >  SDP answer has been sent.
> >
> This means that you can't send it again after you've send it
> in an unreliable provisional response. Do you want tto say that?
>
> /Hans Erik van Elburg
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-***@cs.columbia.edu for questions on current
> sip Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Paul Kyzivat]

Christer Holmberg wrote:
> Hi,
>
> I'm afraid we're over-engineering this whole thing, and we'll end up with something which is even more complicated than what we are trying to clarify :)

Christer,

There are multiple things to do here:

1) decide what is correct

2) explain what is correct in a way that is understandable
to implementors and testers.

3) explain *why* it is correct, based on the existing RFCs,
in sufficient precision to convince the doubters.

What is in this mail thread is a combination of the three.

The draft needs to address both (2) and (3). But if it is organized
carefully, the part addressing (3) which is probably the most confusing
part, can perhaps be segregated from (2) which is the part most readers
will be interested in.

Thanks,
Paul

_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Brett Tate]

> I'm afraid we're over-engineering this whole thing, and we'll
> end up with something which is even more complicated than what
> we are trying to clarify :)

I agree. I think that the complication is less about the RFC ambiguity and more about vendors attempting to find ways to interop when some devices don't support (or disabled support of) the following: 1) interactions with forking proxies, 2) rfc3262, or 3) rfc3311.

Devices which don't support the above 3 items usually need work-a-rounds which are not compliant to SIP's offer/answer rules. Thus fixing potential RFC ambiguity does little to fix the real problem beyond highlighting that most/all of the work-a-rounds are non compliant or not desirable.

_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Paul Kyzivat]

Brett Tate wrote:
>> I'm afraid we're over-engineering this whole thing, and we'll
>> end up with something which is even more complicated than what
>> we are trying to clarify :)
>
> I agree. I think that the complication is less about the RFC ambiguity and more about vendors attempting to find ways to interop when some devices don't support (or disabled support of) the following: 1) interactions with forking proxies, 2) rfc3262, or 3) rfc3311.

You may be right about this.

> Devices which don't support the above 3 items usually need work-a-rounds which are not compliant to SIP's offer/answer rules. Thus fixing potential RFC ambiguity does little to fix the real problem beyond highlighting that most/all of the work-a-rounds are non compliant or not desirable.

I'm not sure what point you are making here.

In cases where implementations are doing the wrong thing because they
don't understand what the right thing is, better specification of
expected behavior will reduce the cases where work arounds are required.
Of course it won't fix things immediately - only as implementations are
corrected. It will certainly help in *disputes* about the correct behavior.

The cases where the existing text calls for things to be ignored, rather
than checked, can actually facilitate interop where one end isn't quite
right. But only for certain types of incorrectness.

Thanks,
Paul
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Brett Tate]

> > I agree. I think that the complication is less about the RFC
> ambiguity and more about vendors attempting to find ways to interop
> when some devices don't support (or disabled support of) the following:
> 1) interactions with forking proxies, 2) rfc3262, or 3) rfc3311.
>
> You may be right about this.
>
> > Devices which don't support the above 3 items usually need work-a-
> rounds which are not compliant to SIP's offer/answer rules. Thus
> fixing potential RFC ambiguity does little to fix the real problem
> beyond highlighting that most/all of the work-a-rounds are non
> compliant or not desirable.
>
> I'm not sure what point you are making here.

I think that the real problem is that some devices don't support (or disable support of) the following: 1) interactions with forking proxies, 2) rfc3262, or 3) rfc3311. I was mainly just attempting to encourage vendors to support these 3 items so that all the non-complaint or not-desirable work-arounds can be deprecated more quickly. However I doubt that the need for such work-arounds will go away any time soon.

_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[OKUMURA Shinji]

Brett,

I think nobody has been discussing on the assumption that UA
does not support those 3 items. (At least me, Gao, Paul)

Such workarounds is out of scope in this draft as you no doubt
know.

Regards,
Shinji

Brett Tate <***@broadsoft.com>
Mon, 19 Apr 2010 12:32:29 -0700
>> > I agree. I think that the complication is less about the RFC
>> ambiguity and more about vendors attempting to find ways to interop
>> when some devices don't support (or disabled support of) the following:
>> 1) interactions with forking proxies, 2) rfc3262, or 3) rfc3311.
>>
>> You may be right about this.
>>
>> > Devices which don't support the above 3 items usually need work-a-
>> rounds which are not compliant to SIP's offer/answer rules. Thus
>> fixing potential RFC ambiguity does little to fix the real problem
>> beyond highlighting that most/all of the work-a-rounds are non
>> compliant or not desirable.
>>
>> I'm not sure what point you are making here.
>
>I think that the real problem is that some devices don't support
>(or disable support of) the following:
>1) interactions with forking proxies, 2) rfc3262, or 3) rfc3311.
>I was mainly just attempting to encourage vendors to support
>these 3 items so that all the non-complaint or not-desirable
>work-arounds can be deprecated more quickly. However I doubt
>that the need for such work-arounds will go away any time soon.
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Brett Tate]

> I think nobody has been discussing on the assumption that
> UA does not support those 3 items. (At least me, Gao, Paul)
>
> Such workarounds is out of scope in this draft as you no
> doubt know.

I agree. However some of the workarounds are why a UAS does silly things like sending a modified SDP within 18x/2xx which must be ignored. It allows a compliant UAC to ignore it while a non compliant UAC potentially treats it as an updated answer SDP (as a workaround for lack of support/use of 100rel, UPDATE, and/or forking) instead of sticking head in the sand until SIP's offer/answer rules allow for proper subsequent renegotiation.

_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[OKUMURA Shinji]

Hi,

Before sending an answer,
- An UAS MAY send unreliable provisional responses with a SDP.
- And the SDP MUST be identical to an answer SDP.

After sending an answer,
- The UAS should not insert a SDP in any response.

Is this OK?

Hans Erik van Elburg <***@gmail.com>
Mon, 19 Apr 2010 13:55:41 +0200
>> - An UAS MAY insert a SDP body that is identical to the SDP
>> answer, in an unreliable provisional response before the SDP
>> answer has been sent.
>>
>> - The UAS MUST NOT insert a SDP body that is not identical to
>> the SDP answer, in an unreliable provisional response before
>> the SDP answer has been sent.
>>
>This is terribly confusing. Very probabe that noone will get it right.
>Triple negation. And talking about sending and answer before the
>answer has been sent. ???
>
>
>> - The UAS MUST NOT insert a SDP body in any response after the
>> SDP answer has been sent.
>>
>This means that you can't send it again after you've send it in an
>unreliable provisional response. Do you want tto say that?
>
>/Hans Erik van Elburg
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Christer Holmberg]

Hi,

>Before sending an answer,
>- An UAS MAY send unreliable provisional responses with a SDP.
>- And the SDP MUST be identical to an answer SDP.
>
>After sending an answer,
>- The UAS should not insert a SDP in any response.
>
>Is this OK?

That text still doesn't say what an SDP inserted after sending the answer means, only that it should not be sent.

I still don't see why we need to make a separation about SDP sent before and after the answer, because in both cases the SDP must be identical to the answer.

And, again, I know there are many implementations that send a copy of the SDP after the SDP answer has been sent, so instead of saying that it should not be done I think it is much more important to say that, if it is done, it must be identical to the SDP answer. In other words, to make it clear that the UAS can not send a NEW offer (or updated answer) in a subsequent response after the SDP answer has been sent.

Regards,

Christer






Hans Erik van Elburg <***@gmail.com>
Mon, 19 Apr 2010 13:55:41 +0200
>> - An UAS MAY insert a SDP body that is identical to the SDP
>> answer, in an unreliable provisional response before the SDP
>> answer has been sent.
>>
>> - The UAS MUST NOT insert a SDP body that is not identical to
>> the SDP answer, in an unreliable provisional response before
>> the SDP answer has been sent.
>>
>This is terribly confusing. Very probabe that noone will get it right.
>Triple negation. And talking about sending and answer before the
>answer has been sent. ???
>
>
>> - The UAS MUST NOT insert a SDP body in any response after the
>> SDP answer has been sent.
>>
>This means that you can't send it again after you've send it in an
>unreliable provisional response. Do you want tto say that?
>
>/Hans Erik van Elburg
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[OKUMURA Shinji]

Christer,

Christer Holmberg <***@ericsson.com>
Tue, 20 Apr 2010 12:27:33 +0200
>Hi,
>
>>Before sending an answer,
>>- An UAS MAY send unreliable provisional responses with a SDP.
>>- And the SDP MUST be identical to an answer SDP.
>>
>>After sending an answer,
>>- The UAS should not insert a SDP in any response.
>>
>>Is this OK?
>
>That text still doesn't say what an SDP inserted after sending
>the answer means, only that it should not be sent.

The SDP means nothing. it is neither an offer nor an answer.

>I still don't see why we need to make a separation about SDP
>sent before and after the answer, because in both cases the
>SDP must be identical to the answer.

1. RFC3261 says that UAS MAY send it before the answer and
doesn't say nothing after the answer.
2. The SDP MUST be ignored by UAC. it is meaningless.
3. if another o/a exchange is occured (using UPDATE or PRACK),
it is not even a confirmation.

>And, again, I know there are many implementations that send
>a copy of the SDP after the SDP answer has been sent, so
>instead of saying that it should not be done I think it is
>much more important to say that, if it is done, it must be
>identical to the SDP answer. In other words, to make it clear
>that the UAS can not send a NEW offer (or updated answer)
>in a subsequent response after the SDP answer has been sent.

Since UAC MUST ignored it, there is no problem on a interworking.
Why must it be identical to the SDP answer?

Regards,
Shinji

>Regards,
>
>Christer
>
>Hans Erik van Elburg <***@gmail.com>
>Mon, 19 Apr 2010 13:55:41 +0200
>>> - An UAS MAY insert a SDP body that is identical to the SDP
>>> answer, in an unreliable provisional response before the SDP
>>> answer has been sent.
>>>
>>> - The UAS MUST NOT insert a SDP body that is not identical to
>>> the SDP answer, in an unreliable provisional response before
>>> the SDP answer has been sent.
>>>
>>This is terribly confusing. Very probabe that noone will get it right.
>>Triple negation. And talking about sending and answer before the
>>answer has been sent. ???
>>
>>
>>> - The UAS MUST NOT insert a SDP body in any response after the
>>> SDP answer has been sent.
>>>
>>This means that you can't send it again after you've send it in an
>>unreliable provisional response. Do you want tto say that?
>>
>>/Hans Erik van Elburg
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Christer Holmberg]

Hi,

>>>Before sending an answer,
>>>- An UAS MAY send unreliable provisional responses with a SDP.
>>>- And the SDP MUST be identical to an answer SDP.
>>>
>>>After sending an answer,
>>>- The UAS should not insert a SDP in any response.
>>>
>>>Is this OK?
>>
>>That text still doesn't say what an SDP inserted after sending the
>>answer means, only that it should not be sent.
>
>The SDP means nothing. it is neither an offer nor an answer.

Exactly. In my opinion that is what is important - not whether the UAS inserts SDP or not.

>>I still don't see why we need to make a separation about SDP sent
>>before and after the answer, because in both cases the SDP must be
>>identical to the answer.
>
> 1. RFC3261 says that UAS MAY send it before the answer and
> doesn't say nothing after the answer.

That is one reason why we are writing the draft - to clarify things which may not be clear in the specs.

>2. The SDP MUST be ignored by UAC. it is meaningless.

I agree, and that is what we must be clear about. Because, as we know, some people want to send a NEW offer (or updated answer) in a subsequent response, and that is not allowed.


>3. if another o/a exchange is occured (using UPDATE or PRACK), it is not even a confirmation.
>
>And, again, I know there are many implementations that send
>a copy of the SDP after the SDP answer has been sent, so instead of
>saying that it should not be done I think it is much more important to
>say that, if it is done, it must be identical to the SDP answer. In other
>words, to make it clear that the UAS can not send a NEW offer (or
>updated answer) in a subsequent response after the SDP answer has been sent.
>
>Since UAC MUST ignored it, there is no problem on a interworking.
>Why must it be identical to the SDP answer?

Well, if you look at it that way, fine. But, then the important thing is that the UAC must ignore it - not that the UAS should not send it.

Regards,

Christer




> >Regards,
> >
> >Christer
> >
> >Hans Erik van Elburg <***@gmail.com> Mon, 19 Apr 2010
> >13:55:41 +0200
> >>> - An UAS MAY insert a SDP body that is identical to the
> SDP answer,
> >>> in an unreliable provisional response before the SDP answer has
> >>> been sent.
> >>>
> >>> - The UAS MUST NOT insert a SDP body that is not
> identical to the
> >>> SDP answer, in an unreliable provisional response before the SDP
> >>> answer has been sent.
> >>>
> >>This is terribly confusing. Very probabe that noone will
> get it right.
> >>Triple negation. And talking about sending and answer before the
> >>answer has been sent. ???
> >>
> >>
> >>> - The UAS MUST NOT insert a SDP body in any response
> after the SDP
> >>> answer has been sent.
> >>>
> >>This means that you can't send it again after you've send it in an
> >>unreliable provisional response. Do you want tto say that?
> >>
> >>/Hans Erik van Elburg
>
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[DRAGE, Keith (Keith)]

Do remember that there are certain cases where the UAC will not ignore it. These are the cases where the message containing original answer has not yet arrived or been lost, and the protocol has not yet recovered from that.

regards

Keith

> -----Original Message-----
> From: sipping-***@ietf.org
> [mailto:sipping-***@ietf.org] On Behalf Of Christer Holmberg
> Sent: Tuesday, April 20, 2010 1:47 PM
> To: OKUMURA Shinji; ***@ietf.org
> Subject: Re: [Sipping] Is SDP in an unreliable response "the
> answer" ???
>
>
> Hi,
>
> >>>Before sending an answer,
> >>>- An UAS MAY send unreliable provisional responses with a SDP.
> >>>- And the SDP MUST be identical to an answer SDP.
> >>>
> >>>After sending an answer,
> >>>- The UAS should not insert a SDP in any response.
> >>>
> >>>Is this OK?
> >>
> >>That text still doesn't say what an SDP inserted after sending the
> >>answer means, only that it should not be sent.
> >
> >The SDP means nothing. it is neither an offer nor an answer.
>
> Exactly. In my opinion that is what is important - not
> whether the UAS inserts SDP or not.
>
> >>I still don't see why we need to make a separation about SDP sent
> >>before and after the answer, because in both cases the SDP must be
> >>identical to the answer.
> >
> > 1. RFC3261 says that UAS MAY send it before the answer and
> > doesn't say nothing after the answer.
>
> That is one reason why we are writing the draft - to clarify
> things which may not be clear in the specs.
>
> >2. The SDP MUST be ignored by UAC. it is meaningless.
>
> I agree, and that is what we must be clear about. Because, as
> we know, some people want to send a NEW offer (or updated
> answer) in a subsequent response, and that is not allowed.
>
>
> >3. if another o/a exchange is occured (using UPDATE or
> PRACK), it is not even a confirmation.
> >
> >And, again, I know there are many implementations that send
> a copy of
> >the SDP after the SDP answer has been sent, so instead of
> saying that
> >it should not be done I think it is much more important to
> say that, if
> >it is done, it must be identical to the SDP answer. In other
> words, to
> >make it clear that the UAS can not send a NEW offer (or
> updated answer)
> >in a subsequent response after the SDP answer has been sent.
> >
> >Since UAC MUST ignored it, there is no problem on a interworking.
> >Why must it be identical to the SDP answer?
>
> Well, if you look at it that way, fine. But, then the
> important thing is that the UAC must ignore it - not that the
> UAS should not send it.
>
> Regards,
>
> Christer
>
>
>
>
> > >Regards,
> > >
> > >Christer
> > >
> > >Hans Erik van Elburg <***@gmail.com> Mon, 19 Apr 2010
> > >13:55:41 +0200
> > >>> - An UAS MAY insert a SDP body that is identical to the
> > SDP answer,
> > >>> in an unreliable provisional response before the SDP
> answer has
> > >>> been sent.
> > >>>
> > >>> - The UAS MUST NOT insert a SDP body that is not
> > identical to the
> > >>> SDP answer, in an unreliable provisional response
> before the SDP
> > >>> answer has been sent.
> > >>>
> > >>This is terribly confusing. Very probabe that noone will
> > get it right.
> > >>Triple negation. And talking about sending and answer before the
> > >>answer has been sent. ???
> > >>
> > >>
> > >>> - The UAS MUST NOT insert a SDP body in any response
> > after the SDP
> > >>> answer has been sent.
> > >>>
> > >>This means that you can't send it again after you've send
> it in an
> > >>unreliable provisional response. Do you want tto say that?
> > >>
> > >>/Hans Erik van Elburg
> >
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-***@cs.columbia.edu for questions on current
> sip Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Paul Kyzivat]

DRAGE, Keith (Keith) wrote:
> Do remember that there are certain cases where the UAC will not ignore it. These are the cases where the message containing original answer has not yet arrived or been lost, and the protocol has not yet recovered from that.

Hmm. Can you say more?

Are you thinking of a case where the answer has been sent in a reliable
provisional, but the PRACK has not yet been received? And then that
*some* SDP is included in a subsequent unreliable provisional, or 2xx?

That is an interesting case. The one that would be least wierd is:

UAC UAS
| INVITE (SDP1) |
|----------------->|
| 1xx REL (SDP2) |
| X--------------|
| 2xx (no SDP) |
|<-----------------|

I think that implies a different best practice:

If the UAS has sent an answer in a reliable provisional, if it sends a
2xx before receiving a prack of the answer, it should include the answer
in the 2xx as well.

(If the UAS intends to initiate another o/a it MUST await the prack, so
if the 1xx is lost it will be retransmitted.)

Thanks,
Paul




| |
|<-----------------|
| |
| |
|----------------->|
| |
|<-----------------|
| |
| |
|----------------->|
| |
|<-----------------|
| |
| |
|----------------->|
| |
|<-----------------|
| |
| |
|----------------->|
| |
|<-----------------|
| |

> regards
>
> Keith
>
>> -----Original Message-----
>> From: sipping-***@ietf.org
>> [mailto:sipping-***@ietf.org] On Behalf Of Christer Holmberg
>> Sent: Tuesday, April 20, 2010 1:47 PM
>> To: OKUMURA Shinji; ***@ietf.org
>> Subject: Re: [Sipping] Is SDP in an unreliable response "the
>> answer" ???
>>
>>
>> Hi,
>>
>>>>> Before sending an answer,
>>>>> - An UAS MAY send unreliable provisional responses with a SDP.
>>>>> - And the SDP MUST be identical to an answer SDP.
>>>>>
>>>>> After sending an answer,
>>>>> - The UAS should not insert a SDP in any response.
>>>>>
>>>>> Is this OK?
>>>> That text still doesn't say what an SDP inserted after sending the
>>>> answer means, only that it should not be sent.
>>> The SDP means nothing. it is neither an offer nor an answer.
>> Exactly. In my opinion that is what is important - not
>> whether the UAS inserts SDP or not.
>>
>>>> I still don't see why we need to make a separation about SDP sent
>>>> before and after the answer, because in both cases the SDP must be
>>>> identical to the answer.
>>> 1. RFC3261 says that UAS MAY send it before the answer and
>>> doesn't say nothing after the answer.
>> That is one reason why we are writing the draft - to clarify
>> things which may not be clear in the specs.
>>
>>> 2. The SDP MUST be ignored by UAC. it is meaningless.
>> I agree, and that is what we must be clear about. Because, as
>> we know, some people want to send a NEW offer (or updated
>> answer) in a subsequent response, and that is not allowed.
>>
>>
>>> 3. if another o/a exchange is occured (using UPDATE or
>> PRACK), it is not even a confirmation.
>>> And, again, I know there are many implementations that send
>> a copy of
>>> the SDP after the SDP answer has been sent, so instead of
>> saying that
>>> it should not be done I think it is much more important to
>> say that, if
>>> it is done, it must be identical to the SDP answer. In other
>> words, to
>>> make it clear that the UAS can not send a NEW offer (or
>> updated answer)
>>> in a subsequent response after the SDP answer has been sent.
>>>
>>> Since UAC MUST ignored it, there is no problem on a interworking.
>>> Why must it be identical to the SDP answer?
>> Well, if you look at it that way, fine. But, then the
>> important thing is that the UAC must ignore it - not that the
>> UAS should not send it.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>> Hans Erik van Elburg <***@gmail.com> Mon, 19 Apr 2010
>>>> 13:55:41 +0200
>>>>>> - An UAS MAY insert a SDP body that is identical to the
>>> SDP answer,
>>>>>> in an unreliable provisional response before the SDP
>> answer has
>>>>>> been sent.
>>>>>>
>>>>>> - The UAS MUST NOT insert a SDP body that is not
>>> identical to the
>>>>>> SDP answer, in an unreliable provisional response
>> before the SDP
>>>>>> answer has been sent.
>>>>>>
>>>>> This is terribly confusing. Very probabe that noone will
>>> get it right.
>>>>> Triple negation. And talking about sending and answer before the
>>>>> answer has been sent. ???
>>>>>
>>>>>
>>>>>> - The UAS MUST NOT insert a SDP body in any response
>>> after the SDP
>>>>>> answer has been sent.
>>>>>>
>>>>> This means that you can't send it again after you've send
>> it in an
>>>>> unreliable provisional response. Do you want tto say that?
>>>>>
>>>>> /Hans Erik van Elburg
>> _______________________________________________
>> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use sip-***@cs.columbia.edu for questions on current
>> sip Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[DRAGE, Keith (Keith)]

Yep, thinking through this is probably the only case. I thought originally there might be some more.

So I guess this is just a minor justification for repeating the answer (unchanged) in subsequent messages, including the final response.

(It is also a reason against trying to implement changing it in subsequent messages, as there is no guarantee what order these will arrive in)

regards

Keith



> -----Original Message-----
> From: Paul Kyzivat [mailto:***@cisco.com]
> Sent: Tuesday, April 20, 2010 3:05 PM
> To: DRAGE, Keith (Keith)
> Cc: Christer Holmberg; OKUMURA Shinji; ***@ietf.org
> Subject: Re: [Sipping] Is SDP in an unreliable response "the
> answer" ???
>
>
>
> DRAGE, Keith (Keith) wrote:
> > Do remember that there are certain cases where the UAC will
> not ignore it. These are the cases where the message
> containing original answer has not yet arrived or been lost,
> and the protocol has not yet recovered from that.
>
> Hmm. Can you say more?
>
> Are you thinking of a case where the answer has been sent in
> a reliable provisional, but the PRACK has not yet been
> received? And then that
> *some* SDP is included in a subsequent unreliable provisional, or 2xx?
>
> That is an interesting case. The one that would be least wierd is:
>
> UAC UAS
> | INVITE (SDP1) |
> |----------------->|
> | 1xx REL (SDP2) |
> | X--------------|
> | 2xx (no SDP) |
> |<-----------------|
>
> I think that implies a different best practice:
>
> If the UAS has sent an answer in a reliable provisional, if
> it sends a 2xx before receiving a prack of the answer, it
> should include the answer in the 2xx as well.
>
> (If the UAS intends to initiate another o/a it MUST await the
> prack, so if the 1xx is lost it will be retransmitted.)
>
> Thanks,
> Paul
>
>
>
>
> | |
> |<-----------------|
> | |
> | |
> |----------------->|
> | |
> |<-----------------|
> | |
> | |
> |----------------->|
> | |
> |<-----------------|
> | |
> | |
> |----------------->|
> | |
> |<-----------------|
> | |
> | |
> |----------------->|
> | |
> |<-----------------|
> | |
>
> > regards
> >
> > Keith
> >
> >> -----Original Message-----
> >> From: sipping-***@ietf.org
> >> [mailto:sipping-***@ietf.org] On Behalf Of Christer Holmberg
> >> Sent: Tuesday, April 20, 2010 1:47 PM
> >> To: OKUMURA Shinji; ***@ietf.org
> >> Subject: Re: [Sipping] Is SDP in an unreliable response
> "the answer"
> >> ???
> >>
> >>
> >> Hi,
> >>
> >>>>> Before sending an answer,
> >>>>> - An UAS MAY send unreliable provisional responses with a SDP.
> >>>>> - And the SDP MUST be identical to an answer SDP.
> >>>>>
> >>>>> After sending an answer,
> >>>>> - The UAS should not insert a SDP in any response.
> >>>>>
> >>>>> Is this OK?
> >>>> That text still doesn't say what an SDP inserted after
> sending the
> >>>> answer means, only that it should not be sent.
> >>> The SDP means nothing. it is neither an offer nor an answer.
> >> Exactly. In my opinion that is what is important - not whether the
> >> UAS inserts SDP or not.
> >>
> >>>> I still don't see why we need to make a separation about
> SDP sent
> >>>> before and after the answer, because in both cases the
> SDP must be
> >>>> identical to the answer.
> >>> 1. RFC3261 says that UAS MAY send it before the answer and
> >>> doesn't say nothing after the answer.
> >> That is one reason why we are writing the draft - to
> clarify things
> >> which may not be clear in the specs.
> >>
> >>> 2. The SDP MUST be ignored by UAC. it is meaningless.
> >> I agree, and that is what we must be clear about. Because, as we
> >> know, some people want to send a NEW offer (or updated
> >> answer) in a subsequent response, and that is not allowed.
> >>
> >>
> >>> 3. if another o/a exchange is occured (using UPDATE or
> >> PRACK), it is not even a confirmation.
> >>> And, again, I know there are many implementations that send
> >> a copy of
> >>> the SDP after the SDP answer has been sent, so instead of
> >> saying that
> >>> it should not be done I think it is much more important to
> >> say that, if
> >>> it is done, it must be identical to the SDP answer. In other
> >> words, to
> >>> make it clear that the UAS can not send a NEW offer (or
> >> updated answer)
> >>> in a subsequent response after the SDP answer has been sent.
> >>>
> >>> Since UAC MUST ignored it, there is no problem on a interworking.
> >>> Why must it be identical to the SDP answer?
> >> Well, if you look at it that way, fine. But, then the
> important thing
> >> is that the UAC must ignore it - not that the UAS should
> not send it.
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >>
> >>>> Regards,
> >>>>
> >>>> Christer
> >>>>
> >>>> Hans Erik van Elburg <***@gmail.com> Mon, 19 Apr 2010
> >>>> 13:55:41 +0200
> >>>>>> - An UAS MAY insert a SDP body that is identical to the
> >>> SDP answer,
> >>>>>> in an unreliable provisional response before the SDP
> >> answer has
> >>>>>> been sent.
> >>>>>>
> >>>>>> - The UAS MUST NOT insert a SDP body that is not
> >>> identical to the
> >>>>>> SDP answer, in an unreliable provisional response
> >> before the SDP
> >>>>>> answer has been sent.
> >>>>>>
> >>>>> This is terribly confusing. Very probabe that noone will
> >>> get it right.
> >>>>> Triple negation. And talking about sending and answer
> before the
> >>>>> answer has been sent. ???
> >>>>>
> >>>>>
> >>>>>> - The UAS MUST NOT insert a SDP body in any response
> >>> after the SDP
> >>>>>> answer has been sent.
> >>>>>>
> >>>>> This means that you can't send it again after you've send
> >> it in an
> >>>>> unreliable provisional response. Do you want tto say that?
> >>>>>
> >>>>> /Hans Erik van Elburg
> >> _______________________________________________
> >> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> >> This list is for NEW development of the application of SIP Use
> >> sip-***@cs.columbia.edu for questions on current sip Use
> >> ***@ietf.org 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-***@cs.columbia.edu for questions on current sip Use
> > ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Paul Kyzivat]

Here is my attempt at summarizing the discussion conclusions:

Normative things (stated or implied in existing RFCs):

- If the UAC sent an offer in the INVITE, then after it receives SDP
(the answer) in a reliable response to the INVITE, any SDP in subsequent
responses to the INVITE MUST be ignored.

- Further, if SDP is received in an unreliable response to the invite
prior to receiving SDP in a reliable response, then it MUST be treated
as the answer for purposes of media processing, but not for purposes of
determining when another offer may be sent or received.

- if the UAS receives an offer in the INVITE, it MUST NOT include SDP in
any response it sends until it has determined the intended answer SDP to
the offer.

- once the intended answer SDP is determined, it MUST be sent in a
reliable response to the INVITE. It MAY be sent in one or more
*preceding* unreliable provisional responses.

Non-normative, best practice suggestions:

- if the UAS receives an offer in the invite, once it has sent the
answer in a reliable response, it should not send any SDP in subsequent
responses to the INVITE.

Thanks,
Paul

Christer Holmberg wrote:
> Hi,
>
>>>> Before sending an answer,
>>>> - An UAS MAY send unreliable provisional responses with a SDP.
>>>> - And the SDP MUST be identical to an answer SDP.
>>>>
>>>> After sending an answer,
>>>> - The UAS should not insert a SDP in any response.
>>>>
>>>> Is this OK?
>>> That text still doesn't say what an SDP inserted after sending the
>>> answer means, only that it should not be sent.
>> The SDP means nothing. it is neither an offer nor an answer.
>
> Exactly. In my opinion that is what is important - not whether the UAS inserts SDP or not.
>
>>> I still don't see why we need to make a separation about SDP sent
>>> before and after the answer, because in both cases the SDP must be
>>> identical to the answer.
>> 1. RFC3261 says that UAS MAY send it before the answer and
>> doesn't say nothing after the answer.
>
> That is one reason why we are writing the draft - to clarify things which may not be clear in the specs.
>
>> 2. The SDP MUST be ignored by UAC. it is meaningless.
>
> I agree, and that is what we must be clear about. Because, as we know, some people want to send a NEW offer (or updated answer) in a subsequent response, and that is not allowed.
>
>
>> 3. if another o/a exchange is occured (using UPDATE or PRACK), it is not even a confirmation.
>>
>> And, again, I know there are many implementations that send
>> a copy of the SDP after the SDP answer has been sent, so instead of
>> saying that it should not be done I think it is much more important to
>> say that, if it is done, it must be identical to the SDP answer. In other
>> words, to make it clear that the UAS can not send a NEW offer (or
>> updated answer) in a subsequent response after the SDP answer has been sent.
>>
>> Since UAC MUST ignored it, there is no problem on a interworking.
>> Why must it be identical to the SDP answer?
>
> Well, if you look at it that way, fine. But, then the important thing is that the UAC must ignore it - not that the UAS should not send it.
>
> Regards,
>
> Christer
>
>
>
>
>>> Regards,
>>>
>>> Christer
>>>
>>> Hans Erik van Elburg <***@gmail.com> Mon, 19 Apr 2010
>>> 13:55:41 +0200
>>>>> - An UAS MAY insert a SDP body that is identical to the
>> SDP answer,
>>>>> in an unreliable provisional response before the SDP answer has
>>>>> been sent.
>>>>>
>>>>> - The UAS MUST NOT insert a SDP body that is not
>> identical to the
>>>>> SDP answer, in an unreliable provisional response before the SDP
>>>>> answer has been sent.
>>>>>
>>>> This is terribly confusing. Very probabe that noone will
>> get it right.
>>>> Triple negation. And talking about sending and answer before the
>>>> answer has been sent. ???
>>>>
>>>>
>>>>> - The UAS MUST NOT insert a SDP body in any response
>> after the SDP
>>>>> answer has been sent.
>>>>>
>>>> This means that you can't send it again after you've send it in an
>>>> unreliable provisional response. Do you want tto say that?
>>>>
>>>> /Hans Erik van Elburg
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Kevin P. Fleming]

Paul Kyzivat wrote:
> Here is my attempt at summarizing the discussion conclusions:
>
> Normative things (stated or implied in existing RFCs):
>
> - If the UAC sent an offer in the INVITE, then after it receives SDP
> (the answer) in a reliable response to the INVITE, any SDP in subsequent
> responses to the INVITE MUST be ignored.
>
> - Further, if SDP is received in an unreliable response to the invite
> prior to receiving SDP in a reliable response, then it MUST be treated
> as the answer for purposes of media processing, but not for purposes of
> determining when another offer may be sent or received.
>
> - if the UAS receives an offer in the INVITE, it MUST NOT include SDP in
> any response it sends until it has determined the intended answer SDP to
> the offer.
>
> - once the intended answer SDP is determined, it MUST be sent in a
> reliable response to the INVITE. It MAY be sent in one or more
> *preceding* unreliable provisional responses.
>
> Non-normative, best practice suggestions:
>
> - if the UAS receives an offer in the invite, once it has sent the
> answer in a reliable response, it should not send any SDP in subsequent
> responses to the INVITE.

I think you've got it, yes.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: ***@digium.com
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Paul Kyzivat]

Paul Kyzivat wrote:

> Then the issue is that *someone else* (who Gao has had occasion to do
> interop testing with) is claiming that there is a different, yet
> legitimate, interpretation of the exiting text. Namely:
>
> - *if* the UAC receives SDP in an unreliable response before
> receiving it in a reliable response, it MUST begin to use it
> in the same way that it would use it if it had been received
> in a reliable response,
>
> - the UAC MUST (or SHOULD?) consider this SDP to be "the answer",
> and hence it MAY send another offer, even before receiving
> another copy of that answer SDP in a *reliable* response.
>
> - still it MUST ignore SDP in subsequent responses to the
> INVITE.
>
> If so, then the question comes down to:
>
> Is this alternate interpretation a valid and legitimate interpretation
> of the existing text, or not?
>
> I agree that this is a fair question to ask, and I am not yet settled on
> an answer to it.
>
> I am approaching this in the manner of a mathematical proof by
> contradiction: If this alternative interpretation leads to some sort of
> inconsistency, then it is not valid. If we can find no inconsistencies,
> then it is a valid interpretation. And if it is, then the text is
> ambiguous and will require normative changes to fix.

I have now found the contradiction I was looking for:

If the UAC thought that receipt of the unreliable response with SDP
meant it could now send another offer, in what message could it send
that offer? The only messages where it could include an offer are:

- an INVITE. But it is forbidden from sending another INVITE until
the current INVITE transaction is complete.

- an UPDATE. But RFC 3311 says

o If the UPDATE is being sent before completion of the initial
INVITE transaction, and the initial INVITE contained an offer,
the UPDATE can contain an offer if the callee generated an
answer in a reliable provisional response, and the caller has
received answers to any other offers it sent in either PRACK or
UPDATE, and has generated answers for any offers it received in
an UPDATE from the callee.

(note that this language itself is non-normative and is justified as
a corollary of 3261.)

This rules out sending the new offer in an UPDATE.

- a PRACK. But a PRACK can only be sent in response to a reliable
provisional. The assumption here is that the answer has not been sent
in a reliable provisional yet. So the PRACK would only be an option
if a reliable provisional *without* SDP was sent after sending an
answer in an unreliable provisional. This is a very weird case.

- in a response. But the only case where an offer is permitted in a
response is in the response to INVITE, which isn't a possibility here.

I think the above is enough to debunk this interpretation.

Thanks,
Paul

_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Kevin P. Fleming]

Paul Kyzivat wrote:

> - a PRACK. But a PRACK can only be sent in response to a reliable
> provisional. The assumption here is that the answer has not been sent
> in a reliable provisional yet. So the PRACK would only be an option
> if a reliable provisional *without* SDP was sent after sending an
> answer in an unreliable provisional. This is a very weird case.

Is this even allowed? I would think that once an answer has been sent in
an unreliable provisional response, the identical answer MUST be
included in (at least) the first reliable provisional response if one is
sent. Allowing any sort of reliable response that does not contain an
identical copy of the answer that was sent in an unreliable response
seems like a recipe for disaster.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: ***@digium.com
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Paul Kyzivat]

Kevin P. Fleming wrote:
> Paul Kyzivat wrote:
>
>> - a PRACK. But a PRACK can only be sent in response to a reliable
>> provisional. The assumption here is that the answer has not been sent
>> in a reliable provisional yet. So the PRACK would only be an option
>> if a reliable provisional *without* SDP was sent after sending an
>> answer in an unreliable provisional. This is a very weird case.
>
> Is this even allowed? I would think that once an answer has been sent in
> an unreliable provisional response, the identical answer MUST be
> included in (at least) the first reliable provisional response if one is
> sent. Allowing any sort of reliable response that does not contain an
> identical copy of the answer that was sent in an unreliable response
> seems like a recipe for disaster.

Its hard to imagine why the UAS would do such an odd thing. But AFAIK it
is not *forbidden* from sending a reliable provisional without the answer.

I don't see it as a recipe for disaster if the UAC is carefully
constructed. But based on the range of behavior in the wild, I think
this might have a high probability of working unpredictably.

Thanks,
Paul

_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Christer Holmberg]

Hi,

>>> - a PRACK. But a PRACK can only be sent in response to a reliable
>>> provisional. The assumption here is that the answer has not been sent
>>> in a reliable provisional yet. So the PRACK would only be an option
>>> if a reliable provisional *without* SDP was sent after sending an
>>> answer in an unreliable provisional. This is a very weird case.
>>
>> Is this even allowed? I would think that once an answer has been sent in
>> an unreliable provisional response, the identical answer MUST be
>> included in (at least) the first reliable provisional response if one is
>> sent. Allowing any sort of reliable response that does not contain an
>> identical copy of the answer that was sent in an unreliable response
>> seems like a recipe for disaster.
>
>Its hard to imagine why the UAS would do such an odd thing. But AFAIK it
>is not *forbidden* from sending a reliable provisional without the answer.
>
>I don't see it as a recipe for disaster if the UAC is carefully
>constructed. But based on the range of behavior in the wild, I think
>this might have a high probability of working unpredictably.

I agree. This is a problem I have seen over the years, and it's not only related to SDP: implementations make assumptions about the presence of information elements, even if the presence/non-presence is not required, and even if the implementation doesn't need the information for anything.

Now, we can always blame implementors for not reading the specs carefully enough, but the fact that we are working on the offer/answer clarification draft, and the re-INVITE clarification draft, shows that SDP offer/answer for SIP is a mess - and the CapNeg vulcano hasn't even erupted yet :)

Regards.

Christer
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[g***@zte.com.cn]

Paul Kyzivat <***@cisco.com> ÐŽÓÚ 2010-04-14 22:12:48:

>
>
> Somogyi, Gabor (NSN - HU/Budapest) wrote:
> > Hi,
> >
> > RFC3261: "...MUST ignore any session descriptions in subsequent
> > responses..."
> > I think that the common industry understanding of RFC3261 is that 1
> > offer has 1 answer, even though that 1 answer may be transmitted
several
> > times.
>
> Yes. Well, actually one answer per dialog. (With forking, an offer in
> the initial invite will get a separate answer per-forked-dialog.)
>
> > And the 1st transmission is used (treated as THE answer). While
> > you are speaking about several answers with 1 matching offer. That is
a
> > fundamental difference.
>
> This of course only makes sense if the sdp in all unreliable responses
> is the same as the sdp in the first reliable response. That is so
> because any/all of the unreliable responses may be lost. You cannot
> count on the UAC using the SDP from the first transmission.
>
> And because of that, a valid implementation could drop all the SDP
> received unreliably and only process the one received reliably.

Supporting of this.
My point here is that making UAC's using of the SDP in first reliable
response normatively, no matter how many SDP it received before the *real*
answer. And how UAC handle SDP(from UAS) before the real answer is another
issue, it can be BCP issue.

>
> > In your chart SDP4 is a reliable answer. Therefore SDP5 might be
> > interpreted as a new offer, hence UAC could send an answer in PRACK.
> > Quite similarly to 3PCC cases, where 200 contains the offer and ACK
the
> > answer.
>
> That has been investigated. Its not allowed. (Unfortunately I cannot
> recall the chain of reasoning that derived its illegality - it wasn't
> obvious but it was sound. It was worked out a *long* time ago.)
>
> Thanks,
> Paul



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[Eric wang]

HI,
inlines.

BR.
2010/4/15 <***@zte.com.cn>

>
> Paul Kyzivat <***@cisco.com> 写于 2010-04-14 22:12:48:
>
>
> >
> >
> > Somogyi, Gabor (NSN - HU/Budapest) wrote:
> > > Hi,
> > >
> > > RFC3261: "...MUST ignore any session descriptions in subsequent
> > > responses..."
> > > I think that the common industry understanding of RFC3261 is that 1
> > > offer has 1 answer, even though that 1 answer may be transmitted
> several
> > > times.
> >
> > Yes. Well, actually one answer per dialog. (With forking, an offer in
> > the initial invite will get a separate answer per-forked-dialog.)
> >
> > > And the 1st transmission is used (treated as THE answer). While
> > > you are speaking about several answers with 1 matching offer. That is a
>
> > > fundamental difference.
> >
> > This of course only makes sense if the sdp in all unreliable responses
> > is the same as the sdp in the first reliable response. That is so
> > because any/all of the unreliable responses may be lost. You cannot
> > count on the UAC using the SDP from the first transmission.
> >
> > And because of that, a valid implementation could drop all the SDP
> > received unreliably and only process the one received reliably.
>
>
> Supporting of this.
> My point here is that making UAC's using of the SDP in first reliable
> response normatively, no matter how many SDP it received before the *real*
> answer. And how UAC handle SDP(from UAS) before the real answer is another
> issue, it can be BCP issue.


Eric: I think, the UAC should listen the SDP sending packets,and choose
another to listen according to rfc3264.
Reuse Shinji 's chart, if SDP2 sends packets while SDP3/SDP4 don't,
the UAC should listen SDP2 and SDP5.

UAC UAS
| F1 INVITE (SDP1) | <-- offer
|-------------------->|
| F2 1xx (SDP2) |
|<--------------------|
| F3 1xx (SDP3) |
|<--------------------|
| F4 1xx (SDP4) |
|<--------------------|
| F5 1xx-rel (SDP5) |<-- answer
|<--------------------|



> >
> > > In your chart SDP4 is a reliable answer. Therefore SDP5 might be
> > > interpreted as a new offer, hence UAC could send an answer in PRACK.
> > > Quite similarly to 3PCC cases, where 200 contains the offer and ACK the
>
> > > answer.
> >
> > That has been investigated. Its not allowed. (Unfortunately I cannot
> > recall the chain of reasoning that derived its illegality - it wasn't
> > obvious but it was sound. It was worked out a *long* time ago.)
> >
> > Thanks,
> > Paul
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>
>
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org for new developments of core SIP
>

[Paul Kyzivat]

Eric - inline

Eric wang wrote:
> HI,
> inlines.
>
> BR.
> 2010/4/15 <***@zte.com.cn <mailto:***@zte.com.cn>>
>
>
> Paul Kyzivat <***@cisco.com <mailto:***@cisco.com>> 写于
> 2010-04-14 22:12:48:
>
>
> >
> >
> > Somogyi, Gabor (NSN - HU/Budapest) wrote:
> > > Hi,
> > >
> > > RFC3261: "...MUST ignore any session descriptions in subsequent
> > > responses..."
> > > I think that the common industry understanding of RFC3261 is
> that 1
> > > offer has 1 answer, even though that 1 answer may be
> transmitted several
> > > times.
> >
> > Yes. Well, actually one answer per dialog. (With forking, an offer in
> > the initial invite will get a separate answer per-forked-dialog.)
> >
> > > And the 1st transmission is used (treated as THE answer). While
> > > you are speaking about several answers with 1 matching offer.
> That is a
> > > fundamental difference.
> >
> > This of course only makes sense if the sdp in all unreliable
> responses
> > is the same as the sdp in the first reliable response. That is so
> > because any/all of the unreliable responses may be lost. You cannot
> > count on the UAC using the SDP from the first transmission.
> >
> > And because of that, a valid implementation could drop all the SDP
> > received unreliably and only process the one received reliably.
>
>
> Supporting of this.
> My point here is that making UAC's using of the SDP in first
> reliable response normatively, no matter how many SDP it received
> before the *real* answer. And how UAC handle SDP(from UAS) before
> the real answer is another issue, it can be BCP issue.
>
>
> Eric: I think, the UAC should listen the SDP sending
> packets,and choose another to listen according to rfc3264.
> Reuse Shinji 's chart, if SDP2 sends packets while SDP3/SDP4 don't,
> the UAC should listen SDP2 and SDP5.

Eric,

I think you may be talking about cases where the call has been forked to
different destinations, and the distinct answers are coming from them.
Is that right?

Because in that case the responses should have different to-tags, thus
becoming distinct (early) dialogs. The discussion we are having is about
what happens in a *single* dialog. And in a single dialog the behavior
you describe is *wrong*.

When there are multiple early dialogs, it is indeed a challenge for the
UAC to figure out what to do. And one of the things it might choose is
to listen to one input stream and ignore the others. Unfortunately,
there is universal and certain way to associate the incoming media
streams you are receiving with the answers you have received in the
signaling. You can do so in certain cases that may apply to you, such as
when symmetric RTP is used (address/port of sender is same as
address/port that is listened on.)

Thanks,
Paul


> UAC UAS
> | F1 INVITE (SDP1) | <-- offer
> |-------------------->|
> | F2 1xx (SDP2) |
> |<--------------------|
> | F3 1xx (SDP3) |
> |<--------------------|
> | F4 1xx (SDP4) |
> |<--------------------|
> | F5 1xx-rel (SDP5) |<-- answer
> |<--------------------|
>
>
>
> >
> > > In your chart SDP4 is a reliable answer. Therefore SDP5 might be
> > > interpreted as a new offer, hence UAC could send an answer in
> PRACK.
> > > Quite similarly to 3PCC cases, where 200 contains the offer and
> ACK the
> > > answer.
> >
> > That has been investigated. Its not allowed. (Unfortunately I cannot
> > recall the chain of reasoning that derived its illegality - it wasn't
> > obvious but it was sound. It was worked out a *long* time ago.)
> >
> > Thanks,
> > Paul
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>
>
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-***@cs.columbia.edu
> <mailto:sip-***@cs.columbia.edu> for questions on current sip
> Use ***@ietf.org <mailto:***@ietf.org> 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-***@cs.columbia.edu for questions on current sip
Us

[Paul Kyzivat]

another correction :-(
(I'm having a bad day that way)

Paul Kyzivat wrote:
...
> I think you may be talking about cases where the call has been forked to
> different destinations, and the distinct answers are coming from them.
> Is that right?
>
> Because in that case the responses should have different to-tags, thus
> becoming distinct (early) dialogs. The discussion we are having is about
> what happens in a *single* dialog. And in a single dialog the behavior
> you describe is *wrong*.
>
> When there are multiple early dialogs, it is indeed a challenge for the
> UAC to figure out what to do. And one of the things it might choose is
> to listen to one input stream and ignore the others. Unfortunately,
> there is universal and certain way to associate the incoming media

s/there is universal/there is *no* universal/

> streams you are receiving with the answers you have received in the
> signaling. You can do so in certain cases that may apply to you, such as
> when symmetric RTP is used (address/port of sender is same as
> address/port that is listened on.)

Sorry,
Paul
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Eric wang]

Hi Paul,
inlines.


On Thu, Apr 15, 2010 at 10:42 PM, Paul Kyzivat <***@cisco.com> wrote:

> Eric - inline
>
> Eric wang wrote:
>
>> HI,
>> inlines.
>>
>> BR.
>> 2010/4/15 <***@zte.com.cn <mailto:***@zte.com.cn>>
>>
>>
>> Paul Kyzivat <***@cisco.com <mailto:***@cisco.com>> ÐŽÓÚ
>>
>> 2010-04-14 22:12:48:
>>
>>
>> >
>> >
>> > Somogyi, Gabor (NSN - HU/Budapest) wrote:
>> > > Hi,
>> > > > > RFC3261: "...MUST ignore any session descriptions in
>> subsequent
>> > > responses..."
>> > > I think that the common industry understanding of RFC3261 is
>> that 1
>> > > offer has 1 answer, even though that 1 answer may be
>> transmitted several
>> > > times.
>> >
>> > Yes. Well, actually one answer per dialog. (With forking, an offer
>> in
>> > the initial invite will get a separate answer per-forked-dialog.)
>> >
>> > > And the 1st transmission is used (treated as THE answer). While
>> > > you are speaking about several answers with 1 matching offer.
>> That is a
>> > > fundamental difference.
>> >
>> > This of course only makes sense if the sdp in all unreliable
>> responses
>> > is the same as the sdp in the first reliable response. That is so
>> > because any/all of the unreliable responses may be lost. You cannot
>> > count on the UAC using the SDP from the first transmission.
>> >
>> > And because of that, a valid implementation could drop all the SDP
>> > received unreliably and only process the one received reliably.
>>
>>
>> Supporting of this.
>> My point here is that making UAC's using of the SDP in first
>> reliable response normatively, no matter how many SDP it received
>> before the *real* answer. And how UAC handle SDP(from UAS) before
>> the real answer is another issue, it can be BCP issue.
>> Eric: I think, the UAC should listen the SDP sending packets,and choose
>> another to listen according to rfc3264.
>> Reuse Shinji 's chart, if SDP2 sends packets while SDP3/SDP4 don't,
>> the UAC should listen SDP2 and SDP5.
>>
>
> Eric,
>
> I think you may be talking about cases where the call has been forked to
> different destinations, and the distinct answers are coming from them. Is
> that right?
>
No. I meant there may be several non-reliable responses in a *single*
dialog.
There maybe several servers that want to send non-reliable response with
SDP(neither offer nor answer) to the caller.I accept it as non-reliable
responses with SDP can also establish early dialog for tone/announcement and
do nothing with offer/answer negotiation between the caller and the called.
I know it violate rfc3261, but it's useful and simple.


> Because in that case the responses should have different to-tags, thus
> becoming distinct (early) dialogs. The discussion we are having is about
> what happens in a *single* dialog. And in a single dialog the behavior you
> describe is *wrong*.
>
But I cannot accept that several reliable responses with SDP appear in a
single dialog, and it seems be allowed in Shinji's chart.

BR
Eric



> When there are multiple early dialogs, it is indeed a challenge for the UAC
> to figure out what to do. And one of the things it might choose is to listen
> to one input stream and ignore the others. Unfortunately, there is universal
> and certain way to associate the incoming media streams you are receiving
> with the answers you have received in the signaling. You can do so in
> certain cases that may apply to you, such as when symmetric RTP is used
> (address/port of sender is same as address/port that is listened on.)
>
> Thanks,
> Paul
>
>
> UAC UAS
>> | F1 INVITE (SDP1) | <-- offer
>> |-------------------->|
>> | F2 1xx (SDP2) |
>> |<--------------------|
>> | F3 1xx (SDP3) |
>> |<--------------------|
>> | F4 1xx (SDP4) | |<--------------------|
>> | F5 1xx-rel (SDP5) |<-- answer
>> |<--------------------|
>>
>> >
>> > > In your chart SDP4 is a reliable answer. Therefore SDP5 might be
>> > > interpreted as a new offer, hence UAC could send an answer in
>> PRACK.
>> > > Quite similarly to 3PCC cases, where 200 contains the offer and
>> ACK the
>> > > answer.
>> >
>> > That has been investigated. Its not allowed. (Unfortunately I cannot
>> > recall the chain of reasoning that derived its illegality - it
>> wasn't
>> > obvious but it was sound. It was worked out a *long* time ago.)
>> >
>> > Thanks,
>> > Paul
>>
>> --------------------------------------------------------
>> ZTE Information Security Notice: The information contained in this mail
>> is solely property of the sender's organization. This mail communication is
>> confidential. Recipients named above are obligated to maintain secrecy and
>> are not permitted to disclose the contents of this communication to others.
>> This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they are
>> addressed. If you have received this email in error please notify the
>> originator of the message. Any views expressed in this message are those of
>> the individual sender.
>> This message has been scanned for viruses and Spam by ZTE Anti-Spam
>> system.
>>
>>
>> _______________________________________________
>> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use sip-***@cs.columbia.edu
>> <mailto:sip-***@cs.columbia.edu> for questions on current sip
>> Use ***@ietf.org <mailto:***@ietf.org> for new developments of core
>> SIP
>>
>>
>>

[Paul Kyzivat]

inline, with some trimming

Eric wang wrote:
> Hi Paul,
> inlines.
>
>
> On Thu, Apr 15, 2010 at 10:42 PM, Paul Kyzivat <***@cisco.com
> <mailto:***@cisco.com>> wrote:
>
> Eric - inline
>
> Eric wang wrote:
>
> HI,
> inlines.
>
> BR.
> 2010/4/15 <***@zte.com.cn <mailto:***@zte.com.cn>
> <mailto:***@zte.com.cn <mailto:***@zte.com.cn>>>
>
>
> Paul Kyzivat <***@cisco.com <mailto:***@cisco.com>
> <mailto:***@cisco.com <mailto:***@cisco.com>>> 写于
>
> 2010-04-14 22:12:48:
>
>
> >
> >
> > Somogyi, Gabor (NSN - HU/Budapest) wrote:
> > > Hi,
> > > > > RFC3261: "...MUST ignore any session
> descriptions in subsequent
> > > responses..."
> > > I think that the common industry understanding of RFC3261 is
> that 1
> > > offer has 1 answer, even though that 1 answer may be
> transmitted several
> > > times.
> >
> > Yes. Well, actually one answer per dialog. (With forking,
> an offer in
> > the initial invite will get a separate answer
> per-forked-dialog.)
> >
> > > And the 1st transmission is used (treated as THE
> answer). While
> > > you are speaking about several answers with 1 matching
> offer.
> That is a
> > > fundamental difference.
> >
> > This of course only makes sense if the sdp in all unreliable
> responses
> > is the same as the sdp in the first reliable response.
> That is so
> > because any/all of the unreliable responses may be lost.
> You cannot
> > count on the UAC using the SDP from the first transmission.
> >
> > And because of that, a valid implementation could drop all
> the SDP
> > received unreliably and only process the one received
> reliably.
>
>
> Supporting of this.
> My point here is that making UAC's using of the SDP in first
> reliable response normatively, no matter how many SDP it received
> before the *real* answer. And how UAC handle SDP(from UAS) before
> the real answer is another issue, it can be BCP issue.
> Eric: I think, the UAC should listen the SDP sending
> packets,and choose another to listen according to rfc3264.
> Reuse Shinji 's chart, if SDP2 sends packets while SDP3/SDP4 don't,
> the UAC should listen SDP2 and SDP5.
>
>
> Eric,
>
> I think you may be talking about cases where the call has been
> forked to different destinations, and the distinct answers are
> coming from them. Is that right?
>
> No. I meant there may be several non-reliable responses in a *single*
> dialog.
> There maybe several servers that want to send non-reliable response with
> SDP(neither offer nor answer) to the caller.I accept it as non-reliable
> responses with SDP can also establish early dialog for tone/announcement
> and do nothing with offer/answer negotiation between the caller and the
> called.
> I know it violate rfc3261, but it's useful and simple.

Well, if you agree it violates 3261 then lets stop talking.
You can do lots of non-conforming things that are simple and useful. But
doing them results in interoperability problems.

And I will assert that you can achieve what you wish in a conforming way
simply by having those separate servers use a distinct to-tag for their
response, thus creating distinct early dialogs. The UAC will then
understand them for what they are - responses from different entities -
and can decide how to render them with that understanding.

> Because in that case the responses should have different to-tags,
> thus becoming distinct (early) dialogs. The discussion we are having
> is about what happens in a *single* dialog. And in a single dialog
> the behavior you describe is *wrong*.
>
> But I cannot accept that several reliable responses with SDP appear in a
> single dialog, and it seems be allowed in Shinji's chart.

Shinji was using that as an example of *invalid* usage, for the purpose
of discussing how the UAC might react to such invalid usage.

Thanks,
Paul
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ie

[DRAGE, Keith (Keith)]

As far as I am concerned we are NOT writing these things into offer answer

offer answer is meant to be a general clarification of what exists at the moment.

The statements you are proposing update RFC 3264 and need to be in a candidate standards track RFC that does that.

regards

Keith

> -----Original Message-----
> From: sipping-***@ietf.org
> [mailto:sipping-***@ietf.org] On Behalf Of OKUMURA Shinji
> Sent: Wednesday, April 14, 2010 8:32 AM
> To: ***@ietf.org
> Subject: Re: [Sipping] About offeranswer draft:
>
> Hi Gao,
>
> ***@zte.com.cn
> Wed, 14 Apr 2010 12:21:45 +0800
> >sipping-***@ietf.org 写于 2010-04-14 11:17:23:
> >
> >> Hi Gao,
> >>
> >> In the following case,
> >>
> >> UAC UAS
> >> | F1 INVITE (SDP1) | <-- offer
> >> |-------------------->|
> >> | F2 1xx (SDP2) |
> >> |<--------------------|
> >> | F3 1xx (SDP3) |
> >> |<--------------------|
> >> | F4 1xx-rel (SDP4) | <-- answer
> >> |<--------------------|
> >> | F5 1xx-rel (SDP5) |
> >> |<--------------------|
> >> | F6 1xxl (SDP6) |
> >> |<--------------------|
> >> | F7 2xx INV(SDP7) |
> >> |<--------------------|
> >> | F8 ACK |
> >> |-------------------->|
> >> (PRACK transactions are not shown)
> >>
> >> I tried to arrange the rules.
> >> (small letters mean informational)
> >>
> >> UAC,
> >> (Rc1) MUST treat SDP2 as the answer.
> >> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> >> (Rc3) may treat SDP3 as the answer.
> >
> >[Gao] OK
> >
> >> (Rc4) should treat SDP4 as the answer and confirm the
> current O/A
> >> status by sending new offer.
> >
> >[Gao] support of this, though this may be modification of
> current RFC3261.
>
> You will probably think of the following statements,
> RFC3261/13.2.1 Creating the Initial INVITE
> (snip) "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."
>
> No doubt this is one of the cussword built in this document.
> It is a personal interpretation of mine,
> "as the answer" is associated with not "treat" but "receives",
> and "treat" means "not ignore".
>
> Just putting that aside for now, I think there is a consensus that
> Rc4 does not need a modification of current RFC3261.
>
> >> UAS,
> >> (Rs1) should not send SDP5, SDP6 and SDP7.
> >> (Rs2) must not send SDP2 and SDP3 if these are not the
> same as SDP4.
> >>
> >> Rc3 and Rc4 are new added descriptions.
> >> Rs1 and Rs2 are current descriptions in this draft.
> >>
> >> I think "MUST NOT" is suitable for (Rs1).
> >> Because RFC3261 says
> >> Once the UAS has sent or received an answer to the initial
> >> offer, it MUST NOT generate subsequent offers in any responses
> >> to the initial INVITE. This means that a UAS based on this
> >> specification alone can never generate subsequent offers until
> >> completion of the initial transaction.
> >>
> >
> >[Gao] Yes.
> >
> >> SDP5 and SDP7 are regarded as "subsequent offers".
> >
> >[Gao] as "MUST NOT" is suitable for (Rs1), so there must be no
> >"subsequent offers" in subsequent response.
>
> Certainly UAC MUST ignore SDPs no matter what these are.
>
> Regards,
> Shinji
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-***@cs.columbia.edu for questions on current
> sip Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of

[Paul Kyzivat]

Keith,

I agree with with the point I think you are making. But we are walking a
fine line here. The goal has not been to enact changes with this draft.
There are some cases where the spec is definitely ambiguous, and for
those we have had to get another stds track doc to fix - e.g. reinvite.

In other cases the specs are far from clear, but if you read them very
carefully some seemingly ambiguous cases can be found to be corollaries
of existing text. In that situation, having this draft write down those
determinations doesn't change anything but is of great aid to developers.

And then there remain cases that are ambiguous, but where some best
practices can avoid the ambiguities.

If you were referring specifically to the comment:

> Just putting that aside for now, I think there is a consensus that
> Rc4 does not need a modification of current RFC3261.

then I am actually not sure at the moment which category this falls
into. Its worthy of discussion.

Thanks,
Paul

DRAGE, Keith (Keith) wrote:
> As far as I am concerned we are NOT writing these things into offer answer
>
> offer answer is meant to be a general clarification of what exists at the moment.
>
> The statements you are proposing update RFC 3264 and need to be in a candidate standards track RFC that does that.
>
> regards
>
> Keith
>
>> -----Original Message-----
>> From: sipping-***@ietf.org
>> [mailto:sipping-***@ietf.org] On Behalf Of OKUMURA Shinji
>> Sent: Wednesday, April 14, 2010 8:32 AM
>> To: ***@ietf.org
>> Subject: Re: [Sipping] About offeranswer draft:
>>
>> Hi Gao,
>>
>> ***@zte.com.cn
>> Wed, 14 Apr 2010 12:21:45 +0800
>>> sipping-***@ietf.org 写于 2010-04-14 11:17:23:
>>>
>>>> Hi Gao,
>>>>
>>>> In the following case,
>>>>
>>>> UAC UAS
>>>> | F1 INVITE (SDP1) | <-- offer
>>>> |-------------------->|
>>>> | F2 1xx (SDP2) |
>>>> |<--------------------|
>>>> | F3 1xx (SDP3) |
>>>> |<--------------------|
>>>> | F4 1xx-rel (SDP4) | <-- answer
>>>> |<--------------------|
>>>> | F5 1xx-rel (SDP5) |
>>>> |<--------------------|
>>>> | F6 1xxl (SDP6) |
>>>> |<--------------------|
>>>> | F7 2xx INV(SDP7) |
>>>> |<--------------------|
>>>> | F8 ACK |
>>>> |-------------------->|
>>>> (PRACK transactions are not shown)
>>>>
>>>> I tried to arrange the rules.
>>>> (small letters mean informational)
>>>>
>>>> UAC,
>>>> (Rc1) MUST treat SDP2 as the answer.
>>>> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
>>>> (Rc3) may treat SDP3 as the answer.
>>> [Gao] OK
>>>
>>>> (Rc4) should treat SDP4 as the answer and confirm the
>> current O/A
>>>> status by sending new offer.
>>> [Gao] support of this, though this may be modification of
>> current RFC3261.
>>
>> You will probably think of the following statements,
>> RFC3261/13.2.1 Creating the Initial INVITE
>> (snip) "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."
>>
>> No doubt this is one of the cussword built in this document.
>> It is a personal interpretation of mine,
>> "as the answer" is associated with not "treat" but "receives",
>> and "treat" means "not ignore".
>>
>> Just putting that aside for now, I think there is a consensus that
>> Rc4 does not need a modification of current RFC3261.
>>
>>>> UAS,
>>>> (Rs1) should not send SDP5, SDP6 and SDP7.
>>>> (Rs2) must not send SDP2 and SDP3 if these are not the
>> same as SDP4.
>>>> Rc3 and Rc4 are new added descriptions.
>>>> Rs1 and Rs2 are current descriptions in this draft.
>>>>
>>>> I think "MUST NOT" is suitable for (Rs1).
>>>> Because RFC3261 says
>>>> Once the UAS has sent or received an answer to the initial
>>>> offer, it MUST NOT generate subsequent offers in any responses
>>>> to the initial INVITE. This means that a UAS based on this
>>>> specification alone can never generate subsequent offers until
>>>> completion of the initial transaction.
>>>>
>>> [Gao] Yes.
>>>
>>>> SDP5 and SDP7 are regarded as "subsequent offers".
>>> [Gao] as "MUST NOT" is suitable for (Rs1), so there must be no
>>> "subsequent offers" in subsequent response.
>> Certainly UAC MUST ignore SDPs no matter what these are.
>>
>> Regards,
>> Shinji
>> _______________________________________________
>> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use sip-***@cs.columbia.edu for questions on current
>> sip Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org 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-***@cs.columbia.edu for questions on current s

[Eric wang]

Hi all,

I believe that SDP in non-reliable response is useful. eg, if the UAS
wants to send a tone to UAC while the UAC doesn't support 100rel, the UAS
can use a non-reliable response with the tone SDP.
So I believe different SDPs(compare with the answer) can exist in
non-reliable response and final 2xx response.

But, when I saw the chart below, the only words in my mind is ,"OMG, the
SIP is never SI(m)P(le) again!"




2010/4/14 OKUMURA Shinji <***@softfront.jp>

> Hi Gao,
>
> In the following case,
>
> UAC UAS
> | F1 INVITE (SDP1) | <-- offer
> |-------------------->|
> | F2 1xx (SDP2) |
> |<--------------------|
> | F3 1xx (SDP3) |
> |<--------------------|
> | F4 1xx-rel (SDP4) | <-- answer
> |<--------------------|
> | F5 1xx-rel (SDP5) |
> |<--------------------|
> | F6 1xxl (SDP6) |
> |<--------------------|
> | F7 2xx INV(SDP7) |
> |<--------------------|
> | F8 ACK |
> |-------------------->|
> (PRACK transactions are not shown)
>
> I tried to arrange the rules.
> (small letters mean informational)
>
> UAC,
> (Rc1) MUST treat SDP2 as the answer.
> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> (Rc3) may treat SDP3 as the answer.
> (Rc4) should treat SDP4 as the answer and confirm the current O/A status
> by sending new offer.
>
> UAS,
> (Rs1) should not send SDP5, SDP6 and SDP7.
> (Rs2) must not send SDP2 and SDP3 if these are not the same as SDP4.
>
> Rc3 and Rc4 are new added descriptions.
> Rs1 and Rs2 are current descriptions in this draft.
>
> I think "MUST NOT" is suitable for (Rs1).
> Because RFC3261 says
> Once the UAS has sent or received an answer to the initial
> offer, it MUST NOT generate subsequent offers in any responses
> to the initial INVITE. This means that a UAS based on this
> specification alone can never generate subsequent offers until
> completion of the initial transaction.
>
> SDP5 and SDP7 are regarded as "subsequent offers".
>
> What do you think of these?
>
> Regards,
> Shinji
>
> ***@zte.com.cn
> Mon, 12 Apr 2010 11:37:09 +0800
> >Hi Shinji,
> >
> >Please see inlines.
> >
> >Thanks,
> >
> >Gao
> >
> >sipping-***@ietf.org ÐŽÓÚ 2010-04-12 10:55:47:
> >
> >> Hi Gao,
> >>
> >> The clarifications for the section 13.2.1 of RFC 3261 is
> >> one of the major purposes in this draft.
> >>
> >> In the section 3.1 of this draft,
> >> | 3.1. Offer/Answer for the INVITE method with 100rel extension
> >> | (snip) All the session
> >> | descriptions in the unreliable responses to the INVITE request must
> >> | be identical to the answer which is included in the reliable
> >> | response.
> >>
> >> Do you doubt this clarification?
> >> In my understanding, this has already reached the consensus in WG.
> >
> >[Gao] I am not want to *challenge* the consensus we have reached in WG.
> >But as this draft is aims for clarification, not for normative correction,
> >I have no way to convince the *UAS*.
> >
> >>
> >> I'm confused.
> >> Do you have something a concrete proposal?
> >
> >[Gao] I think the original illegibility is from RFC3261. So, I sended
> >mails about it in SIPCore ML:
> >
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html
> >
> >To be honest, I think there are two options here:
> >1. Forbid different SDP(compare with the answer) before the answer
> >normatively.
> >2. Allowing different SDP(compare with the answer) before the answer
> >normatively.
> >
> >>
> >> Just to be sure, this draft is not a normative document but
> >> an informational one as you no doubt know.
> >
> >[Gao] Sure, I know it is informative.
> >
> >>
> >> Regards,
> >> Shinji
> >>
> >> ***@zte.com.cn
> >> Fri, 9 Apr 2010 16:50:12 +0800
> >> >Hi Shinji,
> >> >
> >> >Thanks firstly.
> >> >
> >> >But the UAS do not think it throws the problem. RFC3261 said UAS may
> send
> >> >the same SDP before the answer, but there is not normative words of to
> >> >forbid the different SDPs.
> >> >
> >> >And if the equipment has been in the network, unless we using the
> evident
> >> >standard, we has no way to request their correction.
> >> >
> >> >Gao
> >> >
> >> >OKUMURA Shinji <***@softfront.jp>
> >> >·¢ŒþÈË: sipping-***@ietf.org
> >> >2010-04-09 16:30
> >> >
> >> >ÊÕŒþÈË
> >> >***@ietf.org
> >> >³­ËÍ
> >> >
> >> >Ö÷Ìâ
> >> >Re: [Sipping] About offeranswer draft:
> >> >
> >> >Hi Gao,
> >> >
> >> >In this case it is no doubt the UAS is a cause of the problem.
> >> >All you have to do is say "Your UAS is against the rules".
> >> >You will surely win the fight.
> >> >
> >> >Regards,
> >> >Shinji
> >> >
> >> >***@zte.com.cn
> >> >Fri, 9 Apr 2010 15:25:58 +0800
> >> >>Hi Shinji,
> >> >>
> >> >>By myself, I am OK with the three ways. But if there's no normative
> >> >>definition here, there would be some interworking fight for this
> issue.
> >> >>
> >> >>Thanks,
> >> >>
> >> >>Gao
> >> >>
> >> >>OKUMURA Shinji <***@softfront.jp>
> >> >>·¢ŒþÈË: sipping-***@ietf.org
> >> >>2010-04-09 14:23
> >> >>
> >> >>ÊÕŒþÈË
> >> >>***@ietf.org
> >> >>³­ËÍ
> >> >>
> >> >>Ö÷Ìâ
> >> >>Re: [Sipping] About offeranswer draft:
> >> >>
> >> >>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
> >> >>
> >> >>***@zte.com.cn
> >> >>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
> earlymedia 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 <***@softfront.jp>
> >> >>>·¢ŒþÈË: sipping-***@ietf.org
> >> >>>2010-04-09 10:13
> >> >>>
> >> >>>ÊÕŒþÈË
> >> >>>***@ietf.org
> >> >>>³­ËÍ
> >> >>>
> >> >>>Ö÷Ìâ
> >> >>>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
> >> >>>
> >> >>>***@zte.com.cn
> >> >>>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,
> Ithink 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-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org for new developments of core SIP
>

[Paul Kyzivat]

Eric wang wrote:
> Hi all,
>
> I believe that SDP in non-reliable response is useful. eg, if the
> UAS wants to send a tone to UAC while the UAC doesn't support 100rel,
> the UAS can use a non-reliable response with the tone SDP.
> So I believe different SDPs(compare with the answer) can exist in
> non-reliable response and final 2xx response.

IMO this makes no sense. For one thing, the UAC is instructed to accept
the first and ignore the rest, so sending differing values will have no
utility. For another, this only affects where the UAS will receive media
- it can have no effect on where the UAC receives media. Generally the
UAC isn't transmitting until the call is established, so what is the point.

> But, when I saw the chart below, the only words in my mind is ,"OMG,
> the SIP is never SI(m)P(le) again!"

Where have you been? SIP hasn't been simple since early in the century.

Thanks,
Paul


> 2010/4/14 OKUMURA Shinji <***@softfront.jp
> <mailto:***@softfront.jp>>
>
> Hi Gao,
>
> In the following case,
>
> UAC UAS
> | F1 INVITE (SDP1) | <-- offer
> |-------------------->|
> | F2 1xx (SDP2) |
> |<--------------------|
> | F3 1xx (SDP3) |
> |<--------------------|
> | F4 1xx-rel (SDP4) | <-- answer
> |<--------------------|
> | F5 1xx-rel (SDP5) |
> |<--------------------|
> | F6 1xxl (SDP6) |
> |<--------------------|
> | F7 2xx INV(SDP7) |
> |<--------------------|
> | F8 ACK |
> |-------------------->|
> (PRACK transactions are not shown)
>
> I tried to arrange the rules.
> (small letters mean informational)
>
> UAC,
> (Rc1) MUST treat SDP2 as the answer.
> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> (Rc3) may treat SDP3 as the answer.
> (Rc4) should treat SDP4 as the answer and confirm the current O/A
> status by sending new offer.
>
> UAS,
> (Rs1) should not send SDP5, SDP6 and SDP7.
> (Rs2) must not send SDP2 and SDP3 if these are not the same as SDP4.
>
> Rc3 and Rc4 are new added descriptions.
> Rs1 and Rs2 are current descriptions in this draft.
>
> I think "MUST NOT" is suitable for (Rs1).
> Because RFC3261 says
> Once the UAS has sent or received an answer to the initial
> offer, it MUST NOT generate subsequent offers in any responses
> to the initial INVITE. This means that a UAS based on this
> specification alone can never generate subsequent offers until
> completion of the initial transaction.
>
> SDP5 and SDP7 are regarded as "subsequent offers".
>
> What do you think of these?
>
> Regards,
> Shinji
>
> ***@zte.com.cn <mailto:***@zte.com.cn>
> Mon, 12 Apr 2010 11:37:09 +0800
> >Hi Shinji,
> >
> >Please see inlines.
> >
> >Thanks,
> >
> >Gao
> >
> >sipping-***@ietf.org <mailto:sipping-***@ietf.org> 写于
> 2010-04-12 10:55:47:
> >
> >> Hi Gao,
> >>
> >> The clarifications for the section 13.2.1 of RFC 3261 is
> >> one of the major purposes in this draft.
> >>
> >> In the section 3.1 of this draft,
> >> | 3.1. Offer/Answer for the INVITE method with 100rel extension
> >> | (snip) All the session
> >> | descriptions in the unreliable responses to the INVITE
> request must
> >> | be identical to the answer which is included in the reliable
> >> | response.
> >>
> >> Do you doubt this clarification?
> >> In my understanding, this has already reached the consensus in WG.
> >
> >[Gao] I am not want to *challenge* the consensus we have reached
> in WG.
> >But as this draft is aims for clarification, not for normative
> correction,
> >I have no way to convince the *UAS*.
> >
> >>
> >> I'm confused.
> >> Do you have something a concrete proposal?
> >
> >[Gao] I think the original illegibility is from RFC3261. So, I sended
> >mails about it in SIPCore ML:
> >
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html
> >
> >To be honest, I think there are two options here:
> >1. Forbid different SDP(compare with the answer) before the answer
> >normatively.
> >2. Allowing different SDP(compare with the answer) before the answer
> >normatively.
> >
> >>
> >> Just to be sure, this draft is not a normative document but
> >> an informational one as you no doubt know.
> >
> >[Gao] Sure, I know it is informative.
> >
> >>
> >> Regards,
> >> Shinji
> >>
> >> ***@zte.com.cn <mailto:***@zte.com.cn>
> >> Fri, 9 Apr 2010 16:50:12 +0800
> >> >Hi Shinji,
> >> >
> >> >Thanks firstly.
> >> >
> >> >But the UAS do not think it throws the problem. RFC3261 said
> UAS may send
> >> >the same SDP before the answer, but there is not normative
> words of to
> >> >forbid the different SDPs.
> >> >
> >> >And if the equipment has been in the network, unless we using
> the evident
> >> >standard, we has no way to request their correction.
> >> >
> >> >Gao
> >> >
> >> >OKUMURA Shinji <***@softfront.jp
> <mailto:***@softfront.jp>>
> >> >发件人: sipping-***@ietf.org <mailto:sipping-***@ietf.org>
> >> >2010-04-09 16:30
> >> >
> >> >收件人
> >> >***@ietf.org <mailto:***@ietf.org>
> >> >抄送
> >> >
> >> >主题
> >> >Re: [Sipping] About offeranswer draft:
> >> >
> >> >Hi Gao,
> >> >
> >> >In this case it is no doubt the UAS is a cause of the problem.
> >> >All you have to do is say "Your UAS is against the rules".
> >> >You will surely win the fight.
> >> >
> >> >Regards,
> >> >Shinji
> >> >
> >> >***@zte.com.cn <mailto:***@zte.com.cn>
> >> >Fri, 9 Apr 2010 15:25:58 +0800
> >> >>Hi Shinji,
> >> >>
> >> >>By myself, I am OK with the three ways. But if there's no
> normative
> >> >>definition here, there would be some interworking fight for
> this issue.
> >> >>
> >> >>Thanks,
> >> >>
> >> >>Gao
> >> >>
> >> >>OKUMURA Shinji <***@softfront.jp
> <mailto:***@softfront.jp>>
> >> >>发件人: sipping-***@ietf.org
> <mailto:sipping-***@ietf.org>
> >> >>2010-04-09 14:23
> >> >>
> >> >>收件人
> >> >>***@ietf.org <mailto:***@ietf.org>
> >> >>抄送
> >> >>
> >> >>主题
> >> >>Re: [Sipping] About offeranswer draft:
> >> >>
> >> >>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
> >> >>
> >> >>***@zte.com.cn <mailto:***@zte.com.cn>
> >> >>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
> earlymedia 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 <***@softfront.jp
> <mailto:***@softfront.jp>>
> >> >>>发件人: sipping-***@ietf.org
> <mailto:sipping-***@ietf.org>
> >> >>>2010-04-09 10:13
> >> >>>
> >> >>>收件人
> >> >>>***@ietf.org <mailto:***@ietf.org>
> >> >>>抄送
> >> >>>
> >> >>>主题
> >> >>>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
> >> >>>
> >> >>>***@zte.com.cn <mailto:***@zte.com.cn>
> >> >>>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, Ithink 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-***@cs.columbia.edu
> <mailto:sip-***@cs.columbia.edu> for questions on current sip
> Use ***@ietf.org <mailto:***@ietf.org> 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-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org 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-***@cs.columbia.edu for questions on current si

[Eric wang]

ÔÚ 2010Äê4ÔÂ15ÈÕ ÏÂÎç1:29£¬Eric wang <***@gmail.com>ÐŽµÀ£º

> Hi Paul,
> I have been in the world for many years =_=!!!!
> We shouldn't make complicated rules because the system has already been
> complicated.
>
> In my opinion, the offer/answer model works well if responses are
> reliable.
> If we allow several reliable 18x with SDP, what happen if 18x is after
> UPDATEs.There must be some rules saying "NO".I prefer several reliable 18xs
> with SDP appear only in fork.
>
> BR
> Eric
>
>
>
> ÔÚ 2010Äê4ÔÂ14ÈÕ ÏÂÎç10:02£¬Paul Kyzivat <***@cisco.com>ÐŽµÀ£º
>
>
>>
>> Eric wang wrote:
>> > Hi all,
>> >
>> > I believe that SDP in non-reliable response is useful. eg, if the
>> > UAS wants to send a tone to UAC while the UAC doesn't support 100rel,
>> > the UAS can use a non-reliable response with the tone SDP.
>> > So I believe different SDPs(compare with the answer) can exist in
>> > non-reliable response and final 2xx response.
>>
>> IMO this makes no sense. For one thing, the UAC is instructed to accept
>> the first and ignore the rest, so sending differing values will have no
>> utility. For another, this only affects where the UAS will receive media
>> - it can have no effect on where the UAC receives media. Generally the
>> UAC isn't transmitting until the call is established, so what is the
>> point.
>>
>> > But, when I saw the chart below, the only words in my mind is ,"OMG,
>> > the SIP is never SI(m)P(le) again!"
>>
>> Where have you been? SIP hasn't been simple since early in the century.
>>
>> Thanks,
>> Paul
>>
>>
>> > 2010/4/14 OKUMURA Shinji <***@softfront.jp
>> > <mailto:***@softfront.jp>>
>> >
>> > Hi Gao,
>> >
>> > In the following case,
>> >
>> > UAC UAS
>> > | F1 INVITE (SDP1) | <-- offer
>> > |-------------------->|
>> > | F2 1xx (SDP2) |
>> > |<--------------------|
>> > | F3 1xx (SDP3) |
>> > |<--------------------|
>> > | F4 1xx-rel (SDP4) | <-- answer
>> > |<--------------------|
>> > | F5 1xx-rel (SDP5) |
>> > |<--------------------|
>> > | F6 1xxl (SDP6) |
>> > |<--------------------|
>> > | F7 2xx INV(SDP7) |
>> > |<--------------------|
>> > | F8 ACK |
>> > |-------------------->|
>> > (PRACK transactions are not shown)
>> >
>> > I tried to arrange the rules.
>> > (small letters mean informational)
>> >
>> > UAC,
>> > (Rc1) MUST treat SDP2 as the answer.
>> > (Rc2) MUST ignore SDP5, SDP6 and SDP7.
>> > (Rc3) may treat SDP3 as the answer.
>> > (Rc4) should treat SDP4 as the answer and confirm the current O/A
>> > status by sending new offer.
>> >
>> > UAS,
>> > (Rs1) should not send SDP5, SDP6 and SDP7.
>> > (Rs2) must not send SDP2 and SDP3 if these are not the same as
>> SDP4.
>> >
>> > Rc3 and Rc4 are new added descriptions.
>> > Rs1 and Rs2 are current descriptions in this draft.
>> >
>> > I think "MUST NOT" is suitable for (Rs1).
>> > Because RFC3261 says
>> > Once the UAS has sent or received an answer to the initial
>> > offer, it MUST NOT generate subsequent offers in any
>> responses
>> > to the initial INVITE. This means that a UAS based on this
>> > specification alone can never generate subsequent offers
>> until
>> > completion of the initial transaction.
>> >
>> > SDP5 and SDP7 are regarded as "subsequent offers".
>> >
>> > What do you think of these?
>> >
>> > Regards,
>> > Shinji
>> >
>>
>

[OKUMURA Shinji]

Hi Eric,

Eric wang <***@gmail.com>
Thu, 15 Apr 2010 13:29:41 +0800
>Hi Paul,
>
>I have been in the world for many years =_=!!!!
>We shouldn't make complicated rules because the system has
>already been complicated.
>
>In my opinion, the offer/answer model works well if responses
>are reliable.
>If we allow several reliable 18x with SDP, what happen if 18x
>is after UPDATEs.There must be some rules saying "NO".
>I prefer several reliable 18xs with SDP appear only in fork.

I'm confused.
Nobody says that several reliable 18x may include a SDP even if
it is the same as the answer.

Just you said "different SDPs(compare with the answer) can
exist in non-reliable response and final 2xx response".

Regards,
Shinji

>BR
>Eric
>
>Paul Kyzivat wrote
>>
>> Eric wang wrote:
>> > Hi all,
>> >
>> > I believe that SDP in non-reliable response is useful. eg, if the
>> > UAS wants to send a tone to UAC while the UAC doesn't support 100rel,
>> > the UAS can use a non-reliable response with the tone SDP.
>> > So I believe different SDPs(compare with the answer) can exist in
>> > non-reliable response and final 2xx response.
>>
>> IMO this makes no sense. For one thing, the UAC is instructed to accept
>> the first and ignore the rest, so sending differing values will have no
>> utility. For another, this only affects where the UAS will receive media
>> - it can have no effect on where the UAC receives media. Generally the
>> UAC isn't transmitting until the call is established, so what is the point.
>>
>> > But, when I saw the chart below, the only words in my mind is ,"OMG,
>> > the SIP is never SI(m)P(le) again!"
>>
>> Where have you been? SIP hasn't been simple since early in the century.
>>
>> Thanks,
>> Paul
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Eric wang]

HI Shinji,

I noticed the chart in your mail showed ,SDP4 and SDP5 both exist in
reliable response(1xx-rel). In my mind, no matter SDP5 is offer or answer,
it shouldn't be allowed.

UAC UAS
| F1 INVITE (SDP1) | <-- offer
|-------------------->|
| F2 1xx (SDP2) |
|<--------------------|
| F3 1xx (SDP3) |
|<--------------------|
| F4 1xx-rel (SDP4) | <-- answer
|<--------------------|
| F5 1xx-rel (SDP5) |
|<--------------------|
| F6 1xxl (SDP6) |
|<--------------------|
| F7 2xx INV(SDP7) |
|<--------------------|
| F8 ACK |
|-------------------->|
(PRACK transactions are not shown)

Shinji: Just you said "different SDPs(compare with the answer) can
exist in non-reliable response and final 2xx response".
Eric: I mean different SDPs may appear in non-reliable response,because
some SERVER may use 1xx with SDP
to play some announcements before foward a call, eg a charge server "HI guy,
you have only 5 minute to communicate",
or, a redirect server "the call is forwarding"! If the server want to use
reliable response, it must use re-INVITE after
the call is established ,for the SERVER cannot send the SDP in final
response from UE-B to UE-A.But if the SERVER
use non-reliable response, the SERVER may use final response to carry SDP.

UE-A SERVER UE-B
| - INVITE -> | |
| <-18x-------- | |
| | -INVITE ->|
| | |


BR

Eric

[Eric wang]

HI Shinji,

I noticed the chart in your mail showed ,SDP4 and SDP5 both exist in
reliable response(1xx-rel). In my mind, no matter SDP5 is offer or answer,
it shouldn't be allowed.

UAC UAS
| F1 INVITE (SDP1) | <-- offer
|-------------------->|
| F2 1xx (SDP2) |
|<--------------------|
| F3 1xx (SDP3) |
|<--------------------|
| F4 1xx-rel (SDP4) | <-- answer
|<--------------------|
| F5 1xx-rel (SDP5) |
|<--------------------|
| F6 1xxl (SDP6) |
|<--------------------|
| F7 2xx INV(SDP7) |
|<--------------------|
| F8 ACK |
|-------------------->|
(PRACK transactions are not shown)

Shinji: Just you said "different SDPs(compare with the answer) can


exist in non-reliable response and final 2xx response".

Eric: I mean different SDPs may appear in non-reliable response,because
some SERVER may use 1xx with SDP
to play some announcements before foward a call, eg a charge server "HI guy,
you have only 5 minute to communicate",
or, a redirect server "the call is forwarding"! If the server want to use
reliable response, it must use re-INVITE after
the call is established ,for the SERVER cannot send the SDP in final
response from UE-B to UE-A.But if the SERVER
use non-reliable response, the SERVER may use final response to carry SDP.

UE-A SERVER UE-B
| - INVITE -> | |
| <-18x-------- | |
| | -INVITE ->|
| | |


BR

Eric

[OKUMURA Shinji]

Hi Eric,

Eric wang <***@gmail.com>
Thu, 15 Apr 2010 17:40:17 +0800
>HI Shinji,
>
>I noticed the chart in your mail showed ,SDP4 and SDP5 both
>exist in reliable response(1xx-rel). In my mind, no matter
>SDP5 is offer or answer, it shouldn't be allowed.

Agree. And I have said the same thing in the original mail.
You have misunderstood my mail.

> UAC UAS
> | F1 INVITE (SDP1) | <-- offer
> |-------------------->|
> | F2 1xx (SDP2) |
> |<--------------------|
> | F3 1xx (SDP3) |
> |<--------------------|
> | F4 1xx-rel (SDP4) | <-- answer
> |<--------------------|
> | F5 1xx-rel (SDP5) |
> |<--------------------|
> | F6 1xxl (SDP6) |
> |<--------------------|
> | F7 2xx INV(SDP7) |
> |<--------------------|
> | F8 ACK |
> |-------------------->|
> (PRACK transactions are not shown)
>
>Shinji:
> Just you said "different SDPs(compare with the answer) can
> exist in non-reliable response and final 2xx response".
>
>Eric:
> I mean different SDPs may appear in non-reliable response,
> because some SERVER may use 1xx with SDP
> to play some announcements before foward a call, eg a charge
> server "HI guy, you have only 5 minute to communicate",
> or, a redirect server "the call is forwarding"! If the server
> want to use reliable response, it must use re-INVITE after
> the call is established ,for the SERVER cannot send the SDP
> in final response from UE-B to UE-A.But if the SERVER
> use non-reliable response, the SERVER may use final response
> to carry SDP.
>
> UE-A SERVER UE-B
> | - INVITE -> | |
> | <-18x------ | |
> | | -INVITE -> |
> | | |

IMO "SERVER" in your chart is B2BUA.
Because it sends an original 18x not depended on UE-B.

This situation is just a fork.

Regards,
Shinji

>BR
>
>Eric
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Eric wang]

On Fri, Apr 16, 2010 at 11:39 AM, OKUMURA Shinji <
***@softfront.jp> wrote:

> Hi Eric,
>
> Eric wang <***@gmail.com>
> Thu, 15 Apr 2010 17:40:17 +0800
> >HI Shinji,
> >
> >I noticed the chart in your mail showed ,SDP4 and SDP5 both
> >exist in reliable response(1xx-rel). In my mind, no matter
> >SDP5 is offer or answer, it shouldn't be allowed.
>
> Agree. And I have said the same thing in the original mail.
> You have misunderstood my mail.
>

Sorry for that ,I was shocked by your chart:)


>
> > UAC UAS
> > | F1 INVITE (SDP1) | <-- offer
> > |-------------------->|
> > | F2 1xx (SDP2) |
> > |<--------------------|
> > | F3 1xx (SDP3) |
> > |<--------------------|
> > | F4 1xx-rel (SDP4) | <-- answer
> > |<--------------------|
> > | F5 1xx-rel (SDP5) |
> > |<--------------------|
> > | F6 1xxl (SDP6) |
> > |<--------------------|
> > | F7 2xx INV(SDP7) |
> > |<--------------------|
> > | F8 ACK |
> > |-------------------->|
> > (PRACK transactions are not shown)
> >
> >Shinji:
> > Just you said "different SDPs(compare with the answer) can
> > exist in non-reliable response and final 2xx response".
> >
> >Eric:
> > I mean different SDPs may appear in non-reliable response,
> > because some SERVER may use 1xx with SDP
> > to play some announcements before foward a call, eg a charge
> > server "HI guy, you have only 5 minute to communicate",
> > or, a redirect server "the call is forwarding"! If the server
> > want to use reliable response, it must use re-INVITE after
> > the call is established ,for the SERVER cannot send the SDP
> > in final response from UE-B to UE-A.But if the SERVER
> > use non-reliable response, the SERVER may use final response
> > to carry SDP.
> >
> > UE-A SERVER UE-B
> > | - INVITE -> | |
> > | <-18x------ | |
> > | | -INVITE -> |
> > | | |
>
> IMO "SERVER" in your chart is B2BUA.
> Because it sends an original 18x not depended on UE-B.
>
Yes!

BR
Eric




> This situation is just a fork.


> Regards,
> Shinji
>
> >BR
> >
> >Eric
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org for new developments of core SIP
>

[Eric wang]

Hi Paul,
I have been in the world for many years =_=!!!!
We shouldn't make complicated rules because the system has already been
complicated.

In my opinion, the offer/answer model works well if responses are
reliable.
If we allow several reliable 18x with SDP, what happen if 18x is after
UPDATEs.There must be some rules saying "NO".I prefer several reliable 18xs
with SDP appear only in fork.

BR
Eric



ÔÚ 2010Äê4ÔÂ14ÈÕ ÏÂÎç10:02£¬Paul Kyzivat <***@cisco.com>ÐŽµÀ£º

>
>
> Eric wang wrote:
> > Hi all,
> >
> > I believe that SDP in non-reliable response is useful. eg, if the
> > UAS wants to send a tone to UAC while the UAC doesn't support 100rel,
> > the UAS can use a non-reliable response with the tone SDP.
> > So I believe different SDPs(compare with the answer) can exist in
> > non-reliable response and final 2xx response.
>
> IMO this makes no sense. For one thing, the UAC is instructed to accept
> the first and ignore the rest, so sending differing values will have no
> utility. For another, this only affects where the UAS will receive media
> - it can have no effect on where the UAC receives media. Generally the
> UAC isn't transmitting until the call is established, so what is the point.
>
> > But, when I saw the chart below, the only words in my mind is ,"OMG,
> > the SIP is never SI(m)P(le) again!"
>
> Where have you been? SIP hasn't been simple since early in the century.
>
> Thanks,
> Paul
>
>
> > 2010/4/14 OKUMURA Shinji <***@softfront.jp
> > <mailto:***@softfront.jp>>
> >
> > Hi Gao,
> >
> > In the following case,
> >
> > UAC UAS
> > | F1 INVITE (SDP1) | <-- offer
> > |-------------------->|
> > | F2 1xx (SDP2) |
> > |<--------------------|
> > | F3 1xx (SDP3) |
> > |<--------------------|
> > | F4 1xx-rel (SDP4) | <-- answer
> > |<--------------------|
> > | F5 1xx-rel (SDP5) |
> > |<--------------------|
> > | F6 1xxl (SDP6) |
> > |<--------------------|
> > | F7 2xx INV(SDP7) |
> > |<--------------------|
> > | F8 ACK |
> > |-------------------->|
> > (PRACK transactions are not shown)
> >
> > I tried to arrange the rules.
> > (small letters mean informational)
> >
> > UAC,
> > (Rc1) MUST treat SDP2 as the answer.
> > (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> > (Rc3) may treat SDP3 as the answer.
> > (Rc4) should treat SDP4 as the answer and confirm the current O/A
> > status by sending new offer.
> >
> > UAS,
> > (Rs1) should not send SDP5, SDP6 and SDP7.
> > (Rs2) must not send SDP2 and SDP3 if these are not the same as
> SDP4.
> >
> > Rc3 and Rc4 are new added descriptions.
> > Rs1 and Rs2 are current descriptions in this draft.
> >
> > I think "MUST NOT" is suitable for (Rs1).
> > Because RFC3261 says
> > Once the UAS has sent or received an answer to the initial
> > offer, it MUST NOT generate subsequent offers in any responses
> > to the initial INVITE. This means that a UAS based on this
> > specification alone can never generate subsequent offers until
> > completion of the initial transaction.
> >
> > SDP5 and SDP7 are regarded as "subsequent offers".
> >
> > What do you think of these?
> >
> > Regards,
> > Shinji
> >
> > ***@zte.com.cn <mailto:***@zte.com.cn>
> > Mon, 12 Apr 2010 11:37:09 +0800
> > >Hi Shinji,
> > >
> > >Please see inlines.
> > >
> > >Thanks,
> > >
> > >Gao
> > >
> > >sipping-***@ietf.org <mailto:sipping-***@ietf.org> ÐŽÓÚ
> > 2010-04-12 10:55:47:
> > >
> > >> Hi Gao,
> > >>
> > >> The clarifications for the section 13.2.1 of RFC 3261 is
> > >> one of the major purposes in this draft.
> > >>
> > >> In the section 3.1 of this draft,
> > >> | 3.1. Offer/Answer for the INVITE method with 100rel
> extension
> > >> | (snip) All the session
> > >> | descriptions in the unreliable responses to the INVITE
> > request must
> > >> | be identical to the answer which is included in the reliable
> > >> | response.
> > >>
> > >> Do you doubt this clarification?
> > >> In my understanding, this has already reached the consensus in
> WG.
> > >
> > >[Gao] I am not want to *challenge* the consensus we have reached
> > in WG.
> > >But as this draft is aims for clarification, not for normative
> > correction,
> > >I have no way to convince the *UAS*.
> > >
> > >>
> > >> I'm confused.
> > >> Do you have something a concrete proposal?
> > >
> > >[Gao] I think the original illegibility is from RFC3261. So, I
> sended
> > >mails about it in SIPCore ML:
> > >
> > >http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
> > >http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html
> > >
> > >To be honest, I think there are two options here:
> > >1. Forbid different SDP(compare with the answer) before the answer
> > >normatively.
> > >2. Allowing different SDP(compare with the answer) before the
> answer
> > >normatively.
> > >
> > >>
> > >> Just to be sure, this draft is not a normative document but
> > >> an informational one as you no doubt know.
> > >
> > >[Gao] Sure, I know it is informative.
> > >
> > >>
> > >> Regards,
> > >> Shinji
> > >>
> > >> ***@zte.com.cn <mailto:***@zte.com.cn>
> > >> Fri, 9 Apr 2010 16:50:12 +0800
> > >> >Hi Shinji,
> > >> >
> > >> >Thanks firstly.
> > >> >
> > >> >But the UAS do not think it throws the problem. RFC3261 said
> > UAS may send
> > >> >the same SDP before the answer, but there is not normative
> > words of to
> > >> >forbid the different SDPs.
> > >> >
> > >> >And if the equipment has been in the network, unless we using
> > the evident
> > >> >standard, we has no way to request their correction.
> > >> >
> > >> >Gao
> > >> >
> > >> >OKUMURA Shinji <***@softfront.jp
> > <mailto:***@softfront.jp>>
> > >> >·¢ŒþÈË: sipping-***@ietf.org <mailto:sipping-***@ietf.org
> >
> > >> >2010-04-09 16:30
> > >> >
> > >> >ÊÕŒþÈË
> > >> >***@ietf.org <mailto:***@ietf.org>
> > >> >³­ËÍ
> > >> >
> > >> >Ö÷Ìâ
> > >> >Re: [Sipping] About offeranswer draft:
> > >> >
> > >> >Hi Gao,
> > >> >
> > >> >In this case it is no doubt the UAS is a cause of the problem.
> > >> >All you have to do is say "Your UAS is against the rules".
> > >> >You will surely win the fight.
> > >> >
> > >> >Regards,
> > >> >Shinji
> > >> >
> > >> >***@zte.com.cn <mailto:***@zte.com.cn>
> > >> >Fri, 9 Apr 2010 15:25:58 +0800
> > >> >>Hi Shinji,
> > >> >>
> > >> >>By myself, I am OK with the three ways. But if there's no
> > normative
> > >> >>definition here, there would be some interworking fight for
> > this issue.
> > >> >>
> > >> >>Thanks,
> > >> >>
> > >> >>Gao
> > >> >>
> > >> >>OKUMURA Shinji <***@softfront.jp
> > <mailto:***@softfront.jp>>
> > >> >>·¢ŒþÈË: sipping-***@ietf.org
> > <mailto:sipping-***@ietf.org>
> > >> >>2010-04-09 14:23
> > >> >>
> > >> >>ÊÕŒþÈË
> > >> >>***@ietf.org <mailto:***@ietf.org>
> > >> >>³­ËÍ
> > >> >>
> > >> >>Ö÷Ìâ
> > >> >>Re: [Sipping] About offeranswer draft:
> > >> >>
> > >> >>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
> > >> >>
> > >> >>***@zte.com.cn <mailto:***@zte.com.cn>
> > >> >>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
> > earlymedia 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 <***@softfront.jp
> > <mailto:***@softfront.jp>>
> > >> >>>·¢ŒþÈË: sipping-***@ietf.org
> > <mailto:sipping-***@ietf.org>
> > >> >>>2010-04-09 10:13
> > >> >>>
> > >> >>>ÊÕŒþÈË
> > >> >>>***@ietf.org <mailto:***@ietf.org>
> > >> >>>³­ËÍ
> > >> >>>
> > >> >>>Ö÷Ìâ
> > >> >>>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
> > >> >>>
> > >> >>>***@zte.com.cn <mailto:***@zte.com.cn>
> > >> >>>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, Ithink 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-***@cs.columbia.edu
> > <mailto:sip-***@cs.columbia.edu> for questions on current
> sip
> > Use ***@ietf.org <mailto:***@ietf.org> 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-***@cs.columbia.edu for questions on current sip
> > Use ***@ietf.org for new developments of core SIP
>

[Christer Holmberg]

Hi,

SIP used to be (m)music to my ears...

Anyway, I don't anyone has said that it is "forbidden" for a UAC to use a SDP in an unreliable 18x. But, it is not the "official" SDP answer.

And, if the UAC uses the SDP in the unreliable 18x, and the SDP in the reliable answer is then different, the UAC should consider it as a protocol error in my opinion - not do any "switching".

>We shouldn't make complicated rules because the system has already been complicated.

What is complicated in "There can be only one SDP answer per transaction, and it comes in the first reliable response of that transaction"?

>In my opinion, the offer/answer model works well if responses are reliable.
>If we allow several reliable 18x with SDP, what happen if 18x is after UPDATEs.There must be some rules >saying "NO".I prefer several reliable 18xs with SDP appear only in fork.

If the UAC sends a new offer in UPDATE, it will receive the new answer in the UPDATE 200 OK.

The 18x still belongs to the INVITE transaction, and may contain the previous SDP answer. But, since you have already received an SDP answer for the INVITE transaction, the SDP in the new 18x it has no meaning - no matter if there are UPDATE(s) or not...

Regards,

Christer






在 2010年4月14日 下午10:02，Paul Kyzivat <***@cisco.com<mailto:***@cisco.com>>写道：


Eric wang wrote:
> Hi all,
>
> I believe that SDP in non-reliable response is useful. eg, if the
> UAS wants to send a tone to UAC while the UAC doesn't support 100rel,
> the UAS can use a non-reliable response with the tone SDP.
> So I believe different SDPs(compare with the answer) can exist in
> non-reliable response and final 2xx response.

IMO this makes no sense. For one thing, the UAC is instructed to accept
the first and ignore the rest, so sending differing values will have no
utility. For another, this only affects where the UAS will receive media
- it can have no effect on where the UAC receives media. Generally the
UAC isn't transmitting until the call is established, so what is the point.

> But, when I saw the chart below, the only words in my mind is ,"OMG,
> the SIP is never SI(m)P(le) again!"

Where have you been? SIP hasn't been simple since early in the century.

Thanks,
Paul


> 2010/4/14 OKUMURA Shinji <***@softfront.jp<mailto:***@softfront.jp>
> <mailto:***@softfront.jp<mailto:***@softfront.jp>>>
>
> Hi Gao,
>
> In the following case,
>
> UAC UAS
> | F1 INVITE (SDP1) | <-- offer
> |-------------------->|
> | F2 1xx (SDP2) |
> |<--------------------|
> | F3 1xx (SDP3) |
> |<--------------------|
> | F4 1xx-rel (SDP4) | <-- answer
> |<--------------------|
> | F5 1xx-rel (SDP5) |
> |<--------------------|
> | F6 1xxl (SDP6) |
> |<--------------------|
> | F7 2xx INV(SDP7) |
> |<--------------------|
> | F8 ACK |
> |-------------------->|
> (PRACK transactions are not shown)
>
> I tried to arrange the rules.
> (small letters mean informational)
>
> UAC,
> (Rc1) MUST treat SDP2 as the answer.
> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> (Rc3) may treat SDP3 as the answer.
> (Rc4) should treat SDP4 as the answer and confirm the current O/A
> status by sending new offer.
>
> UAS,
> (Rs1) should not send SDP5, SDP6 and SDP7.
> (Rs2) must not send SDP2 and SDP3 if these are not the same as SDP4.
>
> Rc3 and Rc4 are new added descriptions.
> Rs1 and Rs2 are current descriptions in this draft.
>
> I think "MUST NOT" is suitable for (Rs1).
> Because RFC3261 says
> Once the UAS has sent or received an answer to the initial
> offer, it MUST NOT generate subsequent offers in any responses
> to the initial INVITE. This means that a UAS based on this
> specification alone can never generate subsequent offers until
> completion of the initial transaction.
>
> SDP5 and SDP7 are regarded as "subsequent offers".
>
> What do you think of these?
>
> Regards,
> Shinji
>
> ***@zte.com.cn<mailto:***@zte.com.cn> <mailto:***@zte.com.cn<mailto:***@zte.com.cn>>
> Mon, 12 Apr 2010 11:37:09 +0800
> >Hi Shinji,
> >
> >Please see inlines.
> >
> >Thanks,
> >
> >Gao
> >
> >sipping-***@ietf.org<mailto:sipping-***@ietf.org> <mailto:sipping-***@ietf.org<mailto:sipping-***@ietf.org>> 写于
> 2010-04-12 10:55:47:
> >
> >> Hi Gao,
> >>
> >> The clarifications for the section 13.2.1 of RFC 3261 is
> >> one of the major purposes in this draft.
> >>
> >> In the section 3.1 of this draft,
> >> | 3.1. Offer/Answer for the INVITE method with 100rel extension
> >> | (snip) All the session
> >> | descriptions in the unreliable responses to the INVITE
> request must
> >> | be identical to the answer which is included in the reliable
> >> | response.
> >>
> >> Do you doubt this clarification?
> >> In my understanding, this has already reached the consensus in WG.
> >
> >[Gao] I am not want to *challenge* the consensus we have reached
> in WG.
> >But as this draft is aims for clarification, not for normative
> correction,
> >I have no way to convince the *UAS*.
> >
> >>
> >> I'm confused.
> >> Do you have something a concrete proposal?
> >
> >[Gao] I think the original illegibility is from RFC3261. So, I sended
> >mails about it in SIPCore ML:
> >
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html
> >
> >To be honest, I think there are two options here:
> >1. Forbid different SDP(compare with the answer) before the answer
> >normatively.
> >2. Allowing different SDP(compare with the answer) before the answer
> >normatively.
> >
> >>
> >> Just to be sure, this draft is not a normative document but
> >> an informational one as you no doubt know.
> >
> >[Gao] Sure, I know it is informative.
> >
> >>
> >> Regards,
> >> Shinji
> >>
> >> ***@zte.com.cn<mailto:***@zte.com.cn> <mailto:***@zte.com.cn<mailto:***@zte.com.cn>>
> >> Fri, 9 Apr 2010 16:50:12 +0800
> >> >Hi Shinji,
> >> >
> >> >Thanks firstly.
> >> >
> >> >But the UAS do not think it throws the problem. RFC3261 said
> UAS may send
> >> >the same SDP before the answer, but there is not normative
> words of to
> >> >forbid the different SDPs.
> >> >
> >> >And if the equipment has been in the network, unless we using
> the evident
> >> >standard, we has no way to request their correction.
> >> >
> >> >Gao
> >> >
> >> >OKUMURA Shinji <***@softfront.jp<mailto:***@softfront.jp>
> <mailto:***@softfront.jp<mailto:***@softfront.jp>>>
> >> >发件人: sipping-***@ietf.org<mailto:sipping-***@ietf.org> <mailto:sipping-***@ietf.org<mailto:sipping-***@ietf.org>>
> >> >2010-04-09 16:30
> >> >
> >> >收件人
> >> >***@ietf.org<mailto:***@ietf.org> <mailto:***@ietf.org<mailto:***@ietf.org>>
> >> >抄送
> >> >
> >> >主题
> >> >Re: [Sipping] About offeranswer draft:
> >> >
> >> >Hi Gao,
> >> >
> >> >In this case it is no doubt the UAS is a cause of the problem.
> >> >All you have to do is say "Your UAS is against the rules".
> >> >You will surely win the fight.
> >> >
> >> >Regards,
> >> >Shinji
> >> >
> >> >***@zte.com.cn<mailto:***@zte.com.cn> <mailto:***@zte.com.cn<mailto:***@zte.com.cn>>
> >> >Fri, 9 Apr 2010 15:25:58 +0800
> >> >>Hi Shinji,
> >> >>
> >> >>By myself, I am OK with the three ways. But if there's no
> normative
> >> >>definition here, there would be some interworking fight for
> this issue.
> >> >>
> >> >>Thanks,
> >> >>
> >> >>Gao
> >> >>
> >> >>OKUMURA Shinji <***@softfront.jp<mailto:***@softfront.jp>
> <mailto:***@softfront.jp<mailto:***@softfront.jp>>>
> >> >>发件人: sipping-***@ietf.org<mailto:sipping-***@ietf.org>
> <mailto:sipping-***@ietf.org<mailto:sipping-***@ietf.org>>
> >> >>2010-04-09 14:23
> >> >>
> >> >>收件人
> >> >>***@ietf.org<mailto:***@ietf.org> <mailto:***@ietf.org<mailto:***@ietf.org>>
> >> >>抄送
> >> >>
> >> >>主题
> >> >>Re: [Sipping] About offeranswer draft:
> >> >>
> >> >>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
> >> >>
> >> >>***@zte.com.cn<mailto:***@zte.com.cn> <mailto:***@zte.com.cn<mailto:***@zte.com.cn>>
> >> >>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
> earlymedia 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 <***@softfront.jp<mailto:***@softfront.jp>
> <mailto:***@softfront.jp<mailto:***@softfront.jp>>>
> >> >>>发件人: sipping-***@ietf.org<mailto:sipping-***@ietf.org>
> <mailto:sipping-***@ietf.org<mailto:sipping-***@ietf.org>>
> >> >>>2010-04-09 10:13
> >> >>>
> >> >>>收件人
> >> >>>***@ietf.org<mailto:***@ietf.org> <mailto:***@ietf.org<mailto:***@ietf.org>>
> >> >>>抄送
> >> >>>
> >> >>>主题
> >> >>>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
> >> >>>
> >> >>>***@zte.com.cn<mailto:***@zte.com.cn> <mailto:***@zte.com.cn<mailto:***@zte.com.cn>>
> >> >>>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, Ithink 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-***@cs.columbia.edu<mailto:sip-***@cs.columbia.edu>
> <mailto:sip-***@cs.columbia.edu<mailto:sip-***@cs.columbia.edu>> for questions on current sip
> Use ***@ietf.org<mailto:***@ietf.org> <mailto:***@ietf.org<mailto:***@ietf.org>> 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-***@cs.columbia.edu<mailto:sip-***@cs.columbia.edu> for questions on current sip
> Use ***@ietf.org<mailto:***@ietf.org> 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-***@cs.columbia.edu for questions on curre

[DRAGE, Keith (Keith)]

> Anyway, I don't anyone has said that it is "forbidden" for a
> UAC to use a SDP in an unreliable 18x. But, it is not the
> "official" SDP answer.
>

We write specifications that indicate what you are meant to do, not what you are not meant to do.

If someone tries to write different SDP in a subsequent response, then that is a proprietary extension that has not been signalled by any of the compatibility mechanisms, and people should expect it not to work.

We do not change the standard to fix those sort of problems.

Keith

> -----Original Message-----
> From: sipping-***@ietf.org
> [mailto:sipping-***@ietf.org] On Behalf Of Christer Holmberg
> Sent: Thursday, April 15, 2010 6:26 PM
> To: Eric wang; Paul Kyzivat
> Cc: OKUMURA Shinji; ***@ietf.org
> Subject: Re: [Sipping] About offeranswer draft:
>
> Hi,
>
> SIP used to be (m)music to my ears...
>
> Anyway, I don't anyone has said that it is "forbidden" for a
> UAC to use a SDP in an unreliable 18x. But, it is not the
> "official" SDP answer.
>
> And, if the UAC uses the SDP in the unreliable 18x, and the
> SDP in the reliable answer is then different, the UAC should
> consider it as a protocol error in my opinion - not do any
> "switching".
>
> >We shouldn't make complicated rules because the system has
> already been complicated.
>
> What is complicated in "There can be only one SDP answer per
> transaction, and it comes in the first reliable response of
> that transaction"?
>
> >In my opinion, the offer/answer model works well if
> responses are reliable.
> >If we allow several reliable 18x with SDP, what happen if
> 18x is after UPDATEs.There must be some rules >saying "NO".I
> prefer several reliable 18xs with SDP appear only in fork.
>
> If the UAC sends a new offer in UPDATE, it will receive the
> new answer in the UPDATE 200 OK.
>
> The 18x still belongs to the INVITE transaction, and may
> contain the previous SDP answer. But, since you have already
> received an SDP answer for the INVITE transaction, the SDP in
> the new 18x it has no meaning - no matter if there are
> UPDATE(s) or not...
>
> Regards,
>
> Christer
>
>
>
>
>
>
> 在 2010年4月14日 下午10:02，Paul Kyzivat
> <***@cisco.com<mailto:***@cisco.com>>写道：
>
>
> Eric wang wrote:
> > Hi all,
> >
> > I believe that SDP in non-reliable response is useful.
> eg, if the
> > UAS wants to send a tone to UAC while the UAC doesn't
> support 100rel,
> > the UAS can use a non-reliable response with the tone SDP.
> > So I believe different SDPs(compare with the answer) can exist in
> > non-reliable response and final 2xx response.
>
> IMO this makes no sense. For one thing, the UAC is instructed
> to accept the first and ignore the rest, so sending differing
> values will have no utility. For another, this only affects
> where the UAS will receive media
> - it can have no effect on where the UAC receives media.
> Generally the UAC isn't transmitting until the call is
> established, so what is the point.
>
> > But, when I saw the chart below, the only words in my mind is
> > ,"OMG, the SIP is never SI(m)P(le) again!"
>
> Where have you been? SIP hasn't been simple since early in
> the century.
>
> Thanks,
> Paul
>
>
> > 2010/4/14 OKUMURA Shinji
> > <***@softfront.jp<mailto:***@softfront.jp>
> >
> <mailto:***@softfront.jp<mailto:***@softfront.jp
> > >>>
> >
> > Hi Gao,
> >
> > In the following case,
> >
> > UAC UAS
> > | F1 INVITE (SDP1) | <-- offer
> > |-------------------->|
> > | F2 1xx (SDP2) |
> > |<--------------------|
> > | F3 1xx (SDP3) |
> > |<--------------------|
> > | F4 1xx-rel (SDP4) | <-- answer
> > |<--------------------|
> > | F5 1xx-rel (SDP5) |
> > |<--------------------|
> > | F6 1xxl (SDP6) |
> > |<--------------------|
> > | F7 2xx INV(SDP7) |
> > |<--------------------|
> > | F8 ACK |
> > |-------------------->|
> > (PRACK transactions are not shown)
> >
> > I tried to arrange the rules.
> > (small letters mean informational)
> >
> > UAC,
> > (Rc1) MUST treat SDP2 as the answer.
> > (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> > (Rc3) may treat SDP3 as the answer.
> > (Rc4) should treat SDP4 as the answer and confirm the
> current O/A
> > status by sending new offer.
> >
> > UAS,
> > (Rs1) should not send SDP5, SDP6 and SDP7.
> > (Rs2) must not send SDP2 and SDP3 if these are not
> the same as SDP4.
> >
> > Rc3 and Rc4 are new added descriptions.
> > Rs1 and Rs2 are current descriptions in this draft.
> >
> > I think "MUST NOT" is suitable for (Rs1).
> > Because RFC3261 says
> > Once the UAS has sent or received an answer to
> the initial
> > offer, it MUST NOT generate subsequent offers in
> any responses
> > to the initial INVITE. This means that a UAS
> based on this
> > specification alone can never generate
> subsequent offers until
> > completion of the initial transaction.
> >
> > SDP5 and SDP7 are regarded as "subsequent offers".
> >
> > What do you think of these?
> >
> > Regards,
> > Shinji
> >
> > ***@zte.com.cn<mailto:***@zte.com.cn>
> <mailto:***@zte.com.cn<mailto:***@zte.com.cn>>
> > Mon, 12 Apr 2010 11:37:09 +0800
> > >Hi Shinji,
> > >
> > >Please see inlines.
> > >
> > >Thanks,
> > >
> > >Gao
> > >
> >
> >sipping-***@ietf.org<mailto:sipping-***@ietf.org>
> <mailto:sipping-***@ietf.org<mailto:sipping-***@ietf.org>> 写于
> > 2010-04-12 10:55:47:
> > >
> > >> Hi Gao,
> > >>
> > >> The clarifications for the section 13.2.1 of RFC 3261 is
> > >> one of the major purposes in this draft.
> > >>
> > >> In the section 3.1 of this draft,
> > >> | 3.1. Offer/Answer for the INVITE method with
> 100rel extension
> > >> | (snip) All the session
> > >> | descriptions in the unreliable responses to the INVITE
> > request must
> > >> | be identical to the answer which is included in
> the reliable
> > >> | response.
> > >>
> > >> Do you doubt this clarification?
> > >> In my understanding, this has already reached the
> consensus in WG.
> > >
> > >[Gao] I am not want to *challenge* the consensus we
> have reached
> > in WG.
> > >But as this draft is aims for clarification, not for normative
> > correction,
> > >I have no way to convince the *UAS*.
> > >
> > >>
> > >> I'm confused.
> > >> Do you have something a concrete proposal?
> > >
> > >[Gao] I think the original illegibility is from
> RFC3261. So, I sended
> > >mails about it in SIPCore ML:
> > >
> >
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
> >
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html
> > >
> > >To be honest, I think there are two options here:
> > >1. Forbid different SDP(compare with the answer)
> before the answer
> > >normatively.
> > >2. Allowing different SDP(compare with the answer)
> before the answer
> > >normatively.
> > >
> > >>
> > >> Just to be sure, this draft is not a normative document but
> > >> an informational one as you no doubt know.
> > >
> > >[Gao] Sure, I know it is informative.
> > >
> > >>
> > >> Regards,
> > >> Shinji
> > >>
> > >> ***@zte.com.cn<mailto:***@zte.com.cn>
> <mailto:***@zte.com.cn<mailto:***@zte.com.cn>>
> > >> Fri, 9 Apr 2010 16:50:12 +0800
> > >> >Hi Shinji,
> > >> >
> > >> >Thanks firstly.
> > >> >
> > >> >But the UAS do not think it throws the problem.
> RFC3261 said
> > UAS may send
> > >> >the same SDP before the answer, but there is not normative
> > words of to
> > >> >forbid the different SDPs.
> > >> >
> > >> >And if the equipment has been in the network,
> unless we using
> > the evident
> > >> >standard, we has no way to request their correction.
> > >> >
> > >> >Gao
> > >> >
> > >> >OKUMURA Shinji
> <***@softfront.jp<mailto:***@softfront.jp>
> >
> <mailto:***@softfront.jp<mailto:***@soft
> front.jp>>>
> > >> >发件人:
> sipping-***@ietf.org<mailto:sipping-***@ietf.org>
> <mailto:sipping-***@ietf.org<mailto:sipping-***@ietf.org>>
> > >> >2010-04-09 16:30
> > >> >
> > >> >收件人
> > >> >***@ietf.org<mailto:***@ietf.org>
> <mailto:***@ietf.org<mailto:***@ietf.org>>
> > >> >抄送
> > >> >
> > >> >主题
> > >> >Re: [Sipping] About offeranswer draft:
> > >> >
> > >> >Hi Gao,
> > >> >
> > >> >In this case it is no doubt the UAS is a cause of
> the problem.
> > >> >All you have to do is say "Your UAS is against the rules".
> > >> >You will surely win the fight.
> > >> >
> > >> >Regards,
> > >> >Shinji
> > >> >
> > >> >***@zte.com.cn<mailto:***@zte.com.cn>
> <mailto:***@zte.com.cn<mailto:***@zte.com.cn>>
> > >> >Fri, 9 Apr 2010 15:25:58 +0800
> > >> >>Hi Shinji,
> > >> >>
> > >> >>By myself, I am OK with the three ways. But if there's no
> > normative
> > >> >>definition here, there would be some interworking
> fight for
> > this issue.
> > >> >>
> > >> >>Thanks,
> > >> >>
> > >> >>Gao
> > >> >>
> > >> >>OKUMURA Shinji
> <***@softfront.jp<mailto:***@softfront.jp>
> >
> <mailto:***@softfront.jp<mailto:***@soft
> front.jp>>>
> > >> >>发件人:
> sipping-***@ietf.org<mailto:sipping-***@ietf.org>
> >
> <mailto:sipping-***@ietf.org<mailto:sipping-***@ietf.org>>
> > >> >>2010-04-09 14:23
> > >> >>
> > >> >>收件人
> > >> >>***@ietf.org<mailto:***@ietf.org>
> <mailto:***@ietf.org<mailto:***@ietf.org>>
> > >> >>抄送
> > >> >>
> > >> >>主题
> > >> >>Re: [Sipping] About offeranswer draft:
> > >> >>
> > >> >>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
> > >> >>
> > >> >>***@zte.com.cn<mailto:***@zte.com.cn>
> <mailto:***@zte.com.cn<mailto:***@zte.com.cn>>
> > >> >>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
> > earlymedia 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
> <***@softfront.jp<mailto:***@softfront.jp>
> >
> <mailto:***@softfront.jp<mailto:***@soft
> front.jp>>>
> > >> >>>发件人:
> sipping-***@ietf.org<mailto:sipping-***@ietf.org>
> >
> <mailto:sipping-***@ietf.org<mailto:sipping-***@ietf.org>>
> > >> >>>2010-04-09 10:13
> > >> >>>
> > >> >>>收件人
> > >> >>>***@ietf.org<mailto:***@ietf.org>
> <mailto:***@ietf.org<mailto:***@ietf.org>>
> > >> >>>抄送
> > >> >>>
> > >> >>>主题
> > >> >>>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
> > >> >>>
> > >>
> >>>***@zte.com.cn<mailto:***@zte.com.cn>
> <mailto:***@zte.com.cn<mailto:***@zte.com.cn>>
> > >> >>>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, Ithink 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-***@cs.columbia.edu<mailto:sip-***@cs.co
> lumbia.edu>
> >
> <mailto:sip-***@cs.columbia.edu<mailto:sip-implemento
> ***@cs.columbia.edu>> for questions on current sip
> > Use ***@ietf.org<mailto:***@ietf.org>
> > <mailto:***@ietf.org<mailto:***@ietf.org>> 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-***@cs.columbia.edu<mailto:sip-***@cs.columbia.e
> > du> for questions on current sip Use
> ***@ietf.org<mailto:***@ietf.org>
> > 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-***@cs.columbia.edu for questions on current
> sip Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new dev

[Christer Holmberg]

Hi,


>>SIP used to be (m)music to my ears...
>>
>>Anyway, I don't anyone has said that it is "forbidden" for a UAC to use a SDP in an unreliable 18x. But, it is not the "official" SDP answer.
>>
>>And, if the UAC uses the SDP in the unreliable 18x, and the SDP in the reliable answer is then different, the UAC should consider it as a protocol error in my opinion - not do any "switching".
>
>
>
>I think UAC should consider SDP in reliable response as the correct one and listen to it.

Yes, and I think that is what at least me and Paul have been trying to say. But, after you've received the answer in one reliable answer, it can't be updated in another reliable answer.


>I don't konw why unreliable 18x with SDP be considered as answer if received, I will be appreciate if someone tell my why.

It will NOT be considered as answer. Sometimes we talk about it as a "preview of the answer". Whatever the UAC does with it is unspecified (unless you use ICE, where the unreliable SDP actually IS used - but it is still not considered as answer).


>>We shouldn't make complicated rules because the system has already been complicated.
>
>What is complicated in "There can be only one SDP answer per transaction, and it comes in the first reliable response of that transaction"?
>
>I mean, It's complicated if SDPs in reliable responses should be ingored(treated as neither offer nor answer), because UAC has already received answer SDP in either reliable or unreliable response.
>I support no SDP in reliable responses should be ignored, we should trust *reliable*.

I agree.

But, still, according to the rules the SDPs in the unreliable and reliable responses have to be the same.


>>>>In my opinion, the offer/answer model works well if responses are reliable.
>>>>If we allow several reliable 18x with SDP, what happen if 18x is after UPDATEs.There must be some rules >saying "NO".I prefer several reliable 18xs with SDP appear only in fork.
>>If the UAC sends a new offer in UPDATE, it will receive the new answer in the UPDATE 200 OK.
>
>Yes!
>
>The 18x still belongs to the INVITE transaction, and may contain the previous SDP answer. But, since you have already received an SDP answer for the INVITE transaction, the SDP in the new 18x it has no meaning - no matter
>if there are UPDATE(s) or not...
>
>The meaningless SDP would make mechanism harder to implementation.

I don't understand how it would make anything harder. Once you've received an SDP answer in a reliable response, you simply don't care about the SDPs in the additional responses...


Maybe we can recommend that, once the UAS has sent the SDP answer in a reliable response, it should not include it in additional responses for the same transaction. But, the UAC still has to be able to handle cases where the additional responses do contain SDP.

Regards,

Christer







在 2010年4月14日 下午10:02，Paul Kyzivat <***@cisco.com<mailto:***@cisco.com>>写道：



Eric wang wrote:
> Hi all,
>
> I believe that SDP in non-reliable response is useful. eg, if the
> UAS wants to send a tone to UAC while the UAC doesn't support 100rel,
> the UAS can use a non-reliable response with the tone SDP.
> So I believe different SDPs(compare with the answer) can exist in
> non-reliable response and final 2xx response.

IMO this makes no sense. For one thing, the UAC is instructed to accept
the first and ignore the rest, so sending differing values will have no
utility. For another, this only affects where the UAS will receive media
- it can have no effect on where the UAC receives media. Generally the
UAC isn't transmitting until the call is established, so what is the point.

> But, when I saw the chart below, the only words in my mind is ,"OMG,
> the SIP is never SI(m)P(le) again!"

Where have you been? SIP hasn't been simple since early in the century.

Thanks,
Paul


> 2010/4/14 OKUMURA Shinji <***@softfront.jp<mailto:***@softfront.jp>

> <mailto:***@softfront.jp<mailto:***@softfront.jp>>>

>
> Hi Gao,
>
> In the following case,
>
> UAC UAS
> | F1 INVITE (SDP1) | <-- offer
> |-------------------->|
> | F2 1xx (SDP2) |
> |<--------------------|
> | F3 1xx (SDP3) |
> |<--------------------|
> | F4 1xx-rel (SDP4) | <-- answer
> |<--------------------|
> | F5 1xx-rel (SDP5) |
> |<--------------------|
> | F6 1xxl (SDP6) |
> |<--------------------|
> | F7 2xx INV(SDP7) |
> |<--------------------|
> | F8 ACK |
> |-------------------->|
> (PRACK transactions are not shown)
>
> I tried to arrange the rules.
> (small letters mean informational)
>
> UAC,
> (Rc1) MUST treat SDP2 as the answer.
> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> (Rc3) may treat SDP3 as the answer.
> (Rc4) should treat SDP4 as the answer and confirm the current O/A
> status by sending new offer.
>
> UAS,
> (Rs1) should not send SDP5, SDP6 and SDP7.
> (Rs2) must not send SDP2 and SDP3 if these are not the same as SDP4.
>
> Rc3 and Rc4 are new added descriptions.
> Rs1 and Rs2 are current descriptions in this draft.
>
> I think "MUST NOT" is suitable for (Rs1).
> Because RFC3261 says
> Once the UAS has sent or received an answer to the initial
> offer, it MUST NOT generate subsequent offers in any responses
> to the initial INVITE. This means that a UAS based on this
> specification alone can never generate subsequent offers until
> completion of the initial transaction.
>
> SDP5 and SDP7 are regarded as "subsequent offers".
>
> What do you think of these?
>
> Regards,
> Shinji
>

> ***@zte.com.cn<mailto:***@zte.com.cn> <mailto:***@zte.com.cn<mailto:***@zte.com.cn>>

> Mon, 12 Apr 2010 11:37:09 +0800
> >Hi Shinji,
> >
> >Please see inlines.
> >
> >Thanks,
> >
> >Gao
> >

> >sipping-***@ietf.org<mailto:sipping-***@ietf.org> <mailto:sipping-***@ietf.org<mailto:sipping-***@ietf.org>> 写于

> 2010-04-12 10:55:47:
> >
> >> Hi Gao,
> >>
> >> The clarifications for the section 13.2.1 of RFC 3261 is
> >> one of the major purposes in this draft.
> >>
> >> In the section 3.1 of this draft,
> >> | 3.1. Offer/Answer for the INVITE method with 100rel extension
> >> | (snip) All the session
> >> | descriptions in the unreliable responses to the INVITE
> request must
> >> | be identical to the answer which is included in the reliable
> >> | response.
> >>
> >> Do you doubt this clarification?
> >> In my understanding, this has already reached the consensus in WG.
> >
> >[Gao] I am not want to *challenge* the consensus we have reached
> in WG.
> >But as this draft is aims for clarification, not for normative
> correction,
> >I have no way to convince the *UAS*.
> >
> >>
> >> I'm confused.
> >> Do you have something a concrete proposal?
> >
> >[Gao] I think the original illegibility is from RFC3261. So, I sended
> >mails about it in SIPCore ML:
> >
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html
> >
> >To be honest, I think there are two options here:
> >1. Forbid different SDP(compare with the answer) before the answer
> >normatively.
> >2. Allowing different SDP(compare with the answer) before the answer
> >normatively.
> >
> >>
> >> Just to be sure, this draft is not a normative document but
> >> an informational one as you no doubt know.
> >
> >[Gao] Sure, I know it is informative.
> >
> >>
> >> Regards,
> >> Shinji
> >>

> >> ***@zte.com.cn<mailto:***@zte.com.cn> <mailto:***@zte.com.cn<mailto:***@zte.com.cn>>

> >> Fri, 9 Apr 2010 16:50:12 +0800
> >> >Hi Shinji,
> >> >
> >> >Thanks firstly.
> >> >
> >> >But the UAS do not think it throws the problem. RFC3261 said
> UAS may send
> >> >the same SDP before the answer, but there is not normative
> words of to
> >> >forbid the different SDPs.
> >> >
> >> >And if the equipment has been in the network, unless we using
> the evident
> >> >standard, we has no way to request their correction.
> >> >
> >> >Gao
> >> >
> >> >OKUMURA Shinji <***@softfront.jp<mailto:***@softfront.jp>

> <mailto:***@softfront.jp<mailto:***@softfront.jp>>>
> >> >发件人: sipping-***@ietf.org<mailto:sipping-***@ietf.org> <mailto:sipping-***@ietf.org<mailto:sipping-***@ietf.org>>

> >> >2010-04-09 16:30
> >> >
> >> >收件人

> >> >***@ietf.org<mailto:***@ietf.org> <mailto:***@ietf.org<mailto:***@ietf.org>>

> >> >抄送
> >> >
> >> >主题
> >> >Re: [Sipping] About offeranswer draft:
> >> >
> >> >Hi Gao,
> >> >
> >> >In this case it is no doubt the UAS is a cause of the problem.
> >> >All you have to do is say "Your UAS is against the rules".
> >> >You will surely win the fight.
> >> >
> >> >Regards,
> >> >Shinji
> >> >

> >> >***@zte.com.cn<mailto:***@zte.com.cn> <mailto:***@zte.com.cn<mailto:***@zte.com.cn>>

> >> >Fri, 9 Apr 2010 15:25:58 +0800
> >> >>Hi Shinji,
> >> >>
> >> >>By myself, I am OK with the three ways. But if there's no
> normative
> >> >>definition here, there would be some interworking fight for
> this issue.
> >> >>
> >> >>Thanks,
> >> >>
> >> >>Gao
> >> >>
> >> >>OKUMURA Shinji <***@softfront.jp<mailto:***@softfront.jp>

> <mailto:***@softfront.jp<mailto:***@softfront.jp>>>

> >> >>发件人: sipping-***@ietf.org<mailto:sipping-***@ietf.org>

> <mailto:sipping-***@ietf.org<mailto:sipping-***@ietf.org>>

> >> >>2010-04-09 14:23
> >> >>
> >> >>收件人

> >> >>***@ietf.org<mailto:***@ietf.org> <mailto:***@ietf.org<mailto:***@ietf.org>>

> >> >>抄送
> >> >>
> >> >>主题
> >> >>Re: [Sipping] About offeranswer draft:
> >> >>
> >> >>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
> >> >>

> >> >>***@zte.com.cn<mailto:***@zte.com.cn> <mailto:***@zte.com.cn<mailto:***@zte.com.cn>>

> >> >>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
> earlymedia 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 <***@softfront.jp<mailto:***@softfront.jp>

> <mailto:***@softfront.jp<mailto:***@softfront.jp>>>

> >> >>>发件人: sipping-***@ietf.org<mailto:sipping-***@ietf.org>

> <mailto:sipping-***@ietf.org<mailto:sipping-***@ietf.org>>

> >> >>>2010-04-09 10:13
> >> >>>
> >> >>>收件人

> >> >>>***@ietf.org<mailto:***@ietf.org> <mailto:***@ietf.org<mailto:***@ietf.org>>

> >> >>>抄送
> >> >>>
> >> >>>主题
> >> >>>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
> >> >>>

> >> >>>***@zte.com.cn<mailto:***@zte.com.cn> <mailto:***@zte.com.cn<mailto:***@zte.com.cn>>

> >> >>>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, Ithink 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-***@cs.columbia.edu<mailto:sip-***@cs.columbia.edu>

> <mailto:sip-***@cs.columbia.edu<mailto:sip-***@cs.columbia.edu>> for questions on current sip
> Use ***@ietf.org<mailto:***@ietf.org> <mailto:***@ietf.org<mailto:***@ietf.org>> 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-***@cs.columbia.edu<mailto:sip-***@cs.columbia.edu> for questions on current sip

> Use ***@ietf.org<mailto:***@ietf.org> 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core S

[Eric wang]

HI Christer ,




2010/4/16 Christer Holmberg <***@ericsson.com>

>
> Hi,
>
>
> >>SIP used to be (m)music to my ears...
> >>
> >>Anyway, I don't anyone has said that it is "forbidden" for a UAC to use a
> SDP in an unreliable 18x. But, it is not the "official" SDP answer.
> >>
> >>And, if the UAC uses the SDP in the unreliable 18x, and the SDP in the
> reliable answer is then different, the UAC should consider it as a protocol
> error in my opinion - not do any "switching".
> >
> >
> >
> >I think UAC should consider SDP in reliable response as the correct one
> and listen to it.
>
> Yes, and I think that is what at least me and Paul have been trying to say.
> But, after you've received the answer in one reliable answer, it can't be
> updated in another reliable answer.


Eric: Agree. And It's better another reliable answer doesn't exist.



>
> >I don't konw why unreliable 18x with SDP be considered as answer if
> received, I will be appreciate if someone tell my why.
>
> It will NOT be considered as answer. Sometimes we talk about it as a
> "preview of the answer". Whatever the UAC does with it is unspecified
> (unless you use ICE, where the unreliable SDP actually IS used - but it is
> still not considered as answer).
>

Eric: If it is a "preview of the answer", I think the negotiation should be
like precondition, not SDP in unreliable response.
I prefer the SDP in unreliable response can used for something else, eg, the
CALLED want to send CALLER a music while alerting.



>
>
> >>We shouldn't make complicated rules because the system has already been
> complicated.
> >
> >What is complicated in "There can be only one SDP answer per transaction,
> and it comes in the first reliable response of that transaction"?
> >
> >I mean, It's complicated if SDPs in reliable responses should be
> ingored(treated as neither offer nor answer), because UAC has already
> received answer SDP in either reliable or unreliable response.
> >I support no SDP in reliable responses should be ignored, we should trust
> *reliable*.
>
> I agree.
>
> But, still, according to the rules the SDPs in the unreliable and reliable
> responses have to be the same.
>

Eric: I'd be glad if you can explain why they should be the same.



>
>
> >>>>In my opinion, the offer/answer model works well if responses are
> reliable.
> >>>>If we allow several reliable 18x with SDP, what happen if 18x is after
> UPDATEs.There must be some rules >saying "NO".I prefer several reliable 18xs
> with SDP appear only in fork.
> >>If the UAC sends a new offer in UPDATE, it will receive the new answer in
> the UPDATE 200 OK.
> >
> >Yes!
> >
> >The 18x still belongs to the INVITE transaction, and may contain the
> previous SDP answer. But, since you have already received an SDP answer for
> the INVITE transaction, the SDP in the new 18x it has no meaning - no matter
> >if there are UPDATE(s) or not...
> >
> >The meaningless SDP would make mechanism harder to implementation.
>
> I don't understand how it would make anything harder. Once you've received
> an SDP answer in a reliable response, you simply don't care about the SDPs
> in the additional responses...
>

Eric: I meant harder, not cannot:)
If meaningless SDPs are allowed, as a B2BUA server, we should distinguish
the meaning SDP from meaningless, should recognize if the SDP in reliable
18x is a new offer, when this happened in a
complex service such as Call Transfer, meaningless SDPs will make the
implementation more complex.


>
>
> Maybe we can recommend that, once the UAS has sent the SDP answer in a
> reliable response, it should not include it in additional responses for the
> same transaction. But, the UAC still has to be able to handle cases where
> the additional responses do contain SDP.
>

Eric: I suppose so. Then the UAC may just return an error to UAS, I think.

BR
Eric







ÔÚ 2010Äê4ÔÂ14ÈÕ ÏÂÎç10:02£¬Paul Kyzivat <***@cisco.com<mailto:
***@cisco.com>>ÐŽµÀ£º



Eric wang wrote:
> Hi all,
>
> I believe that SDP in non-reliable response is useful.
eg, if the
> UAS wants to send a tone to UAC while the UAC doesn't
support 100rel,
> the UAS can use a non-reliable response with the tone SDP.
> So I believe different SDPs(compare with the answer) can
exist in
> non-reliable response and final 2xx response.

IMO this makes no sense. For one thing, the UAC is instructed
to accept
the first and ignore the rest, so sending differing values
will have no
utility. For another, this only affects where the UAS will
receive media
- it can have no effect on where the UAC receives media.
Generally the
UAC isn't transmitting until the call is established, so what
is the point.

> But, when I saw the chart below, the only words in my
mind is ,"OMG,
> the SIP is never SI(m)P(le) again!"

Where have you been? SIP hasn't been simple since early in
the century.

Thanks,
Paul


> 2010/4/14 OKUMURA Shinji <***@softfront.jp
<mailto:***@softfront.jp>

> <mailto:***@softfront.jp<mailto:
***@softfront.jp>>>

>
> Hi Gao,
>
> In the following case,
>
> UAC UAS
> | F1 INVITE (SDP1) | <-- offer
> |-------------------->|
> | F2 1xx (SDP2) |
> |<--------------------|
> | F3 1xx (SDP3) |
> |<--------------------|
> | F4 1xx-rel (SDP4) | <-- answer
> |<--------------------|
> | F5 1xx-rel (SDP5) |
> |<--------------------|
> | F6 1xxl (SDP6) |
> |<--------------------|
> | F7 2xx INV(SDP7) |
> |<--------------------|
> | F8 ACK |
> |-------------------->|
> (PRACK transactions are not shown)
>
> I tried to arrange the rules.
> (small letters mean informational)
>
> UAC,
> (Rc1) MUST treat SDP2 as the answer.
> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> (Rc3) may treat SDP3 as the answer.
> (Rc4) should treat SDP4 as the answer and confirm the
current O/A
> status by sending new offer.
>
> UAS,
> (Rs1) should not send SDP5, SDP6 and SDP7.
> (Rs2) must not send SDP2 and SDP3 if these are not
the same as SDP4.
>
> Rc3 and Rc4 are new added descriptions.
> Rs1 and Rs2 are current descriptions in this draft.
>
> I think "MUST NOT" is suitable for (Rs1).
> Because RFC3261 says
> Once the UAS has sent or received an answer to
the initial
> offer, it MUST NOT generate subsequent offers in
any responses
> to the initial INVITE. This means that a UAS
based on this
> specification alone can never generate
subsequent offers until
> completion of the initial transaction.
>
> SDP5 and SDP7 are regarded as "subsequent offers".
>
> What do you think of these?
>
> Regards,
> Shinji
>

> ***@zte.com.cn<mailto:***@zte.com.cn>
<mailto:***@zte.com.cn<mailto:***@zte.com.cn>>

> Mon, 12 Apr 2010 11:37:09 +0800
> >Hi Shinji,
> >
> >Please see inlines.
> >
> >Thanks,
> >
> >Gao
> >

> >sipping-***@ietf.org<mailto:
sipping-***@ietf.org> <mailto:sipping-***@ietf.org<mailto:
sipping-***@ietf.org>> ÐŽÓÚ

> 2010-04-12 10:55:47:
> >
> >> Hi Gao,
> >>
> >> The clarifications for the section 13.2.1 of RFC
3261 is
> >> one of the major purposes in this draft.
> >>
> >> In the section 3.1 of this draft,
> >> | 3.1. Offer/Answer for the INVITE method with
100rel extension
> >> | (snip) All the session
> >> | descriptions in the unreliable responses to the
INVITE
> request must
> >> | be identical to the answer which is included in
the reliable
> >> | response.
> >>
> >> Do you doubt this clarification?
> >> In my understanding, this has already reached the
consensus in WG.
> >
> >[Gao] I am not want to *challenge* the consensus we
have reached
> in WG.
> >But as this draft is aims for clarification, not for
normative
> correction,
> >I have no way to convince the *UAS*.
> >
> >>
> >> I'm confused.
> >> Do you have something a concrete proposal?
> >
> >[Gao] I think the original illegibility is from
RFC3261. So, I sended
> >mails about it in SIPCore ML:
> >
> >
http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
> >
http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html
> >
> >To be honest, I think there are two options here:
> >1. Forbid different SDP(compare with the answer)
before the answer
> >normatively.
> >2. Allowing different SDP(compare with the answer)
before the answer
> >normatively.
> >
> >>
> >> Just to be sure, this draft is not a normative
document but
> >> an informational one as you no doubt know.
> >
> >[Gao] Sure, I know it is informative.
> >
> >>
> >> Regards,
> >> Shinji
> >>

> >> ***@zte.com.cn<mailto:***@zte.com.cn>
<mailto:***@zte.com.cn<mailto:***@zte.com.cn>>

> >> Fri, 9 Apr 2010 16:50:12 +0800
> >> >Hi Shinji,
> >> >
> >> >Thanks firstly.
> >> >
> >> >But the UAS do not think it throws the problem.
RFC3261 said
> UAS may send
> >> >the same SDP before the answer, but there is not
normative
> words of to
> >> >forbid the different SDPs.
> >> >
> >> >And if the equipment has been in the network,
unless we using
> the evident
> >> >standard, we has no way to request their
correction.
> >> >
> >> >Gao
> >> >
> >> >OKUMURA Shinji <***@softfront.jp
<mailto:***@softfront.jp>

> <mailto:***@softfront.jp<mailto:
***@softfront.jp>>>
> >> >·¢ŒþÈË: sipping-***@ietf.org<mailto:
sipping-***@ietf.org> <mailto:sipping-***@ietf.org<mailto:
sipping-***@ietf.org>>

> >> >2010-04-09 16:30
> >> >
> >> >ÊÕŒþÈË

> >> >***@ietf.org<mailto:***@ietf.org> <mailto:
***@ietf.org<mailto:***@ietf.org>>

> >> >³­ËÍ
> >> >
> >> >Ö÷Ìâ
> >> >Re: [Sipping] About offeranswer draft:
> >> >
> >> >Hi Gao,
> >> >
> >> >In this case it is no doubt the UAS is a cause of
the problem.
> >> >All you have to do is say "Your UAS is against the
rules".
> >> >You will surely win the fight.
> >> >
> >> >Regards,
> >> >Shinji
> >> >

> >> >***@zte.com.cn<mailto:***@zte.com.cn>
<mailto:***@zte.com.cn<mailto:***@zte.com.cn>>

> >> >Fri, 9 Apr 2010 15:25:58 +0800
> >> >>Hi Shinji,
> >> >>
> >> >>By myself, I am OK with the three ways. But if
there's no
> normative
> >> >>definition here, there would be some interworking
fight for
> this issue.
> >> >>
> >> >>Thanks,
> >> >>
> >> >>Gao
> >> >>
> >> >>OKUMURA Shinji <***@softfront.jp
<mailto:***@softfront.jp>

> <mailto:***@softfront.jp<mailto:
***@softfront.jp>>>

> >> >>·¢ŒþÈË: sipping-***@ietf.org<mailto:
sipping-***@ietf.org>

> <mailto:sipping-***@ietf.org<mailto:
sipping-***@ietf.org>>

> >> >>2010-04-09 14:23
> >> >>
> >> >>ÊÕŒþÈË

> >> >>***@ietf.org<mailto:***@ietf.org>
<mailto:***@ietf.org<mailto:***@ietf.org>>

> >> >>³­ËÍ
> >> >>
> >> >>Ö÷Ìâ
> >> >>Re: [Sipping] About offeranswer draft:
> >> >>
> >> >>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
> >> >>

> >> >>***@zte.com.cn<mailto:***@zte.com.cn>
<mailto:***@zte.com.cn<mailto:***@zte.com.cn>>

> >> >>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
> earlymedia 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 <***@softfront.jp
<mailto:***@softfront.jp>

> <mailto:***@softfront.jp<mailto:
***@softfront.jp>>>

> >> >>>·¢ŒþÈË: sipping-***@ietf.org<mailto:
sipping-***@ietf.org>

> <mailto:sipping-***@ietf.org<mailto:
sipping-***@ietf.org>>

> >> >>>2010-04-09 10:13
> >> >>>
> >> >>>ÊÕŒþÈË

> >> >>>***@ietf.org<mailto:***@ietf.org>
<mailto:***@ietf.org<mailto:***@ietf.org>>

> >> >>>³­ËÍ
> >> >>>
> >> >>>Ö÷Ìâ
> >> >>>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
> >> >>>

> >> >>>***@zte.com.cn<mailto:***@zte.com.cn>
<mailto:***@zte.com.cn<mailto:***@zte.com.cn>>

> >> >>>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, Ithink 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-***@cs.columbia.edu<mailto:
sip-***@cs.columbia.edu>

> <mailto:sip-***@cs.columbia.edu<mailto:
sip-***@cs.columbia.edu>> for questions on current sip
> Use ***@ietf.org<mailto:***@ietf.org> <mailto:
***@ietf.org<mailto:***@ietf.org>> 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-***@cs.columbia.edu<mailto:
sip-***@cs.columbia.edu> for questions on current sip

> Use ***@ietf.org<mailto:***@ietf.org> for new developments
of core SIP

[Paul Kyzivat]

Too many messages - it would be insane to reply to them all.
This reply is generally to several of Eric's prior messages in this
thread and the discussion about them.

IIUC, eric doesn't like SDP in unreliable responses.
But such usage is still very common. There are many deployments that
don't use PRACK at all. So implementations must be prepared for this.
When reliable provisionals are *not* used, providing "a preview" (my
terminology for this) in unreliable provisionals is very valuable,
because it allows the media streams to get started sooner than if the
UAC had to wait for the 200. So the UAC has much incentive to honor the
SDP in an unreliable provisional in order to get the media going.

(The 3261 text says the UAC MUST honor the SDP in the reliable
provisional if it receives it. But if it chose not to honor it, it could
simply claim that it was lost somewhere along the way, maybe after the
network interface on its box. And who can argue?)

Even when the UAC has included Supported:100_rel in the INVITE, there is
no guarantee that the UAS supports it, or is willing to use it. So still
in this case the UAC has strong motivation to honor the SDP in an
unreliable provisional.

Support for reliable provisionals has to be consistent with all of the
above. It provides *additional* behavior options - it removes none of
the above. (Unless the UAC specifies Required:100_rel. Lets not talk
about that case now.)

A nicely behaved UAS that is intending to use reliable provisionals will
probably not ever send an unreliable provisional containing SDP. In that
case Eric will be happy. But that is not *required* behavior. Maybe it
should have been, but since it was not, it would now be harder to go
back and fix than it is to simply cope with it. So we carefully specify
what is meant if SDP is received in an unreliable provisional and then
again in a reliable provisional.

That's my take on this particular discussion.

Thanks,
Paul

Eric wang wrote:
> HI Christer ,
>
>
>
>
> 2010/4/16 Christer Holmberg <***@ericsson.com
> <mailto:***@ericsson.com>>
>
>
> Hi,
>
>
> >>SIP used to be (m)music to my ears...
> >>
> >>Anyway, I don't anyone has said that it is "forbidden" for a UAC
> to use a SDP in an unreliable 18x. But, it is not the "official" SDP
> answer.
> >>
> >>And, if the UAC uses the SDP in the unreliable 18x, and the SDP
> in the reliable answer is then different, the UAC should consider it
> as a protocol error in my opinion - not do any "switching".
> >
> >
> >
> >I think UAC should consider SDP in reliable response as the
> correct one and listen to it.
>
> Yes, and I think that is what at least me and Paul have been trying
> to say. But, after you've received the answer in one reliable
> answer, it can't be updated in another reliable answer.
>
>
> Eric: Agree. And It's better another reliable answer doesn't exist.
>
>
>
>
> >I don't konw why unreliable 18x with SDP be considered as answer
> if received, I will be appreciate if someone tell my why.
>
> It will NOT be considered as answer. Sometimes we talk about it as a
> "preview of the answer". Whatever the UAC does with it is
> unspecified (unless you use ICE, where the unreliable SDP actually
> IS used - but it is still not considered as answer).
>
>
> Eric: If it is a "preview of the answer", I think the negotiation should
> be like precondition, not SDP in unreliable response.
> I prefer the SDP in unreliable response can used for something else, eg,
> the CALLED want to send CALLER a music while alerting.
>
>
>
>
>
> >>We shouldn't make complicated rules because the system has
> already been complicated.
> >
> >What is complicated in "There can be only one SDP answer per
> transaction, and it comes in the first reliable response of that
> transaction"?
> >
> >I mean, It's complicated if SDPs in reliable responses should be
> ingored(treated as neither offer nor answer), because UAC has
> already received answer SDP in either reliable or unreliable response.
> >I support no SDP in reliable responses should be ignored, we
> should trust *reliable*.
>
> I agree.
>
> But, still, according to the rules the SDPs in the unreliable and
> reliable responses have to be the same.
>
>
> Eric: I'd be glad if you can explain why they should be the same.
>
>
>
>
>
> >>>>In my opinion, the offer/answer model works well if responses
> are reliable.
> >>>>If we allow several reliable 18x with SDP, what happen if 18x
> is after UPDATEs.There must be some rules >saying "NO".I prefer
> several reliable 18xs with SDP appear only in fork.
> >>If the UAC sends a new offer in UPDATE, it will receive the new
> answer in the UPDATE 200 OK.
> >
> >Yes!
> >
> >The 18x still belongs to the INVITE transaction, and may contain
> the previous SDP answer. But, since you have already received an SDP
> answer for the INVITE transaction, the SDP in the new 18x it has no
> meaning - no matter
> >if there are UPDATE(s) or not...
> >
> >The meaningless SDP would make mechanism harder to implementation.
>
> I don't understand how it would make anything harder. Once you've
> received an SDP answer in a reliable response, you simply don't care
> about the SDPs in the additional responses...
>
>
> Eric: I meant harder, not cannot:)
> If meaningless SDPs are allowed, as a B2BUA server, we
> should distinguish the meaning SDP from meaningless, should recognize if
> the SDP in reliable 18x is a new offer, when this happened in a
> complex service such as Call Transfer, meaningless SDPs will make the
> implementation more complex.
>
>
>
>
> Maybe we can recommend that, once the UAS has sent the SDP answer in
> a reliable response, it should not include it in additional
> responses for the same transaction. But, the UAC still has to be
> able to handle cases where the additional responses do contain SDP.
>
>
> Eric: I suppose so. Then the UAC may just return an error to UAS, I think.
>
> BR
> Eric
>
>
>
>
>
>
>
> 在 2010年4月14日 下午10:02，Paul Kyzivat
> <***@cisco.com
> <mailto:***@cisco.com><mailto:***@cisco.com
> <mailto:***@cisco.com>>>写道：
>
>
>
> Eric wang wrote:
> > Hi all,
> >
> > I believe that SDP in non-reliable response is
> useful. eg, if the
> > UAS wants to send a tone to UAC while the UAC doesn't
> support 100rel,
> > the UAS can use a non-reliable response with the tone SDP.
> > So I believe different SDPs(compare with the answer)
> can exist in
> > non-reliable response and final 2xx response.
>
> IMO this makes no sense. For one thing, the UAC is
> instructed to accept
> the first and ignore the rest, so sending differing
> values will have no
> utility. For another, this only affects where the UAS
> will receive media
> - it can have no effect on where the UAC receives media.
> Generally the
> UAC isn't transmitting until the call is established, so
> what is the point.
>
> > But, when I saw the chart below, the only words in
> my mind is ,"OMG,
> > the SIP is never SI(m)P(le) again!"
>
> Where have you been? SIP hasn't been simple since early
> in the century.
>
> Thanks,
> Paul
>
>
> > 2010/4/14 OKUMURA Shinji <***@softfront.jp
> <mailto:***@softfront.jp><mailto:***@softfront.jp
> <mailto:***@softfront.jp>>
>
> > <mailto:***@softfront.jp
> <mailto:***@softfront.jp><mailto:***@softfront.jp
> <mailto:***@softfront.jp>>>>
>
> >
> > Hi Gao,
> >
> > In the following case,
> >
> > UAC UAS
> > | F1 INVITE (SDP1) | <-- offer
> > |-------------------->|
> > | F2 1xx (SDP2) |
> > |<--------------------|
> > | F3 1xx (SDP3) |
> > |<--------------------|
> > | F4 1xx-rel (SDP4) | <-- answer
> > |<--------------------|
> > | F5 1xx-rel (SDP5) |
> > |<--------------------|
> > | F6 1xxl (SDP6) |
> > |<--------------------|
> > | F7 2xx INV(SDP7) |
> > |<--------------------|
> > | F8 ACK |
> > |-------------------->|
> > (PRACK transactions are not shown)
> >
> > I tried to arrange the rules.
> > (small letters mean informational)
> >
> > UAC,
> > (Rc1) MUST treat SDP2 as the answer.
> > (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> > (Rc3) may treat SDP3 as the answer.
> > (Rc4) should treat SDP4 as the answer and confirm
> the current O/A
> > status by sending new offer.
> >
> > UAS,
> > (Rs1) should not send SDP5, SDP6 and SDP7.
> > (Rs2) must not send SDP2 and SDP3 if these are
> not the same as SDP4.
> >
> > Rc3 and Rc4 are new added descriptions.
> > Rs1 and Rs2 are current descriptions in this draft.
> >
> > I think "MUST NOT" is suitable for (Rs1).
> > Because RFC3261 says
> > Once the UAS has sent or received an answer
> to the initial
> > offer, it MUST NOT generate subsequent
> offers in any responses
> > to the initial INVITE. This means that a
> UAS based on this
> > specification alone can never generate
> subsequent offers until
> > completion of the initial transaction.
> >
> > SDP5 and SDP7 are regarded as "subsequent offers".
> >
> > What do you think of these?
> >
> > Regards,
> > Shinji
> >
>
> > ***@zte.com.cn
> <mailto:***@zte.com.cn><mailto:***@zte.com.cn
> <mailto:***@zte.com.cn>> <mailto:***@zte.com.cn
> <mailto:***@zte.com.cn><mailto:***@zte.com.cn
> <mailto:***@zte.com.cn>>>
>
> > Mon, 12 Apr 2010 11:37:09 +0800
> > >Hi Shinji,
> > >
> > >Please see inlines.
> > >
> > >Thanks,
> > >
> > >Gao
> > >
>
> > >sipping-***@ietf.org
> <mailto:sipping-***@ietf.org><mailto:sipping-***@ietf.org
> <mailto:sipping-***@ietf.org>> <mailto:sipping-***@ietf.org
> <mailto:sipping-***@ietf.org><mailto:sipping-***@ietf.org
> <mailto:sipping-***@ietf.org>>> 写于
>
> > 2010-04-12 10:55:47:
> > >
> > >> Hi Gao,
> > >>
> > >> The clarifications for the section 13.2.1 of
> RFC 3261 is
> > >> one of the major purposes in this draft.
> > >>
> > >> In the section 3.1 of this draft,
> > >> | 3.1. Offer/Answer for the INVITE method
> with 100rel extension
> > >> | (snip) All the session
> > >> | descriptions in the unreliable responses to
> the INVITE
> > request must
> > >> | be identical to the answer which is
> included in the reliable
> > >> | response.
> > >>
> > >> Do you doubt this clarification?
> > >> In my understanding, this has already reached
> the consensus in WG.
> > >
> > >[Gao] I am not want to *challenge* the consensus
> we have reached
> > in WG.
> > >But as this draft is aims for clarification, not
> for normative
> > correction,
> > >I have no way to convince the *UAS*.
> > >
> > >>
> > >> I'm confused.
> > >> Do you have something a concrete proposal?
> > >
> > >[Gao] I think the original illegibility is from
> RFC3261. So, I sended
> > >mails about it in SIPCore ML:
> > >
> >
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
> >
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html
> > >
> > >To be honest, I think there are two options here:
> > >1. Forbid different SDP(compare with the answer)
> before the answer
> > >normatively.
> > >2. Allowing different SDP(compare with the
> answer) before the answer
> > >normatively.
> > >
> > >>
> > >> Just to be sure, this draft is not a normative
> document but
> > >> an informational one as you no doubt know.
> > >
> > >[Gao] Sure, I know it is informative.
> > >
> > >>
> > >> Regards,
> > >> Shinji
> > >>
>
> > >> ***@zte.com.cn
> <mailto:***@zte.com.cn><mailto:***@zte.com.cn
> <mailto:***@zte.com.cn>> <mailto:***@zte.com.cn
> <mailto:***@zte.com.cn><mailto:***@zte.com.cn
> <mailto:***@zte.com.cn>>>
>
> > >> Fri, 9 Apr 2010 16:50:12 +0800
> > >> >Hi Shinji,
> > >> >
> > >> >Thanks firstly.
> > >> >
> > >> >But the UAS do not think it throws the
> problem. RFC3261 said
> > UAS may send
> > >> >the same SDP before the answer, but there is
> not normative
> > words of to
> > >> >forbid the different SDPs.
> > >> >
> > >> >And if the equipment has been in the network,
> unless we using
> > the evident
> > >> >standard, we has no way to request their
> correction.
> > >> >
> > >> >Gao
> > >> >
> > >> >OKUMURA Shinji <***@softfront.jp
> <mailto:***@softfront.jp><mailto:***@softfront.jp
> <mailto:***@softfront.jp>>
>
> > <mailto:***@softfront.jp
> <mailto:***@softfront.jp><mailto:***@softfront.jp
> <mailto:***@softfront.jp>>>>
> > >> >发件人: sipping-***@ietf.org
> <mailto:sipping-***@ietf.org><mailto:sipping-***@ietf.org
> <mailto:sipping-***@ietf.org>> <mailto:sipping-***@ietf.org
> <mailto:sipping-***@ietf.org><mailto:sipping-***@ietf.org
> <mailto:sipping-***@ietf.org>>>
>
> > >> >2010-04-09 16:30
> > >> >
> > >> >收件人
>
> > >> >***@ietf.org
> <mailto:***@ietf.org><mailto:***@ietf.org
> <mailto:***@ietf.org>> <mailto:***@ietf.org
> <mailto:***@ietf.org><mailto:***@ietf.org
> <mailto:***@ietf.org>>>
>
> > >> >抄送
> > >> >
> > >> >主题
> > >> >Re: [Sipping] About offeranswer draft:
> > >> >
> > >> >Hi Gao,
> > >> >
> > >> >In this case it is no doubt the UAS is a cause
> of the problem.
> > >> >All you have to do is say "Your UAS is against
> the rules".
> > >> >You will surely win the fight.
> > >> >
> > >> >Regards,
> > >> >Shinji
> > >> >
>
> > >> >***@zte.com.cn
> <mailto:***@zte.com.cn><mailto:***@zte.com.cn
> <mailto:***@zte.com.cn>> <mailto:***@zte.com.cn
> <mailto:***@zte.com.cn><mailto:***@zte.com.cn
> <mailto:***@zte.com.cn>>>
>
> > >> >Fri, 9 Apr 2010 15:25:58 +0800
> > >> >>Hi Shinji,
> > >> >>
> > >> >>By myself, I am OK with the three ways. But
> if there's no
> > normative
> > >> >>definition here, there would be some
> interworking fight for
> > this issue.
> > >> >>
> > >> >>Thanks,
> > >> >>
> > >> >>Gao
> > >> >>
> > >> >>OKUMURA Shinji <***@softfront.jp
> <mailto:***@softfront.jp><mailto:***@softfront.jp
> <mailto:***@softfront.jp>>
>
> > <mailto:***@softfront.jp
> <mailto:***@softfront.jp><mailto:***@softfront.jp
> <mailto:***@softfront.jp>>>>
>
> > >> >>发件人: sipping-***@ietf.org
> <mailto:sipping-***@ietf.org><mailto:sipping-***@ietf.org
> <mailto:sipping-***@ietf.org>>
>
> > <mailto:sipping-***@ietf.org
> <mailto:sipping-***@ietf.org><mailto:sipping-***@ietf.org
> <mailto:sipping-***@ietf.org>>>
>
> > >> >>2010-04-09 14:23
> > >> >>
> > >> >>收件人
>
> > >> >>***@ietf.org
> <mailto:***@ietf.org><mailto:***@ietf.org
> <mailto:***@ietf.org>> <mailto:***@ietf.org
> <mailto:***@ietf.org><mailto:***@ietf.org
> <mailto:***@ietf.org>>>
>
> > >> >>抄送
> > >> >>
> > >> >>主题
> > >> >>Re: [Sipping] About offeranswer draft:
> > >> >>
> > >> >>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
> > >> >>
>
> > >> >>***@zte.com.cn
> <mailto:***@zte.com.cn><mailto:***@zte.com.cn
> <mailto:***@zte.com.cn>> <mailto:***@zte.com.cn
> <mailto:***@zte.com.cn><mailto:***@zte.com.cn
> <mailto:***@zte.com.cn>>>
>
> > >> >>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
> > earlymedia 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 <***@softfront.jp
> <mailto:***@softfront.jp><mailto:***@softfront.jp
> <mailto:***@softfront.jp>>
>
> > <mailto:***@softfront.jp
> <mailto:***@softfront.jp><mailto:***@softfront.jp
> <mailto:***@softfront.jp>>>>
>
> > >> >>>发件人: sipping-***@ietf.org
> <mailto:sipping-***@ietf.org><mailto:sipping-***@ietf.org
> <mailto:sipping-***@ietf.org>>
>
> > <mailto:sipping-***@ietf.org
> <mailto:sipping-***@ietf.org><mailto:sipping-***@ietf.org
> <mailto:sipping-***@ietf.org>>>
>
> > >> >>>2010-04-09 10:13
> > >> >>>
> > >> >>>收件人
>
> > >> >>>***@ietf.org
> <mailto:***@ietf.org><mailto:***@ietf.org
> <mailto:***@ietf.org>> <mailto:***@ietf.org
> <mailto:***@ietf.org><mailto:***@ietf.org
> <mailto:***@ietf.org>>>
>
> > >> >>>抄送
> > >> >>>
> > >> >>>主题
> > >> >>>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
> > >> >>>
>
> > >> >>>***@zte.com.cn
> <mailto:***@zte.com.cn><mailto:***@zte.com.cn
> <mailto:***@zte.com.cn>> <mailto:***@zte.com.cn
> <mailto:***@zte.com.cn><mailto:***@zte.com.cn
> <mailto:***@zte.com.cn>>>
>
> > >> >>>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, Ithink 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-***@cs.columbia.edu
> <mailto:sip-***@cs.columbia.edu><mailto:sip-***@cs.columbia.edu
> <mailto:sip-***@cs.columbia.edu>>
>
> > <mailto:sip-***@cs.columbia.edu
> <mailto:sip-***@cs.columbia.edu><mailto:sip-***@cs.columbia.edu
> <mailto:sip-***@cs.columbia.edu>>> for questions on current sip
> > Use ***@ietf.org
> <mailto:***@ietf.org><mailto:***@ietf.org <mailto:***@ietf.org>>
> <mailto:***@ietf.org <mailto:***@ietf.org><mailto:***@ietf.org
> <mailto:***@ietf.org>>> 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-***@cs.columbia.edu
> <mailto:sip-***@cs.columbia.edu><mailto:sip-***@cs.columbia.edu
> <mailto:sip-***@cs.columbia.edu>> for questions on current sip
>
> > Use ***@ietf.org
> <mailto:***@ietf.org><mailto:***@ietf.org <mailto:***@ietf.org>> 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-***@cs.columbia.edu for questions on current sip
Use ***@iet

[Eric wang]

HI Christer
inlines


2010/4/16 Christer Holmberg <***@ericsson.com>

> Hi,
>
> SIP used to be (m)music to my ears...
>
> Anyway, I don't anyone has said that it is "forbidden" for a UAC to use a
> SDP in an unreliable 18x. But, it is not the "official" SDP answer.
>
> And, if the UAC uses the SDP in the unreliable 18x, and the SDP in the
> reliable answer is then different, the UAC should consider it as a protocol
> error in my opinion - not do any "switching".
>

I think UAC should consider SDP in reliable response as the correct one and
listen to it.
I don't konw why unreliable 18x with SDP be considered as answer if
received, I will be appreciate if someone tell my why.It seems like for
purpose as precondition, if I'm right, I recommand use reliable 18x with SDP
for precondition and treat SDP in reliable response as answer that should be
used finally(I konw it's violate rfc3261).


>
> >We shouldn't make complicated rules because the system has already been
> complicated.
>
> What is complicated in "There can be only one SDP answer per transaction,
> and it comes in the first reliable response of that transaction"?


I mean, It's complicated if SDPs in reliable responses should be
ingored(treated as neither offer nor answer), because UAC has already
received answer SDP in either reliable or unreliable response.
I support no SDP in reliable responses should be ignored, we should trust
*reliable*.


> >In my opinion, the offer/answer model works well if responses are
> reliable.
> >If we allow several reliable 18x with SDP, what happen if 18x is after
> UPDATEs.There must be some rules >saying "NO".I prefer several reliable 18xs
> with SDP appear only in fork.
>
> If the UAC sends a new offer in UPDATE, it will receive the new answer in
> the UPDATE 200 OK.
>
>
Yes!


> The 18x still belongs to the INVITE transaction, and may contain the
> previous SDP answer. But, since you have already received an SDP answer for
> the INVITE transaction, the SDP in the new 18x it has no meaning - no matter
> if there are UPDATE(s) or not...
>
>
The meaningless SDP would make mechanism harder to implementation.

BR,
Eric


> Regards,
>
> Christer
>
>
>
>
>
>
> ÔÚ 2010Äê4ÔÂ14ÈÕ ÏÂÎç10:02£¬Paul Kyzivat <***@cisco.com<mailto:
> ***@cisco.com>>ÐŽµÀ£º
>
>
> Eric wang wrote:
> > Hi all,
> >
> > I believe that SDP in non-reliable response is useful. eg, if the
> > UAS wants to send a tone to UAC while the UAC doesn't support 100rel,
> > the UAS can use a non-reliable response with the tone SDP.
> > So I believe different SDPs(compare with the answer) can exist in
> > non-reliable response and final 2xx response.
>
> IMO this makes no sense. For one thing, the UAC is instructed to accept
> the first and ignore the rest, so sending differing values will have no
> utility. For another, this only affects where the UAS will receive media
> - it can have no effect on where the UAC receives media. Generally the
> UAC isn't transmitting until the call is established, so what is the point.
>
> > But, when I saw the chart below, the only words in my mind is ,"OMG,
> > the SIP is never SI(m)P(le) again!"
>
> Where have you been? SIP hasn't been simple since early in the century.
>
> Thanks,
> Paul
>
>
> > 2010/4/14 OKUMURA Shinji <***@softfront.jp<mailto:
> ***@softfront.jp>
> > <mailto:***@softfront.jp<mailto:***@softfront.jp
> >>>
> >
> > Hi Gao,
> >
> > In the following case,
> >
> > UAC UAS
> > | F1 INVITE (SDP1) | <-- offer
> > |-------------------->|
> > | F2 1xx (SDP2) |
> > |<--------------------|
> > | F3 1xx (SDP3) |
> > |<--------------------|
> > | F4 1xx-rel (SDP4) | <-- answer
> > |<--------------------|
> > | F5 1xx-rel (SDP5) |
> > |<--------------------|
> > | F6 1xxl (SDP6) |
> > |<--------------------|
> > | F7 2xx INV(SDP7) |
> > |<--------------------|
> > | F8 ACK |
> > |-------------------->|
> > (PRACK transactions are not shown)
> >
> > I tried to arrange the rules.
> > (small letters mean informational)
> >
> > UAC,
> > (Rc1) MUST treat SDP2 as the answer.
> > (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> > (Rc3) may treat SDP3 as the answer.
> > (Rc4) should treat SDP4 as the answer and confirm the current O/A
> > status by sending new offer.
> >
> > UAS,
> > (Rs1) should not send SDP5, SDP6 and SDP7.
> > (Rs2) must not send SDP2 and SDP3 if these are not the same as
> SDP4.
> >
> > Rc3 and Rc4 are new added descriptions.
> > Rs1 and Rs2 are current descriptions in this draft.
> >
> > I think "MUST NOT" is suitable for (Rs1).
> > Because RFC3261 says
> > Once the UAS has sent or received an answer to the initial
> > offer, it MUST NOT generate subsequent offers in any responses
> > to the initial INVITE. This means that a UAS based on this
> > specification alone can never generate subsequent offers until
> > completion of the initial transaction.
> >
> > SDP5 and SDP7 are regarded as "subsequent offers".
> >
> > What do you think of these?
> >
> > Regards,
> > Shinji
> >
> > ***@zte.com.cn<mailto:***@zte.com.cn> <mailto:
> ***@zte.com.cn<mailto:***@zte.com.cn>>
> > Mon, 12 Apr 2010 11:37:09 +0800
> > >Hi Shinji,
> > >
> > >Please see inlines.
> > >
> > >Thanks,
> > >
> > >Gao
> > >
> > >sipping-***@ietf.org<mailto:sipping-***@ietf.org> <mailto:
> sipping-***@ietf.org<mailto:sipping-***@ietf.org>> ÐŽÓÚ
> > 2010-04-12 10:55:47:
> > >
> > >> Hi Gao,
> > >>
> > >> The clarifications for the section 13.2.1 of RFC 3261 is
> > >> one of the major purposes in this draft.
> > >>
> > >> In the section 3.1 of this draft,
> > >> | 3.1. Offer/Answer for the INVITE method with 100rel
> extension
> > >> | (snip) All the session
> > >> | descriptions in the unreliable responses to the INVITE
> > request must
> > >> | be identical to the answer which is included in the reliable
> > >> | response.
> > >>
> > >> Do you doubt this clarification?
> > >> In my understanding, this has already reached the consensus in
> WG.
> > >
> > >[Gao] I am not want to *challenge* the consensus we have reached
> > in WG.
> > >But as this draft is aims for clarification, not for normative
> > correction,
> > >I have no way to convince the *UAS*.
> > >
> > >>
> > >> I'm confused.
> > >> Do you have something a concrete proposal?
> > >
> > >[Gao] I think the original illegibility is from RFC3261. So, I
> sended
> > >mails about it in SIPCore ML:
> > >
> > >http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
> > >http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html
> > >
> > >To be honest, I think there are two options here:
> > >1. Forbid different SDP(compare with the answer) before the answer
> > >normatively.
> > >2. Allowing different SDP(compare with the answer) before the
> answer
> > >normatively.
> > >
> > >>
> > >> Just to be sure, this draft is not a normative document but
> > >> an informational one as you no doubt know.
> > >
> > >[Gao] Sure, I know it is informative.
> > >
> > >>
> > >> Regards,
> > >> Shinji
> > >>
> > >> ***@zte.com.cn<mailto:***@zte.com.cn> <mailto:
> ***@zte.com.cn<mailto:***@zte.com.cn>>
> > >> Fri, 9 Apr 2010 16:50:12 +0800
> > >> >Hi Shinji,
> > >> >
> > >> >Thanks firstly.
> > >> >
> > >> >But the UAS do not think it throws the problem. RFC3261 said
> > UAS may send
> > >> >the same SDP before the answer, but there is not normative
> > words of to
> > >> >forbid the different SDPs.
> > >> >
> > >> >And if the equipment has been in the network, unless we using
> > the evident
> > >> >standard, we has no way to request their correction.
> > >> >
> > >> >Gao
> > >> >
> > >> >OKUMURA Shinji <***@softfront.jp<mailto:
> ***@softfront.jp>
> > <mailto:***@softfront.jp<mailto:
> ***@softfront.jp>>>
> > >> >·¢ŒþÈË: sipping-***@ietf.org<mailto:sipping-***@ietf.org>
> <mailto:sipping-***@ietf.org<mailto:sipping-***@ietf.org>>
> > >> >2010-04-09 16:30
> > >> >
> > >> >ÊÕŒþÈË
> > >> >***@ietf.org<mailto:***@ietf.org> <mailto:
> ***@ietf.org<mailto:***@ietf.org>>
> > >> >³­ËÍ
> > >> >
> > >> >Ö÷Ìâ
> > >> >Re: [Sipping] About offeranswer draft:
> > >> >
> > >> >Hi Gao,
> > >> >
> > >> >In this case it is no doubt the UAS is a cause of the problem.
> > >> >All you have to do is say "Your UAS is against the rules".
> > >> >You will surely win the fight.
> > >> >
> > >> >Regards,
> > >> >Shinji
> > >> >
> > >> >***@zte.com.cn<mailto:***@zte.com.cn> <mailto:
> ***@zte.com.cn<mailto:***@zte.com.cn>>
> > >> >Fri, 9 Apr 2010 15:25:58 +0800
> > >> >>Hi Shinji,
> > >> >>
> > >> >>By myself, I am OK with the three ways. But if there's no
> > normative
> > >> >>definition here, there would be some interworking fight for
> > this issue.
> > >> >>
> > >> >>Thanks,
> > >> >>
> > >> >>Gao
> > >> >>
> > >> >>OKUMURA Shinji <***@softfront.jp<mailto:
> ***@softfront.jp>
> > <mailto:***@softfront.jp<mailto:
> ***@softfront.jp>>>
> > >> >>·¢ŒþÈË: sipping-***@ietf.org<mailto:sipping-***@ietf.org
> >
> > <mailto:sipping-***@ietf.org<mailto:sipping-***@ietf.org>>
> > >> >>2010-04-09 14:23
> > >> >>
> > >> >>ÊÕŒþÈË
> > >> >>***@ietf.org<mailto:***@ietf.org> <mailto:
> ***@ietf.org<mailto:***@ietf.org>>
> > >> >>³­ËÍ
> > >> >>
> > >> >>Ö÷Ìâ
> > >> >>Re: [Sipping] About offeranswer draft:
> > >> >>
> > >> >>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
> > >> >>
> > >> >>***@zte.com.cn<mailto:***@zte.com.cn> <mailto:
> ***@zte.com.cn<mailto:***@zte.com.cn>>
> > >> >>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
> > earlymedia 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 <***@softfront.jp<mailto:
> ***@softfront.jp>
> > <mailto:***@softfront.jp<mailto:
> ***@softfront.jp>>>
> > >> >>>·¢ŒþÈË: sipping-***@ietf.org<mailto:
> sipping-***@ietf.org>
> > <mailto:sipping-***@ietf.org<mailto:sipping-***@ietf.org>>
> > >> >>>2010-04-09 10:13
> > >> >>>
> > >> >>>ÊÕŒþÈË
> > >> >>>***@ietf.org<mailto:***@ietf.org> <mailto:
> ***@ietf.org<mailto:***@ietf.org>>
> > >> >>>³­ËÍ
> > >> >>>
> > >> >>>Ö÷Ìâ
> > >> >>>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
> > >> >>>
> > >> >>>***@zte.com.cn<mailto:***@zte.com.cn> <mailto:
> ***@zte.com.cn<mailto:***@zte.com.cn>>
> > >> >>>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, Ithink 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-***@cs.columbia.edu<mailto:
> sip-***@cs.columbia.edu>
> > <mailto:sip-***@cs.columbia.edu<mailto:
> sip-***@cs.columbia.edu>> for questions on current sip
> > Use ***@ietf.org<mailto:***@ietf.org> <mailto:***@ietf.org<mailto:
> ***@ietf.org>> 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-***@cs.columbia.edu<mailto:
> sip-***@cs.columbia.edu> for questions on current sip
> > Use ***@ietf.org<mailto:***@ietf.org> for new developments of core SIP
>
>

[g***@zte.com.cn]

Hi Eric,

Are you ZTE's Eric? I have one colleague also named Eric wang(Wang Libo).

And some comments inlines.

Thanks,

Gao

sipping-***@ietf.org ÐŽÓÚ 2010-04-14 13:04:34:

> Hi all,
>
> I believe that SDP in non-reliable response is useful. eg, if
> the UAS wants to send a tone to UAC while the UAC doesn't support
> 100rel, the UAS can use a non-reliable response with the tone SDP.
> So I believe different SDPs(compare with the answer) can exist in
> non-reliable response and final 2xx response.

Yes, it is so in many deployed network. But the key problem here about the
UAC's normative handling of the real answer, if it is different from the
previous the SDP from the UAS.

>
> But, when I saw the chart below, the only words in my mind is
> ,"OMG, the SIP is never SI(m)P(le) again!"

I guess it is the extreme use case in theory. Considering normal call
flow, it would be more simple. But if we should evaluate the rules, we
usually need such use cases, as Shinji showed us.

>
>
>
>
> 2010/4/14 OKUMURA Shinji <***@softfront.jp>
> Hi Gao,
>
> In the following case,
>
> UAC UAS
> | F1 INVITE (SDP1) | <-- offer
> |-------------------->|
> | F2 1xx (SDP2) |
> |<--------------------|
> | F3 1xx (SDP3) |
> |<--------------------|
> | F4 1xx-rel (SDP4) | <-- answer
> |<--------------------|
> | F5 1xx-rel (SDP5) |
> |<--------------------|
> | F6 1xxl (SDP6) |
> |<--------------------|
> | F7 2xx INV(SDP7) |
> |<--------------------|
> | F8 ACK |
> |-------------------->|
> (PRACK transactions are not shown)
>
> I tried to arrange the rules.
> (small letters mean informational)
>
> UAC,
> (Rc1) MUST treat SDP2 as the answer.
> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> (Rc3) may treat SDP3 as the answer.
> (Rc4) should treat SDP4 as the answer and confirm the current O/A
> status by sending new offer.
>
> UAS,
> (Rs1) should not send SDP5, SDP6 and SDP7.
> (Rs2) must not send SDP2 and SDP3 if these are not the same as SDP4.
>
> Rc3 and Rc4 are new added descriptions.
> Rs1 and Rs2 are current descriptions in this draft.
>
> I think "MUST NOT" is suitable for (Rs1).
> Because RFC3261 says
> Once the UAS has sent or received an answer to the initial
> offer, it MUST NOT generate subsequent offers in any responses
> to the initial INVITE. This means that a UAS based on this
> specification alone can never generate subsequent offers until
> completion of the initial transaction.
>
> SDP5 and SDP7 are regarded as "subsequent offers".
>
> What do you think of these?
>
> Regards,
> Shinji
>
> ***@zte.com.cn
> Mon, 12 Apr 2010 11:37:09 +0800
> >Hi Shinji,
> >
> >Please see inlines.
> >
> >Thanks,
> >
> >Gao
> >
> >sipping-***@ietf.org ÐŽÓÚ 2010-04-12 10:55:47:
> >
> >> Hi Gao,
> >>
> >> The clarifications for the section 13.2.1 of RFC 3261 is
> >> one of the major purposes in this draft.
> >>
> >> In the section 3.1 of this draft,
> >> | 3.1. Offer/Answer for the INVITE method with 100rel extension
> >> | (snip) All the session
> >> | descriptions in the unreliable responses to the INVITE request
must
> >> | be identical to the answer which is included in the reliable
> >> | response.
> >>
> >> Do you doubt this clarification?
> >> In my understanding, this has already reached the consensus in WG.
> >
> >[Gao] I am not want to *challenge* the consensus we have reached in WG.
> >But as this draft is aims for clarification, not for normative
correction,
> >I have no way to convince the *UAS*.
> >
> >>
> >> I'm confused.
> >> Do you have something a concrete proposal?
> >
> >[Gao] I think the original illegibility is from RFC3261. So, I sended
> >mails about it in SIPCore ML:
> >
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html
> >
> >To be honest, I think there are two options here:
> >1. Forbid different SDP(compare with the answer) before the answer
> >normatively.
> >2. Allowing different SDP(compare with the answer) before the answer
> >normatively.
> >
> >>
> >> Just to be sure, this draft is not a normative document but
> >> an informational one as you no doubt know.
> >
> >[Gao] Sure, I know it is informative.
> >
> >>
> >> Regards,
> >> Shinji
> >>
> >> ***@zte.com.cn
> >> Fri, 9 Apr 2010 16:50:12 +0800
> >> >Hi Shinji,
> >> >
> >> >Thanks firstly.
> >> >
> >> >But the UAS do not think it throws the problem. RFC3261 said UAS may
send
> >> >the same SDP before the answer, but there is not normative words of
to
> >> >forbid the different SDPs.
> >> >
> >> >And if the equipment has been in the network, unless we using the
evident
> >> >standard, we has no way to request their correction.
> >> >
> >> >Gao
> >> >
> >> >OKUMURA Shinji <***@softfront.jp>
> >> >·¢ŒþÈË: sipping-***@ietf.org
> >> >2010-04-09 16:30
> >> >
> >> >ÊÕŒþÈË
> >> >***@ietf.org
> >> >³­ËÍ
> >> >
> >> >Ö÷Ìâ
> >> >Re: [Sipping] About offeranswer draft:
> >> >
> >> >Hi Gao,
> >> >
> >> >In this case it is no doubt the UAS is a cause of the problem.
> >> >All you have to do is say "Your UAS is against the rules".
> >> >You will surely win the fight.
> >> >
> >> >Regards,
> >> >Shinji
> >> >
> >> >***@zte.com.cn
> >> >Fri, 9 Apr 2010 15:25:58 +0800
> >> >>Hi Shinji,
> >> >>
> >> >>By myself, I am OK with the three ways. But if there's no normative
> >> >>definition here, there would be some interworking fight for this
issue.
> >> >>
> >> >>Thanks,
> >> >>
> >> >>Gao
> >> >>
> >> >>OKUMURA Shinji <***@softfront.jp>
> >> >>·¢ŒþÈË: sipping-***@ietf.org
> >> >>2010-04-09 14:23
> >> >>
> >> >>ÊÕŒþÈË
> >> >>***@ietf.org
> >> >>³­ËÍ
> >> >>
> >> >>Ö÷Ìâ
> >> >>Re: [Sipping] About offeranswer draft:
> >> >>
> >> >>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
> >> >>
> >> >>***@zte.com.cn
> >> >>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
> earlymedia 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 <***@softfront.jp>
> >> >>>·¢ŒþÈË: sipping-***@ietf.org
> >> >>>2010-04-09 10:13
> >> >>>
> >> >>>ÊÕŒþÈË
> >> >>>***@ietf.org
> >> >>>³­ËÍ
> >> >>>
> >> >>>Ö÷Ìâ
> >> >>>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
> >> >>>
> >> >>>***@zte.com.cn
> >> >>>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, Ithink 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-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org for new developments of core SIP


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[Paul Kyzivat]

I'm not going to reply to this until there has been discussion on my
other replies.

Thanks,
Paul

OKUMURA Shinji wrote:
> Hi Gao,
>
> In the following case,
>
> UAC UAS
> | F1 INVITE (SDP1) | <-- offer
> |-------------------->|
> | F2 1xx (SDP2) |
> |<--------------------|
> | F3 1xx (SDP3) |
> |<--------------------|
> | F4 1xx-rel (SDP4) | <-- answer
> |<--------------------|
> | F5 1xx-rel (SDP5) |
> |<--------------------|
> | F6 1xxl (SDP6) |
> |<--------------------|
> | F7 2xx INV(SDP7) |
> |<--------------------|
> | F8 ACK |
> |-------------------->|
> (PRACK transactions are not shown)
>
> I tried to arrange the rules.
> (small letters mean informational)
>
> UAC,
> (Rc1) MUST treat SDP2 as the answer.
> (Rc2) MUST ignore SDP5, SDP6 and SDP7.
> (Rc3) may treat SDP3 as the answer.
> (Rc4) should treat SDP4 as the answer and confirm the current O/A status by sending new offer.
>
> UAS,
> (Rs1) should not send SDP5, SDP6 and SDP7.
> (Rs2) must not send SDP2 and SDP3 if these are not the same as SDP4.
>
> Rc3 and Rc4 are new added descriptions.
> Rs1 and Rs2 are current descriptions in this draft.
>
> I think "MUST NOT" is suitable for (Rs1).
> Because RFC3261 says
> Once the UAS has sent or received an answer to the initial
> offer, it MUST NOT generate subsequent offers in any responses
> to the initial INVITE. This means that a UAS based on this
> specification alone can never generate subsequent offers until
> completion of the initial transaction.
>
> SDP5 and SDP7 are regarded as "subsequent offers".
>
> What do you think of these?
>
> Regards,
> Shinji
>
> ***@zte.com.cn
> Mon, 12 Apr 2010 11:37:09 +0800
>> Hi Shinji,
>>
>> Please see inlines.
>>
>> Thanks,
>>
>> Gao
>>
>> sipping-***@ietf.org 写于 2010-04-12 10:55:47:
>>
>>> Hi Gao,
>>>
>>> The clarifications for the section 13.2.1 of RFC 3261 is
>>> one of the major purposes in this draft.
>>>
>>> In the section 3.1 of this draft,
>>> | 3.1. Offer/Answer for the INVITE method with 100rel extension
>>> | (snip) All the session
>>> | descriptions in the unreliable responses to the INVITE request must
>>> | be identical to the answer which is included in the reliable
>>> | response.
>>>
>>> Do you doubt this clarification?
>>> In my understanding, this has already reached the consensus in WG.
>> [Gao] I am not want to *challenge* the consensus we have reached in WG.
>> But as this draft is aims for clarification, not for normative correction,
>> I have no way to convince the *UAS*.
>>
>>> I'm confused.
>>> Do you have something a concrete proposal?
>> [Gao] I think the original illegibility is from RFC3261. So, I sended
>> mails about it in SIPCore ML:
>>
>> http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
>> http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html
>>
>> To be honest, I think there are two options here:
>> 1. Forbid different SDP(compare with the answer) before the answer
>> normatively.
>> 2. Allowing different SDP(compare with the answer) before the answer
>> normatively.
>>
>>> Just to be sure, this draft is not a normative document but
>>> an informational one as you no doubt know.
>> [Gao] Sure, I know it is informative.
>>
>>> Regards,
>>> Shinji
>>>
>>> ***@zte.com.cn
>>> Fri, 9 Apr 2010 16:50:12 +0800
>>>> Hi Shinji,
>>>>
>>>> Thanks firstly.
>>>>
>>>> But the UAS do not think it throws the problem. RFC3261 said UAS may send
>>>> the same SDP before the answer, but there is not normative words of to
>>>> forbid the different SDPs.
>>>>
>>>> And if the equipment has been in the network, unless we using the evident
>>>> standard, we has no way to request their correction.
>>>>
>>>> Gao
>>>>
>>>> OKUMURA Shinji <***@softfront.jp>
>>>> 发件人: sipping-***@ietf.org
>>>> 2010-04-09 16:30
>>>>
>>>> 收件人
>>>> ***@ietf.org
>>>> 抄送
>>>>
>>>> 主题
>>>> Re: [Sipping] About offeranswer draft:
>>>>
>>>> Hi Gao,
>>>>
>>>> In this case it is no doubt the UAS is a cause of the problem.
>>>> All you have to do is say "Your UAS is against the rules".
>>>> You will surely win the fight.
>>>>
>>>> Regards,
>>>> Shinji
>>>>
>>>> ***@zte.com.cn
>>>> Fri, 9 Apr 2010 15:25:58 +0800
>>>>> Hi Shinji,
>>>>>
>>>>> By myself, I am OK with the three ways. But if there's no normative
>>>>> definition here, there would be some interworking fight for this issue.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Gao
>>>>>
>>>>> OKUMURA Shinji <***@softfront.jp>
>>>>> 发件人: sipping-***@ietf.org
>>>>> 2010-04-09 14:23
>>>>>
>>>>> 收件人
>>>>> ***@ietf.org
>>>>> 抄送
>>>>>
>>>>> 主题
>>>>> Re: [Sipping] About offeranswer draft:
>>>>>
>>>>> 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
>>>>>
>>>>> ***@zte.com.cn
>>>>> 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 earlymedia 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 <***@softfront.jp>
>>>>>> 发件人: sipping-***@ietf.org
>>>>>> 2010-04-09 10:13
>>>>>>
>>>>>> 收件人
>>>>>> ***@ietf.org
>>>>>> 抄送
>>>>>>
>>>>>> 主题
>>>>>> 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
>>>>>>
>>>>>> ***@zte.com.cn
>>>>>> 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, Ithink 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-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.

[Paul Kyzivat]

inline

***@zte.com.cn wrote:
>
> Hi Shinji,
>
> Please see inlines.
>
> Thanks,
>
> Gao
>
> sipping-***@ietf.org 写于 2010-04-12 10:55:47:
>
> > Hi Gao,
> >
> > The clarifications for the section 13.2.1 of RFC 3261 is
> > one of the major purposes in this draft.
> >
> > In the section 3.1 of this draft,
> > | 3.1. Offer/Answer for the INVITE method with 100rel extension
> > | (snip) All the session
> > | descriptions in the unreliable responses to the INVITE request must
> > | be identical to the answer which is included in the reliable
> > | response.
> >
> > Do you doubt this clarification?
> > In my understanding, this has already reached the consensus in WG.
>
> [Gao] I am not want to *challenge* the consensus we have reached in WG.
> But as this draft is aims for clarification, not for normative
> correction, I have no way to convince the *UAS*.

(I just posted a related reply to a later message in this thread.)

Whether this clarification is supported by the existing normative text
is worthy of some careful thought.

As I noted in the other reply, a UAS sending multiple *unreliable*
responses with SDP must assume that some or all of them will be lost. If
these SDPs have different values, and the UAC processes the first it
receives, and ignores the rest, then the resulting behavior will be
indeterminate.

IMO this is sufficient to infer that there is only one meaningful
interpretation, so that a clarification is sufficient without a
normative change.

Thanks,
Paul

> >
> > I'm confused.
> > Do you have something a concrete proposal?
>
> [Gao] I think the original illegibility is from RFC3261. So, I sended
> mails about it in SIPCore ML:
>
> http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
> http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html
>
> To be honest, I think there are two options here:
> 1. Forbid different SDP(compare with the answer) before the answer
> normatively.
> 2. Allowing different SDP(compare with the answer) before the answer
> normatively.
>
> >
> > Just to be sure, this draft is not a normative document but
> > an informational one as you no doubt know.
>
> [Gao] Sure, I know it is informative.
>
> >
> > Regards,
> > Shinji
> >
> > ***@zte.com.cn
> > Fri, 9 Apr 2010 16:50:12 +0800
> > >Hi Shinji,
> > >
> > >Thanks firstly.
> > >
> > >But the UAS do not think it throws the problem. RFC3261 said UAS may
> send
> > >the same SDP before the answer, but there is not normative words of to
> > >forbid the different SDPs.
> > >
> > >And if the equipment has been in the network, unless we using the
> evident
> > >standard, we has no way to request their correction.
> > >
> > >Gao
> > >
> > >OKUMURA Shinji <***@softfront.jp>
> > >发件人: sipping-***@ietf.org
> > >2010-04-09 16:30
> > >
> > >收件人
> > >***@ietf.org
> > >抄送
> > >
> > >主题
> > >Re: [Sipping] About offeranswer draft:
> > >
> > >Hi Gao,
> > >
> > >In this case it is no doubt the UAS is a cause of the problem.
> > >All you have to do is say "Your UAS is against the rules".
> > >You will surely win the fight.
> > >
> > >Regards,
> > >Shinji
> > >
> > >***@zte.com.cn
> > >Fri, 9 Apr 2010 15:25:58 +0800
> > >>Hi Shinji,
> > >>
> > >>By myself, I am OK with the three ways. But if there's no normative
> > >>definition here, there would be some interworking fight for this issue.
> > >>
> > >>Thanks,
> > >>
> > >>Gao
> > >>
> > >>OKUMURA Shinji <***@softfront.jp>
> > >>发件人: sipping-***@ietf.org
> > >>2010-04-09 14:23
> > >>
> > >>收件人
> > >>***@ietf.org
> > >>抄送
> > >>
> > >>主题
> > >>Re: [Sipping] About offeranswer draft:
> > >>
> > >>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
> > >>
> > >>***@zte.com.cn
> > >>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
> earlymedia 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 <***@softfront.jp>
> > >>>发件人: sipping-***@ietf.org
> > >>>2010-04-09 10:13
> > >>>
> > >>>收件人
> > >>>***@ietf.org
> > >>>抄送
> > >>>
> > >>>主题
> > >>>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
> > >>>
> > >>>***@zte.com.cn
> > >>>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,
> Ithink 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-***@cs.columbia.edu for questions on current sip
> > >Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
> > Use ***@ietf.org for new developments of core SIP
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org

[g***@zte.com.cn]

Hi Paul and Shinji,

I guess I can converg my discussion on the point, should UAC refresh the
media plane by the real answer?

Or, just ignore the real answer, if it has gotten one in one previous
unreliable response?

And no matter what direction we choose, we should do the evaluation about
whether it is violation/correction of RFC3261.

Thanks,

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[OKUMURA Shinji]

Hi Gao,

***@zte.com.cn
Thu, 15 Apr 2010 14:32:20 +0800
>Hi Paul and Shinji,
>
>I guess I can converge my discussion on the point, should UAC refresh the
>media plane by the real answer?
>
>Or, just ignore the real answer, if it has gotten one in one previous
>unreliable response?

IMO UAC should refresh the current view of a session description
by the real answer.

>And no matter what direction we choose, we should do the evaluation about
>whether it is violation/correction of RFC3261.

I think, in RFC3261 UAC's behavior is described based on the
premise that UAS never include the different SDP from the answer
into the prior unreliable responcse.
It is absolutely an implicit premise. But it is not bad, I think.

So then we can think that UAC's behavior for the different SDP
is not described in RFC. Therefor it can be BCP and does not
violate RFC.

Quod Erat Demonstrandum.

Regards,
Shinji
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[g***@zte.com.cn]

Hi Shinji,




OKUMURA Shinji <***@softfront.jp>
·¢ŒþÈË: sipping-***@ietf.org
2010-04-15 16:22

ÊÕŒþÈË
***@ietf.org
³­ËÍ

Ö÷Ìâ
Re: [Sipping] About offeranswer draft:






Hi Gao,

***@zte.com.cn
Thu, 15 Apr 2010 14:32:20 +0800
>Hi Paul and Shinji,
>
>I guess I can converge my discussion on the point, should UAC refresh the

>media plane by the real answer?
>
>Or, just ignore the real answer, if it has gotten one in one previous
>unreliable response?

IMO UAC should refresh the current view of a session description
by the real answer.

[Gao] By myself, I also prefer this one.

>And no matter what direction we choose, we should do the evaluation about

>whether it is violation/correction of RFC3261.

I think, in RFC3261 UAC's behavior is described based on the
premise that UAS never include the different SDP from the answer
into the prior unreliable responcse.
It is absolutely an implicit premise. But it is not bad, I think.

So then we can think that UAC's behavior for the different SDP
is not described in RFC. Therefor it can be BCP and does not
violate RFC.

[Gao] If we want to BCP thing for different SDP, we need to clarify that
*same* SDP is not mandatory for UAS's behavior.
I am not sure whether "*same* SDP is not mandatory for UAS's behavior" is
normative change from RFC3261 or not.

Quod Erat Demonstrandum.

Regards,
Shinji
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP





--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[OKUMURA Shinji]

Hi,

I think "*same* SDP is mandatory for UAS's behavior",
and
"That same exact answer MAY also be placed in any provisional
responses sent prior to the answer." means it adequately for me.

Regards,
Shinji

***@zte.com.cn
Thu, 15 Apr 2010 16:42:48 +0800
>Hi Shinji,
>
>OKUMURA Shinji <***@softfront.jp>
>发件人: sipping-***@ietf.org
>2010-04-15 16:22
>
>收件人
>***@ietf.org
>抄送
>
>主题
>Re: [Sipping] About offeranswer draft:
>
>Hi Gao,
>
>***@zte.com.cn
>Thu, 15 Apr 2010 14:32:20 +0800
>>Hi Paul and Shinji,
>>
>>I guess I can converge my discussion on the point, should UAC refresh the
>>media plane by the real answer?
>>
>>Or, just ignore the real answer, if it has gotten one in one previous
>>unreliable response?
>
>IMO UAC should refresh the current view of a session description
>by the real answer.
>
>[Gao] By myself, I also prefer this one.
>
>>And no matter what direction we choose, we should do the evaluation about
>>whether it is violation/correction of RFC3261.
>
>I think, in RFC3261 UAC's behavior is described based on the
>premise that UAS never include the different SDP from the answer
>into the prior unreliable responcse.
>It is absolutely an implicit premise. But it is not bad, I think.
>
>So then we can think that UAC's behavior for the different SDP
>is not described in RFC. Therefor it can be BCP and does not
>violate RFC.
>
>[Gao] If we want to BCP thing for different SDP, we need to clarify that
>*same* SDP is not mandatory for UAS's behavior.
>I am not sure whether "*same* SDP is not mandatory for UAS's behavior" is
>normative change from RFC3261 or not.
>
>Quod Erat Demonstrandum.
>
>Regards,
>Shinji
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current si

[g***@zte.com.cn]

Hi,

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================



OKUMURA Shinji <***@softfront.jp>
·¢ŒþÈË: sipping-***@ietf.org
2010-04-15 17:07

ÊÕŒþÈË
***@ietf.org
³­ËÍ

Ö÷Ìâ
Re: [Sipping] About offeranswer draft:






Hi,

I think "*same* SDP is mandatory for UAS's behavior",

[Gao] As you think *same* if mandatory, why not just ignore the real
answer, if it has gotten one in one previous unreliable response?

and
"That same exact answer MAY also be placed in any provisional
responses sent prior to the answer." means it adequately for me.

Regards,
Shinji


>>Hi Paul and Shinji,
>>
>>I guess I can converge my discussion on the point, should UAC refresh
the
>>media plane by the real answer?
>>
>>Or, just ignore the real answer, if it has gotten one in one previous
>>unreliable response?
>
>IMO UAC should refresh the current view of a session description
>by the real answer.
>
>[Gao] By myself, I also prefer this one.
>
>>And no matter what direction we choose, we should do the evaluation
about
>>whether it is violation/correction of RFC3261.
>
>I think, in RFC3261 UAC's behavior is described based on the
>premise that UAS never include the different SDP from the answer
>into the prior unreliable responcse.
>It is absolutely an implicit premise. But it is not bad, I think.
>
>So then we can think that UAC's behavior for the different SDP
>is not described in RFC. Therefor it can be BCP and does not
>violate RFC.
>
>[Gao] If we want to BCP thing for different SDP, we need to clarify that
>*same* SDP is not mandatory for UAS's behavior.
>I am not sure whether "*same* SDP is not mandatory for UAS's behavior" is

>normative change from RFC3261 or not.
>
>Quod Erat Demonstrandum.
>
>Regards,
>Shinji
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[OKUMURA Shinji]

Hi,

***@zte.com.cn
Thu, 15 Apr 2010 17:14:09 +0800
>Hi,
>
>OKUMURA Shinji <***@softfront.jp>
>发件人: sipping-***@ietf.org
>2010-04-15 17:07
>
>收件人
>***@ietf.org
>抄送
>
>主题
>Re: [Sipping] About offeranswer draft:
>
>Hi,
>
>I think "*same* SDP is mandatory for UAS's behavior",
>
>[Gao] As you think *same* if mandatory, why not just ignore the real
>answer, if it has gotten one in one previous unreliable response?

Because I am a kind man for an ill-behaved UAS.

nantene

>and
>"That same exact answer MAY also be placed in any provisional
>responses sent prior to the answer." means it adequately for me.
>
>Regards,
>Shinji
>
>
>>>Hi Paul and Shinji,
>>>
>>>I guess I can converge my discussion on the point, should UAC refresh the
>>>media plane by the real answer?
>>>
>>>Or, just ignore the real answer, if it has gotten one in one previous
>>>unreliable response?
>>
>>IMO UAC should refresh the current view of a session description
>>by the real answer.
>>
>>[Gao] By myself, I also prefer this one.
>>
>>>And no matter what direction we choose, we should do the evaluation about
>>>whether it is violation/correction of RFC3261.
>>
>>I think, in RFC3261 UAC's behavior is described based on the
>>premise that UAS never include the different SDP from the answer
>>into the prior unreliable responcse.
>>It is absolutely an implicit premise. But it is not bad, I think.
>>
>>So then we can think that UAC's behavior for the different SDP
>>is not described in RFC. Therefor it can be BCP and does not
>>violate RFC.
>>
>>[Gao] If we want to BCP thing for different SDP, we need to clarify that
>>*same* SDP is not mandatory for UAS's behavior.
>>I am not sure whether "*same* SDP is not mandatory for UAS's behavior" is
>
>>normative change from RFC3261 or not.
>>
>>Quod Erat Demonstrandum.
>>
>>Regards,
>>Shinji
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core S

[Paul Kyzivat]

OKUMURA Shinji wrote:
> Hi,
>
> ***@zte.com.cn
> Thu, 15 Apr 2010 17:14:09 +0800
>> Hi,
>>
>> OKUMURA Shinji <***@softfront.jp>
>> 发件人: sipping-***@ietf.org
>> 2010-04-15 17:07
>>
>> 收件人
>> ***@ietf.org
>> 抄送
>>
>> 主题
>> Re: [Sipping] About offeranswer draft:
>>
>> Hi,
>>
>> I think "*same* SDP is mandatory for UAS's behavior",
>>
>> [Gao] As you think *same* if mandatory, why not just ignore the real
>> answer, if it has gotten one in one previous unreliable response?
>
> Because I am a kind man for an ill-behaved UAS.
>
> nantene
>
>> and
>> "That same exact answer MAY also be placed in any provisional
>> responses sent prior to the answer." means it adequately for me.
>>
>> Regards,
>> Shinji

I think this is again getting into the realm of "how should the UAC
behave if the UAS is non-conforming?"

We are not obligated to clarify that at all, though we *may* provide a
suggestion if it seems important.

But I am opposed to expecting the UAC to detect the non-conformance in
order to take specific remedial action. I think that is what "should UAC
refresh the media plane by the real answer" is talking about.

*If* the UAC detects this non-conformance (the indeterminacy), then it
*could* attempt to remedy it by "refreshing the media plane". But there
may be indeterminacy that has not been detected. I guess that too could
be remedied by doing an extra O/A to "refresh". But that would increase
the number of messages in cases when there is no indeterminacy at all.
And if the refresh were attempted using a reINVITE, it could simply lead
to yet another indeterminacy.

So I prefer to say nothing about the "refresh" in this draft.

Thanks,
Paul

>>>> Hi Paul and Shinji,
>>>>
>>>> I guess I can converge my discussion on the point, should UAC refresh the
>>>> media plane by the real answer?
>>>>
>>>> Or, just ignore the real answer, if it has gotten one in one previous
>>>> unreliable response?
>>> IMO UAC should refresh the current view of a session description
>>> by the real answer.
>>>
>>> [Gao] By myself, I also prefer this one.
>>>
>>>> And no matter what direction we choose, we should do the evaluation about
>>>> whether it is violation/correction of RFC3261.
>>> I think, in RFC3261 UAC's behavior is described based on the
>>> premise that UAS never include the different SDP from the answer
>>> into the prior unreliable responcse.
>>> It is absolutely an implicit premise. But it is not bad, I think.
>>>
>>> So then we can think that UAC's behavior for the different SDP
>>> is not described in RFC. Therefor it can be BCP and does not
>>> violate RFC.
>>>
>>> [Gao] If we want to BCP thing for different SDP, we need to clarify that
>>> *same* SDP is not mandatory for UAS's behavior.
>>> I am not sure whether "*same* SDP is not mandatory for UAS's behavior" is
>>> normative change from RFC3261 or not.
>>>
>>> Quod Erat Demonstrandum.
>>>
>>> Regards,
>>> Shinji
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.o

[OKUMURA Shinji]

Hi Paul,

You say in another message,
>- but when "the answer" is received, it MUST be ignored
> (rather than "used") if an earlier SDP has already been
> received and so "treated as the answer".

I agree this is the one and only *intended* meaning of
the text.

Regards,
Shinji

Paul Kyzivat <***@cisco.com>
Fri, 16 Apr 2010 19:16:10 -0400
>OKUMURA Shinji wrote:
>> Hi,
>>
>> ***@zte.com.cn
>> Thu, 15 Apr 2010 17:14:09 +0800
>>> Hi,
>>>
>>> OKUMURA Shinji <***@softfront.jp>
>>> 发件人: sipping-***@ietf.org
>>> 2010-04-15 17:07
>>>
>>> 收件人
>>> ***@ietf.org
>>> 抄送
>>>
>>> 主题
>>> Re: [Sipping] About offeranswer draft:
>>>
>>> Hi,
>>>
>>> I think "*same* SDP is mandatory for UAS's behavior",
>>>
>>> [Gao] As you think *same* if mandatory, why not just ignore the real
>>> answer, if it has gotten one in one previous unreliable response?
>>
>> Because I am a kind man for an ill-behaved UAS.
>>
>> nantene
>>
>>> and
>>> "That same exact answer MAY also be placed in any provisional
>>> responses sent prior to the answer." means it adequately for me.
>>>
>>> Regards,
>>> Shinji
>
>I think this is again getting into the realm of "how should the UAC
>behave if the UAS is non-conforming?"
>
>We are not obligated to clarify that at all, though we *may* provide a
>suggestion if it seems important.
>
>But I am opposed to expecting the UAC to detect the non-conformance in
>order to take specific remedial action. I think that is what "should UAC
>refresh the media plane by the real answer" is talking about.
>
>*If* the UAC detects this non-conformance (the indeterminacy), then it
>*could* attempt to remedy it by "refreshing the media plane". But there
>may be indeterminacy that has not been detected. I guess that too could
>be remedied by doing an extra O/A to "refresh". But that would increase
>the number of messages in cases when there is no indeterminacy at all.
>And if the refresh were attempted using a reINVITE, it could simply lead
>to yet another indeterminacy.
>
>So I prefer to say nothing about the "refresh" in this draft.
>
> Thanks,
> Paul
>
>>>>> Hi Paul and Shinji,
>>>>>
>>>>> I guess I can converge my discussion on the point, should UAC refresh the
>>>>> media plane by the real answer?
>>>>>
>>>>> Or, just ignore the real answer, if it has gotten one in one previous
>>>>> unreliable response?
>>>> IMO UAC should refresh the current view of a session description
>>>> by the real answer.
>>>>
>>>> [Gao] By myself, I also prefer this one.
>>>>
>>>>> And no matter what direction we choose, we should do the evaluation about
>>>>> whether it is violation/correction of RFC3261.
>>>> I think, in RFC3261 UAC's behavior is described based on the
>>>> premise that UAS never include the different SDP from the answer
>>>> into the prior unreliable responcse.
>>>> It is absolutely an implicit premise. But it is not bad, I think.
>>>>
>>>> So then we can think that UAC's behavior for the different SDP
>>>> is not described in RFC. Therefor it can be BCP and does not
>>>> violate RFC.
>>>>
>>>> [Gao] If we want to BCP thing for different SDP, we need to clarify that
>>>> *same* SDP is not mandatory for UAS's behavior.
>>>> I am not sure whether "*same* SDP is not mandatory for UAS's behavior" is
>>>> normative change from RFC3261 or not.
>>>>
>>>> Quod Erat Demonstrandum.
>>>>
>>>> Regards,
>>>> Shinji
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on curr

[g***@zte.com.cn]

Paul Kyzivat <***@cisco.com> ÐŽÓÚ 2010-04-14 22:23:57:

> inline
>
> ***@zte.com.cn wrote:
> >
> > Hi Shinji,
> >
> > Please see inlines.
> >
> > Thanks,
> >
> > Gao
> >
> > sipping-***@ietf.org ÐŽÓÚ 2010-04-12 10:55:47:
> >
> > > Hi Gao,
> > >
> > > The clarifications for the section 13.2.1 of RFC 3261 is
> > > one of the major purposes in this draft.
> > >
> > > In the section 3.1 of this draft,
> > > | 3.1. Offer/Answer for the INVITE method with 100rel extension
> > > | (snip) All the session
> > > | descriptions in the unreliable responses to the INVITE request
must
> > > | be identical to the answer which is included in the reliable
> > > | response.
> > >
> > > Do you doubt this clarification?
> > > In my understanding, this has already reached the consensus in WG.
> >
> > [Gao] I am not want to *challenge* the consensus we have reached in
WG.
> > But as this draft is aims for clarification, not for normative
> > correction, I have no way to convince the *UAS*.
>
> (I just posted a related reply to a later message in this thread.)
>
> Whether this clarification is supported by the existing normative text
> is worthy of some careful thought.
>
> As I noted in the other reply, a UAS sending multiple *unreliable*
> responses with SDP must assume that some or all of them will be lost. If
> these SDPs have different values, and the UAC processes the first it
> receives, and ignores the rest, then the resulting behavior will be
> indeterminate.

Yes. So, I think finally using the real answer in the first reliable
response can making the final session determinate.
But in your case, UAC would have a indeterminate early media, depending on
which SDP is the one it first receives.

>
> IMO this is sufficient to infer that there is only one meaningful
> interpretation, so that a clarification is sufficient without a
> normative change.

I don't catch this point. Could you say it more.

Thanks,

Gao

>
> Thanks,
> Paul
>
> > >
> > > I'm confused.
> > > Do you have something a concrete proposal?
> >
> > [Gao] I think the original illegibility is from RFC3261. So, I sended
> > mails about it in SIPCore ML:
> >
> > http://www.ietf.org/mail-archive/web/sipcore/current/msg02315.html
> > http://www.ietf.org/mail-archive/web/sipcore/current/msg02328.html
> >
> > To be honest, I think there are two options here:
> > 1. Forbid different SDP(compare with the answer) before the answer
> > normatively.
> > 2. Allowing different SDP(compare with the answer) before the answer
> > normatively.
> >
> > >
> > > Just to be sure, this draft is not a normative document but
> > > an informational one as you no doubt know.
> >
> > [Gao] Sure, I know it is informative.
> >
> > >
> > > Regards,
> > > Shinji
> > >
> > > ***@zte.com.cn
> > > Fri, 9 Apr 2010 16:50:12 +0800
> > > >Hi Shinji,
> > > >
> > > >Thanks firstly.
> > > >
> > > >But the UAS do not think it throws the problem. RFC3261 said UAS
may
> > send
> > > >the same SDP before the answer, but there is not normative words
of to
> > > >forbid the different SDPs.
> > > >
> > > >And if the equipment has been in the network, unless we using the
> > evident
> > > >standard, we has no way to request their correction.
> > > >
> > > >Gao
> > > >
> > > >OKUMURA Shinji <***@softfront.jp>
> > > >·¢ŒþÈË: sipping-***@ietf.org
> > > >2010-04-09 16:30
> > > >
> > > >ÊÕŒþÈË
> > > >***@ietf.org
> > > >³­ËÍ
> > > >
> > > >Ö÷Ìâ
> > > >Re: [Sipping] About offeranswer draft:
> > > >
> > > >Hi Gao,
> > > >
> > > >In this case it is no doubt the UAS is a cause of the problem.
> > > >All you have to do is say "Your UAS is against the rules".
> > > >You will surely win the fight.
> > > >
> > > >Regards,
> > > >Shinji
> > > >
> > > >***@zte.com.cn
> > > >Fri, 9 Apr 2010 15:25:58 +0800
> > > >>Hi Shinji,
> > > >>
> > > >>By myself, I am OK with the three ways. But if there's no
normative
> > > >>definition here, there would be some interworking fight for this
issue.
> > > >>
> > > >>Thanks,
> > > >>
> > > >>Gao
> > > >>
> > > >>OKUMURA Shinji <***@softfront.jp>
> > > >>·¢ŒþÈË: sipping-***@ietf.org
> > > >>2010-04-09 14:23
> > > >>
> > > >>ÊÕŒþÈË
> > > >>***@ietf.org
> > > >>³­ËÍ
> > > >>
> > > >>Ö÷Ìâ
> > > >>Re: [Sipping] About offeranswer draft:
> > > >>
> > > >>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
> > > >>
> > > >>***@zte.com.cn
> > > >>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
> > earlymedia 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 <***@softfront.jp>
> > > >>>·¢ŒþÈË: sipping-***@ietf.org
> > > >>>2010-04-09 10:13
> > > >>>
> > > >>>ÊÕŒþÈË
> > > >>>***@ietf.org
> > > >>>³­ËÍ
> > > >>>
> > > >>>Ö÷Ìâ
> > > >>>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
> > > >>>
> > > >>>***@zte.com.cn
> > > >>>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,
> > Ithink 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-***@cs.columbia.edu for questions on current sip
> > > >Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
> > > Use ***@ietf.org for new developments of core SIP
> >
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in this
> mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated
> to maintain secrecy and are not permitted to disclose the contents
> of this communication to others.
> > This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please
> notify the originator of the message. Any views expressed in this
> message are those of the individual sender.
> > This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.
> >
> >
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-***@cs.columbia.edu for questions on current sip
> > Use ***@ietf.org for new developments of core SIP
>



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[Paul Kyzivat]

Inline.

***@zte.com.cn wrote:
>
>
> Paul Kyzivat <***@cisco.com> 写于 2010-04-14 22:23:57:
>
> > inline
> >
> > ***@zte.com.cn wrote:
> > >
> > > Hi Shinji,
> > >
> > > Please see inlines.
> > >
> > > Thanks,
> > >
> > > Gao
> > >
> > > sipping-***@ietf.org 写于 2010-04-12 10:55:47:
> > >
> > > > Hi Gao,
> > > >
> > > > The clarifications for the section 13.2.1 of RFC 3261 is
> > > > one of the major purposes in this draft.
> > > >
> > > > In the section 3.1 of this draft,
> > > > | 3.1. Offer/Answer for the INVITE method with 100rel extension
> > > > | (snip) All the session
> > > > | descriptions in the unreliable responses to the INVITE
> request must
> > > > | be identical to the answer which is included in the reliable
> > > > | response.
> > > >
> > > > Do you doubt this clarification?
> > > > In my understanding, this has already reached the consensus in WG.
> > >
> > > [Gao] I am not want to *challenge* the consensus we have reached in WG.
> > > But as this draft is aims for clarification, not for normative
> > > correction, I have no way to convince the *UAS*.
> >
> > (I just posted a related reply to a later message in this thread.)
> >
> > Whether this clarification is supported by the existing normative text
> > is worthy of some careful thought.
> >
> > As I noted in the other reply, a UAS sending multiple *unreliable*
> > responses with SDP must assume that some or all of them will be lost. If
> > these SDPs have different values, and the UAC processes the first it
> > receives, and ignores the rest, then the resulting behavior will be
> > indeterminate.
>
> Yes. So, I think finally using the real answer in the first reliable
> response can making the final session determinate.
> But in your case, UAC would have a indeterminate early media, depending
> on which SDP is the one it first receives.

Yes, finally using the SDP in the first reliable response *would* make
this case determinate. However, that has consequences - one of the
following:

- if the SDP from an unreliable response is used initially,
and then a different SDP from a reliable response is received,
there will be need to "switch" from the earlier to the later.
This switching (and even parsing of the SDP) is extra cost
that is unnecessary if the UAS behaves correctly and does not
change the SDP.

- the SDP from the unreliable responses might be ignored, so as
to avoid the need to switch. Instead simply wait for the reliable
response. For one, this is not permitted by the exiting text
(though it can be achieved by pretending to lose the unreliable
responses.) More important, this will delay the setup and use of
the media streams. This can be unacceptable.

All this is simply to provide determinacy for a non-conforming UAS. We
usually don't specify behavior in non-conforming cases. Rather we leave
it to implementations to decide.

> >
> > IMO this is sufficient to infer that there is only one meaningful
> > interpretation, so that a clarification is sufficient without a
> > normative change.
>
> I don't catch this point. Could you say it more.

My point was that the interpretation that permits the UAS to send
changed values of the SDP in unreliable provisionals and then the
reliable response leads to indeterminacy. Its nonsensical to believe the
spec intended to be indeterminate here. So the interpretation is not a
valid one. Rather, it should be excluded, leaving only the
interpretation that the UAS MUST send the same SDP in unreliable
responses and the subsequent reliable response.

But I have in another message confronted yet another interpretation you
apparently obtained from someone you deal with. Lets cap off this thread
here and pick it up in that one.

Thanks,
Paul
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for n

[g***@zte.com.cn]

correction:

Now, we also have other signal rules on O/A, such as sending
UPDATE(adding: with Offer) after the ini-O/A.




Christer Holmberg <***@ericsson.com>
2010-04-16 01:16

ÊÕŒþÈË
Paul Kyzivat <***@cisco.com>, "***@zte.com.cn"
<***@zte.com.cn>
³­ËÍ
"***@ietf.org" <***@ietf.org>, OKUMURA Shinji
<***@softfront.jp>
Ö÷Ìâ
RE: [Sipping] About offeranswer draft:






Hi,

>>Whether it's clearly specified somewhere needs to be checked, though.
>>
>>I know there are implementations that "update" the SDP answer from
>>one reliable response to another (within the same transaction), for
>>the same transaction, but that is certainly nothing we have
standardized.
>>
>I think it should be mentioned here, what is the *lawful* answer?
>It is the one in the first reliable response.

Agree. Whatever comes before that (unreliably), and after that (reliably
OR unreliably),
has no meaning.

>>As it is the *lawful* answer, I think the UAC should using it when it
>>get the answer. And this seems *should* be made normative.
>>While how UAC handle SDP(from UAS) before the real answer, it can be BCP
>>issue.
>
>I think you are arguing that it is "lawful" for the UAS to send
>differing values for the SDP successive unreliable responses and in the
>subsequent reliable response. And that it is then the responsibility of
>the UAC to make this work "right" and "deterministically" by honoring
>the first and ignoring the subsequent ones. Is that right?
>
>But that makes no sense. The UAS cannot know if the UAC will receive the
>first, or any of, the unreliable responses. So if it were to do this odd
>behavior it must be satisfied that *any* of then are the one that the
>UAC uses. Or else it must be assuming that the UAC *might* use one or
>more of the unreliable ones, and eventually *switch* to the one in the
>reliable response.
>
>But 3261 is clear that the UAC should use the first one it receives, and
>ignore the remainder, *including* the reliable one. There is no
>provision for *switching*.

Agree.

I am aware of implementations that, once they have received a reliable SDP
answer,
they don't even parse additional SDPs for the same transaction. So, they
don't even
know whether the additional SDPs are identical or not.

[Gao] Yes.
But when the UAC have received the SDP in one unreliable response, could
it ignore subsequent SDP, even the REAL ANSWER. By current RFC3261, it
should ignore subsequent SDP, even the REAL ANSWER.

Now, we also have other signal rules on O/A, such as sending UPDATE after
the ini-O/A. The key here is, IS the SDP (in unreliable before the real
ANSWER) answer?
If it is answer, then signal rules on O/A need to be corrected.
If it is not answer, the RFC3261's text seems need correction.

As O/A draft does not aim for normative correction, so I just feel it
seams need a normative one. I guess Paul has the prestige to draft such
text:)

>Hence, its a corollary that the only behavior that the UAC can follow
>that is valid and consistent in the face of loss of unreliable responses
>is for them all to contain the same SDP. So that is the *lawful*
>behavior - a UAS that violates this is unreasonable.

Yes.

Regards,

Christer



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.