答复: Re: 答复: RE: Re: 答复: Re: 答复: Re: PRACK: Change MUST requirement to include SDP offer in first reliable provisional response
Hi,
I just mean:
All the usage can be used in PRACK,
we call it Set.
By current RFC3262, can be used in PRACK,
we call it SubSet1.
SubSet1 is very small. And if we do
usage beyond SubSet1, the termination of session is acceptable (for me).
So, I recommend
that the UAS return a 200 when it has not been able to process the PRACK
due to an error, then terminate the session.
About authorization, I think, we can do authorization
in PRACK(It is a choice, not mandatory thing.), but we should do not do
it in PRACK by current RFC3262.
If people want to enrich SubSet1, I think
it is needed to modify RFC3262 and find a way to solve the problem.
Thanks
Gao
Paul Kyzivat <pkyzivat@xxxxxxxxx> 写于 2009-04-08
20:04:27:
>
>
> gao.yang2@xxxxxxxxxx wrote:
> >
> > Please see the previous mail:
> >
> > as UAS MUST return 2xx, then we can *deduce* that it is UAC's
obligation
> > to make sure UAS will accept the PRACK.
>
> I think that in general we can presume that the UAC doesn't *expect*
> that its PRACK will be rejected. Yet the PRACK can fail for no fault
on
> the part of the UAC, and no fault on the part of the UAS either.
>
> I've already given the example of authorization failure.
>
> Its simply a faulty spec that presumes it can ignore the possibility
of
> errors. All we are trying to do is *fix* that so that things will
> continue to function in a predictable way in the face of an error.
>
> Would you honestly recommend that the UAS return a 200 when it has
not
> been able to process the PRACK due to an error?
>
> Thanks
> Paul
>
> > *"Christer Holmberg" <christer.holmberg@xxxxxxxxxxxx>*
> >
> > 2009-04-08 13:39
> >
> >
> > 收件人
> > <gao.yang2@xxxxxxxxxx>, "Paul Kyzivat"
<pkyzivat@xxxxxxxxx>
> > 抄送
> > <sipping@xxxxxxxx>, <sipping-bounces@xxxxxxxx>,
"Rockson Li (zhengyli)"
> > <zhengyli@xxxxxxxxx>
> > 主题
> > RE: Re: 答复: Re: 答复: Re: [Sipping] PRACK:
Change MUST requirement to
> > include SDP offer in first reliable provisional response
> >
> >
> >
> >
> >
> >
> >
> >
> > What PRACK usages are we adding???
> >
> > We are talking about being allowed to send a non-200 response
to a
> > PRACK, and how to deal with it.
> >
> > Regards,
> >
> > Christer
> >
> > ------------------------------------------------------------------------
> > *From:* gao.yang2@xxxxxxxxxx [mailto:gao.yang2@xxxxxxxxxx] *
> > Sent:* 8. huhtikuuta 2009 8:23*
> > To:* Paul Kyzivat*
> > Cc:* Christer Holmberg; sipping@xxxxxxxx; sipping-bounces@xxxxxxxx;
> > Rockson Li (zhengyli)*
> > Subject:* 答复: Re: 答复: Re: 答复: Re: [Sipping] PRACK:
Change MUST
> > requirement to include SDP offer in first reliable provisional
response
> >
> >
> > Hi
> >
> > inline:)
> >
> >
> > Paul Kyzivat <pkyzivat@xxxxxxxxx> 写于 2009-04-08 12:37:40:
> >
> > >
> > >
> > > gao.yang2@xxxxxxxxxx wrote:
> > > >
> > > > I do not think it is naivety of RFC3262.
> > > >
> > > > In theory, there are cases that UAS(PRACK's UAS)
should return
> > non-2xx,
> > > > as there is no explicit regulation of what can
be in PRACK or not.
> > > >
> > > > But as UAS MUST return 2xx, then we can *deduce*
that it is UAC's
> > > > obligation to make sure UAS will accept the PRACK.
If UAS do not obey
> > > > this, UAC can terminate the session. And if UAS
want to issue a
> > > > modification of session which may be rejected
by UAC, it can use
> > UPDATE
> > > > later.
> > >
> > > You have an opinion of what the UAS needs to do to
resolve the
> > > inadequacies of 3262, and I have a different opinion
about that. That is
> > > why we are discussing it. And I expect there are yet
other opinions.
> > > That is why we are discussing it.
> > >
> > > IMO there are cases where a non-2xx response is called
for, and
> > > terminating the session is an unreasonable remedy.
The one I have given
> > > is where an Authorization header is included but the
nonce has expired.
> > > There is no other way for the UAC to learn that it
needs a new nonce,
> > > and having the session fail in that case is unreasonable.
I'm sure there
> > > are other cases as well.
> > >
> >
> > [Gao] If we adding more usage to PARCK, I'm sure there are other
cases
> > as well too.
> > My point is that we can do the thing with another UPDATE, while
not the
> > PRACK.
> >
> > I think this is not a dialectic problem, it is just choice. So,
I would
> > not stick to my personal ponit of view if people want to making
PRACK
> > with more usage.
> >
> >
> > > > Considering UAC, it can judge from the 4xx to
terminate the
> > session(such
> > > > as 481), or send a new PRACK.
> > >
> > > If you acknowledge that the UAS may have need to send
a non-2xx
> > > response, and the UAC may then want to retransmit
the PRACK, then it
> > > seems you are agreeing with me.
> > >
> > > > And the process mentioned above just obeys RFC3262,
and it practical
> > > > enough for the usage.
> > > > I can accept the UAC *judging from the 4xx to
terminate the
> > session(such
> > > > as 481), or send a new PRACK. But I think considering
the UAS
> > rejecting
> > > > the PRACK and retransmiting 18x(100rel) would
make the problem too
> > > > complex.
> > >
> > > What is so hard?
> >
> > [Gao] No hard, just complex :)
> >
> > >
> > > Thanks,
> > > Paul
> > >
> > > > Thanks
> > > > Gao
> > > >
> > > >
> > > >
> > > > *Paul Kyzivat <pkyzivat@xxxxxxxxx>*
> > > >
> > > > 2009-04-07 20:59
> > > >
> > > >
> > > > 收件人
> > > > gao.yang2@xxxxxxxxxx
> > > > 抄送
> > > > Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>,
> > sipping@xxxxxxxx,
> > > > sipping-bounces@xxxxxxxx, "Rockson Li (zhengyli)"
<zhengyli@xxxxxxxxx>
> > > > 主题
> > > > Re: 答复: Re: [Sipping] PRACK:
Change MUST requirement to
> > include SDP
> > > > offer in first reliable provisional response
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > We could write in an RFC that lead must be turned
into gold, but
> > when it
> > > > came time to implement that it would be discovered
that it wasn't
> > > > feasible to always follow the RFC.
> > > >
> > > > The quotes below reflect a similar degree of
naivety in 3262, at least
> > > > regarding the responses to PRACK. Plenty of examples
have been given of
> > > > cases where it is inappropriate to return a 200
response.
> > > >
> > > > The statement that retransmissions shall cease
when the matching PRACK
> > > > is received is, IMO, predicated on the assumption
that a 200 will
> > always
> > > > be returned. Once you reverse that assumption,
then you must also
> > > > reconsider this statement.
> > > >
> > > >
Thanks,
> > > >
Paul
> > > >
> > > >
> > > > gao.yang2@xxxxxxxxxx wrote:
> > > > >
> > > > > More points of view to this question:
> > > > >
> > > > > By RFC3262:
> > > > > 1. "Retransmissions of the reliable
provisional response cease
> > when a
> > > > > matching PRACK is received by the
UA core."
> > > > >
> > > > > 2. "If the PRACK does match an
unacknowledged reliable provisional
> > > > > response, it MUST be responded to
> > > > > with a 2xx response."
> > > > >
> > > > > So, when UAs receive a matching PRACK,
it will stop re-transmit the
> > > > > reliable provisional response(18x).
And the response
> > > > > to PRACK MUST be 2xx.
> > > > >
> > > > > It is simple and clear. And when UAs
receive non-2xx response to
> > PRACK,
> > > > > it is clear that the other side do
not receive the
> > > > > PRACK. It can send a new PRACK(CSeq++,
the same RAck).
> > > > >
> > > > > And now, we can use PRACK to send
"precondition notification"
> > and "codec
> > > > > refine". When we need to issue
session modification like adding
> > codec,
> > > > > adding/removing media streams, we
MUST using Re-INVITE/UPDATE.
> > > > >
> > > > > I think we should not re-write RFC3262
to allow the UA to reject
> > the
> > > > PRACK.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > *Paul Kyzivat <pkyzivat@xxxxxxxxx>*
> > > > > 发件人: sipping-bounces@xxxxxxxx
> > > > >
> > > > > 2009-04-06 20:16
> > > > >
> > > > >
> > > > > 收件人
> > > > >
"Rockson Li (zhengyli)" <zhengyli@xxxxxxxxx>
> > > > > 抄送
> > > > >
sipping@xxxxxxxx, Christer Holmberg
> > > > <christer.holmberg@xxxxxxxxxxxx>
> > > > > 主题
> > > > >
Re: [Sipping] PRACK: Change MUST requirement
to
> > > > include SDP offer in
> > > > > first reliable
provisional response
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I think I also agree. There are a
lot of things that in hindsight we
> > > > > probably would have done differently.
But that is water over the
> > dam. We
> > > > > are where we are.
> > > > >
> > > > >
Paul
> > > > >
> > > > > Rockson Li (zhengyli) wrote:
> > > > > > I totally agree with Hadriel's
insight here.
> > > > > >
> > > > > > It should have been avoided
to put too many jobs into PRACK,
> > > > > >
> > > > > > I miss KISS(Keep It Simple
and Stupid) principle
> > > > > >
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > -Rockson
> > > > > >
> > > > > >
> > > >
> > ------------------------------------------------------------------------
> > > > > > *From:* sipping-bounces@xxxxxxxx
> > [mailto:sipping-bounces@xxxxxxxx] *On
> > > > > > Behalf Of *Hadriel Kaplan
> > > > > > *Sent:* Tuesday, March
31, 2009 9:50 PM
> > > > > > *To:* Christer Holmberg;
sipping@xxxxxxxx
> > > > > > *Subject:* Re: [Sipping]
PRACK: Change MUST requirement to
> > include SDP
> > > > > > offer in first reliable
provisional response
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > In hindsight I’m thinking
we probably also shouldn’t have
> > made the SDP
> > > > > > answer (or another offer)
required or even possible in the PRACK
> > > > > > either. I think it
should have been for one and only one
> > purpose: to
> > > > > > acknowledge receipt of
the provisional response.
> > > > > >
> > > > > >
> > > > > >
> > > > > > -hadriel
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > ------------------------------------------------------------------------
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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
> > > > >
> > > > >
> > > > > --------------------------------------------------------
> > > > > ZTE Information Security Notice: The
information contained in this
> > > > mail is solely property of the sender's organization.
This mail
> > > > communication is confidential. Recipients named
above are obligated to
> > > > maintain secrecy and are not permitted to disclose
the contents of
> > this
> > > > communication to others.
> > > > > This email and any files transmitted
with it are confidential and
> > > > intended solely for the use of the individual
or entity to whom
> > they are
> > > > addressed. If you have received this email in
error please notify the
> > > > originator of the message. Any views expressed
in this message are
> > those
> > > > of the individual sender.
> > > > > This message has been scanned for
viruses and Spam by ZTE Anti-Spam
> > > > system.
> > > >
> > > >
> > > > --------------------------------------------------------
> > > > ZTE Information Security Notice: The information
contained in this
> > > mail is solely property of the sender's organization.
This mail
> > > communication is confidential. Recipients named above
are obligated
> > > to maintain secrecy and are not permitted to disclose
the contents
> > > of this communication to others.
> > > > This email and any files transmitted with it
are confidential and
> > > intended solely for the use of the individual or entity
to whom they
> > > are addressed. If you have received this email in
error please
> > > notify the originator of the message. Any views expressed
in this
> > > message are those of the individual sender.
> > > > This message has been scanned for viruses and
Spam by ZTE Anti-Spam
> > system.
> >
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in
this mail
> > is solely property of the sender's organization. This mail communication
> > is confidential. Recipients named above are obligated to maintain
> > secrecy and are not permitted to disclose the contents of this
> > communication to others.
> > This email and any files transmitted with it are confidential
and
> > intended solely for the use of the individual or entity to whom
they are
> > addressed. If you have received this email in error please notify
the
> > originator of the message. Any views expressed in this message
are those
> > of the individual sender.
> > This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.
> >
> >
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in
this
> mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated
> to maintain secrecy and are not permitted to disclose the contents
> of this communication to others.
> > This email and any files transmitted with it are confidential
and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please
> notify the originator of the message. Any views expressed in this
> message are those of the individual sender.
> > This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
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
[IETF Announce]
[IETF Discussion]
[Linux SCSI]
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]
[Photo]
[Yosemite News]
[Yosemite Photos]
[Free Online Dating]
[Linux Kernel]
[Linux SCSI]
[XFree86]
[Big List of Linux Books]
