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
