Re: About offeranswer draft:

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
> 
> [email protected]
> Mon, 12 Apr 2010 11:37:09 +0800
>> Hi Shinji,
>>
>> Please see inlines.
>>
>> Thanks,
>>
>> Gao
>>
>> [email protected] 写于 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
>>>
>>> [email protected]
>>> 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 <[email protected]> 
>>>> 发件人:  [email protected]
>>>> 2010-04-09 16:30
>>>>
>>>> 收件人
>>>> [email protected]
>>>> 抄送
>>>>
>>>> 主题
>>>> 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
>>>>
>>>> [email protected]
>>>> 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 <[email protected]> 
>>>>> 发件人:  [email protected]
>>>>> 2010-04-09 14:23
>>>>>
>>>>> 收件人
>>>>> [email protected]
>>>>> 抄送
>>>>>
>>>>> 主题
>>>>> 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
>>>>>
>>>>> [email protected]
>>>>> 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 <[email protected]> 
>>>>>> 发件人:  [email protected]
>>>>>> 2010-04-09 10:13
>>>>>>
>>>>>> 收件人
>>>>>> [email protected]
>>>>>> 抄送
>>>>>>
>>>>>> 主题
>>>>>> 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
>>>>>>
>>>>>> [email protected]
>>>>>> 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 [email protected] for questions on current sip
> Use [email protected] 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 [email protected] for questions on current sip
Use [email protected] for new developments of core SIP