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
