Re: [Sipping] About offeranswer draft:

[OKUMURA Shinji <shinji.okumura@xxxxxxxxxxxx>]

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

gao.yang2@xxxxxxxxxx
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 <shinji.okumura@xxxxxxxxxxxx> 
>发件人:  sipping-bounces@xxxxxxxx
>2010-04-09 16:30
>
>收件人
>sipping@xxxxxxxx
>抄送
>
>主题
>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
>
>gao.yang2@xxxxxxxxxx
>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 <shinji.okumura@xxxxxxxxxxxx> 
>>发件人:  sipping-bounces@xxxxxxxx
>>2010-04-09 14:23
>>
>>收件人
>>sipping@xxxxxxxx
>>抄送
>>
>>主题
>>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
>>
>>gao.yang2@xxxxxxxxxx
>>Fri, 9 Apr 2010 11:44:34 +0800
>>>Hi,
>>>
>>>Yes, considering implementation, I also find the three ways, especially 
>>>for the last two ways.
>>>
>>>My original thought is make clarification on the third one("3. change to 
>>>the SDP in a reliable response"), by RFC3264's rule.
>>>
>>>In fact, I think by rules, the UAC should modify the session as it is the 
>>>lawful answer. Using early media by the SDP prior to the lawful answer is 
>>>something outside of the lawful rules(Reliably way of using early media is 
>>>Answer in 100rel). 
>>>
>>>So, I think using or just discarding the SDP prior to the lawful answer is 
>>>something depends on implementation. While "change to the SDP in a 
>>>reliable response" should be normative.
>>>
>>>Thanks,
>>>
>>>Gao
>>>
>>>OKUMURA Shinji <shinji.okumura@xxxxxxxxxxxx> 
>>>发件人:  sipping-bounces@xxxxxxxx
>>>2010-04-09 10:13
>>>
>>>收件人
>>>sipping@xxxxxxxx
>>>抄送
>>>
>>>主题
>>>Re: [Sipping] About offeranswer draft:
>>>
>>>Hi Gao,
>>>
>>>I have no doubt that the different SDP in non-reliable response
>>>violates current regulations.
>>>
>>>The behaviour of UAC is an implementation issue, I think.
>>>When UAS receives the different SDP in a reliable response from
>>>the prior one in a non-reliable response, UAS may ...
>>>1. terminate the session.
>>>2. keep using the SDP in a non-reliable response.
>>>3. change to the SDP in a reliable response.
>>>
>>>It is not clear, but it is not a regular case.
>>>
>>>Regards,
>>>Shinji
>>>
>>>gao.yang2@xxxxxxxxxx
>>>Wed, 7 Apr 2010 11:14:07 +0800
>>>>Hi Paul,
>>>>
>>>>While considering one problem in our production's interoperability 
>>>>testing, I re-read some parts of offeranswer draft and find something 
>>>>might be deserving discussion.
>>>>
>>>>//begin of text(part):
>>>>   For example, in Figure 1, only the SDP in F6 is the answer.  The SDP
>>>>   in the non-reliable response (F2) is the preview of the answer and
>>>>   must be the same as the answer in F6.  Receiving F2, the UAC should
>>>>   act as if it receives the answer.
>>>>//end of text(part)
>>>>
>>>>[Gao] In fact, UAS sending SDP in non-reliable response is for potential 
>>>>early media usage. Considering some UAS may have different address for 
>>>>early media channel and the final session, some UAS may send different 
>>>>SDP(compare with the answer) in non-reliable response. And I really found 
>>>>such equipment inside and outside of ZTE. And considering UAC, I think we 
>>>>should allow the UAC ignore the SDP in non-reliable response, while some 
>>>>UAC really do not handle any SDP which is not offer or answer. 
>>>>
>>>>But the permissibility of the degree of the difference might be delicate. 
>>>>If the non-answer SDP just has different ip address or port, it seams OK. 
>>>>If the non-answer SDP has different media streams, it would be hard to 
>>>>handle for UAC.
>>>>
>>>>
>>>>And I re-read correlative part of RFC3261. I don't know that whether 
>>>>allowing different SDP(compare with the answer) in non-reliable response 
>>>>is violation/correction of current text or not.
>>>>
>>>>//correlative part of RFC3261
>>>>      o  If the initial offer is in an INVITE, the answer MUST be in a
>>>>         reliable non-failure message from UAS back to UAC which is
>>>>         correlated to that INVITE.  For this specification, that is
>>>>         only the final 2xx response to that INVITE.  That same exact
>>>>         answer MAY also be placed in any provisional responses sent
>>>>         prior to the answer.  The UAC MUST treat the first session
>>>>         description it receives as the answer, and MUST ignore any
>>>>         session descriptions in subsequent responses to the initial
>>>>         INVITE.
>>>>
>>>>Thanks,
>>>>
>>>>Gao
>
>_______________________________________________
>Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
>Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP