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
gao.yang2@xxxxxxxxxx
Mon, 12 Apr 2010 11:37:09 +0800
Hi Shinji,
Please see inlines.
Thanks,
Gao
sipping-bounces@xxxxxxxx 写于 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
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 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 <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, 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-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
