[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Current status of response to 3gpp Liaison Statement on offer/answer procedures
Copying Robert. I think his input on this would be invaluable.
This is exactly the sort of response I was hoping to get to my proposal.
It really needs to be carefully vetted.
Comments inline.
Paul
Ian Elz wrote:
Paul,
I have two potential issues with the rules you have mentioned below.
Sorry for the delay in replying to your email but I have taken some vacation and one of the possible issues has just been noticed.
1. Regarding rule 2.
I am assuming that in this rule the UAC not sending an UPDATE also applies after any retransmission of the ACK due to receipt of a 200 OK retransmission. Perhaps this should be explicitly stated.
What I had in mind was that UPDATE couldn't be used until all
retransmissions of the ACK has completed. So it would be 32 seconds.
Since it is quite possible that there will be need of a new O/A within
that period (e.g. because the UAC goes on hold quickly), the UAC will
have to be prepared to use alternative means (reINVITE). The net effect
is probably that the UAC will *never* use UPDATE for O/A outside of an
invite transaction.
I will preface by stating that this is an unlikely scenario but it can and will occur.
The UAC is not allowed to send an UPDATE until after sending an ACK until the timer has expired. In the UAS the timer for receipt of an ACK is based upon T1 with the 200 OK being resent at 2 * T1, 4 * T1, 8 * T1 etc until 64 * T1. With the recommended value of T1 (0.5 s) then the timer is 32 s.
The setting of T1 however is only recommended and the value of T1 on the UAS may be different than as set on the UAC. If the UAS has its T1 set 4 X or greater than the T1 of the UAC then there may be an issue.
I will explain by showing the 200 OK retransmission times from the UAS.
T1 value 0.5 1 2 4
1st Retransmission 1 2 4 8
2nd retransmission 2 4 8 16
3rd retransmission 4 8 16 32
4th retransmission 8 16 32 64
5th retransmission 16 32 64 128
If the UAC has T1 set to 0.5 seconds then there are retransmission intervals which are equal to or greater than the ACK timer when the UAS T1 value is 2 seconds or greater. This could cause an issue.
This may be prevented by making recommendations about timer setting.
I don't know much about the timers. It has always baffled me that we
allow them to be changed. Its my impression that all bets are off if the
two ends of a transaction don't have the same timer values.
2. Regarding rule 1
This prevents the UAS from sending an UPDATE as part of a re-INVITE transaction.
We have come across a case for an initial INVITE where it becomes necessary for the UAS to send an early dialog UPDATE which may also be applicable in a re-INVITE case. I am not sure if it is applicable for a re-INVITE but others may be able to advise.
When a SIP INVITE pasified; );
Cc: sipping <sipping at ietf.org>, Mary Barnes <mary.barnes at nortel.com>,
Gonzalo Camarillo <gonzalo.camarillo at ericsson.com>
Subject: Re: [Sipping] Current status of response to 3gpp Liaison Statement
on offer/answer procedures
X-BeenThere: sipping at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>,
<mailto:sipping-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sipping>
List-Post: <mailto:sipping at ietf.org>
List-Help: <mailto:sipping-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>,
<mailto:sipping-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: sipping-bounces at ietf.org
Errors-To: sipping-bounces at ietf.org
Copying Robert. I think his input on this would be invaluable.
This is exactly the sort of response I was hoping to get to my proposal.
It really needs to be carefully vetted.
Comments inline.
Paul
Ian Elz wrote:
Paul,
I have two potential issues with the rules you have mentioned below.
Sorry for the delay in replying to your email but I have taken some vacation and one of the possible issues has just been noticed.
1. Regarding rule 2.
I am assuming that in this rule the UAC not sending an UPDATE also applies after any retransmission of the ACK due to receipt of a 200 OK retransmission. Perhaps this should be explicitly stated.
What I had in mind was that UPDATE couldn't be used until all
retransmissions of the ACK has completed. So it would be 32 seconds.
Since it is quite possible that there will be need of a new O/A within
that period (e.g. because the UAC goes on hold quickly), the UAC will
have to be prepared to use alternative means (reINVITE). The net effect
is probably that the UAC will *never* use UPDATE for O/A outside of an
invite transaction.
I will preface by stating that this is an unlikely scenario but it can and will occur.
The UAC is not allowed to send an UPDATE until after sending an ACK until the timer has expired. In the UAS the timer for receipt of an ACK is based upon T1 with the 200 OK being resent at 2 * T1, 4 * T1, 8 * T1 etc until 64 * T1. With the recommended value of T1 (0.5 s) then the timer is 32 s.
The setting of T1 however is only recommended and the value of T1 on the UAS may be different than as set on the UAC. If the UAS has its T1 set 4 X or greater than the T1 of the UAC then there may be an issue.
I will explain by showing the 200 OK retransmission times from the UAS.
T1 value 0.5 1 2 4
1st Retransmission 1 2 4 8
2nd retransmission 2 4 8 16
3rd retransmission 4 8 16 32
4th retransmission 8 16 32 64
5th retransmission 16 32 64 128
If the UAC has T1 set to 0.5 seconds then there are retransmission intervals which are equal to or greater than the ACK timer when the UAS T1 value is 2 seconds or greater. This could cause an issue.
This may be prevented by making recommendations about timer setting.
I don't know much about the timers. It has always baffled me that we
allow them to be changed. Its my impression that all bets are off if the
two ends of a transaction don't have the same timer values.
2. Regarding rule 1
This prevents the UAS from sending an UPDATE as part of a re-INVITE transaction.
We have come across a case for an initial INVITE where it becomes necessary for the UAS to send an early dialog UPDATE which may also be applicable in a re-INVITE case. I am not sure if it is applicable for a re-INVITE but others may be able to advise.
When a SIP INVITE passes via ses via an MGC to an ISDN connection the IP address and port to be used can be controlled by the ISDN PBX. When the ISDN bearer identity is provided by the ISDN terminal, in an Alerting signal, the MGC may change the ephemeral (& possibly H.248 context). If we have an INVITE sequence involving preconditions the extended INVITE sequence occurs with an UPDATE from the UAC to confirm reservation of resources. As an immediate response is required to this UPDATE the UAS can only respond with the IP address and port of the H.248 ephemeral that it selected initially. In the ALERTING response to the SETUP request the ISDN terminal specifies a bearer which may result in a different the IP address and/or port. This requires that the UAS sends a further UPDATE with a modified sdp offer to change the IP address and/or port prior to sending the 200 OK.
While this scenario can occur for an initial INVITE it may also be possible for a re-INVITE; e.g. when a new media type is added to an existing session.
I am uncertain as to whether this will occur in this situation and I would welcome input from the list to show that it cannot.
My point was that while an invite/reinvite is in progress, any offer the
UAS might want to send in an UPDATE can instead be sent in a reliable
provisional response.
This *does* present a problem if the UAC supports UPDATE but doesn't
support reliable provisional responses. Is that an important case? Does
anybody do that?
If we must deal with the case where a UAC doesn't support 100rel, but
does support UPDATE, then this proposal won't work. If so, I don't
currently have any alternative.
Paul
Ian Elz
System Manager
DUCI LDC UK
(Lucid Duck)
Office: + 44 24 764 35256
gsm: +44 7801723668
ian.elz at ericsson.com
-----Original Message-----
From: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] On Behalf Of Paul Kyzivat
Sent: 03 July 2008 15:57
To: sipping
Cc: Mary Barnes; Gonzalo Camarillo
Subject: Re: [Sipping] Current status of response to 3gpp Liaison Statement on offer/answer procedures
I have been thinking about how we might solve the UPDATE ambiguity issue
which the MULTI-OA-TRANSACTION has. I have a potential solution, which
involves the following new restrictions:
1) A UAS for a reINVITE MUST NOT send UPDATE requests
within the scope of that INVITE. It must refrain from sending
UPDATE until it has received an ACK for the INVITE.
Note that this isn't much of a restriction, since the same things
can be accomplished with reliable provisional responses before
the INVITE completes, and reINVITE can be used after sending a
final response. The only limitation I can see is if reliable
provisionals are not being used and yet a change is desired
before completion of the INVITE. But I doubt that is a realistic
case.
2) A UAC for an INVITE or reINVITE MUST NOT send an UPDATE request
immediately *after* the completion of the INVITE. It must refrain
until the timer has expired on the ACK. (I forget which timer that
is.)
This also isn't much of a restriction. Anything that can be done
by the UPDATE can also be done with a reINVITE.
With these restrictions, the recipient of an UPDATE never has any
question of whether it should be part of the prior INVITE or not. To be
sure, lets cover the cases:
UAC (for the INVITE):
- An UPDATE that was legally sent by the UAS will arrive after the
final response for the INVITE is received and the ACK sent.
It will be unaffected by failure of the prior reINVITE.
- There is no possibility that a legally sent UPDATE will arrive
before the final response. If one arrives it must have been sent
by a UAS not compliant to these new rules. If one does arrive,
I propose that it be assumed to have been sent within the
INVITE, and hence be rolled back if the INVITE eventually fails.
- Theran MGC to an ISDN connection the IP address and port to be used can be controlled by the ISDN PBX. When the ISDN bearer identity is provided by the ISDN terminal, in an Alerting signal, the MGC may change the ephemeral (& possibly H.248 context). If we have an INVITE sequence involving preconditions the extended INVITE sequence occurs with an UPDATE from the UAC to confirm reservation of resources. As an immediate response is required to this UPDATE the UAS can only respond with the IP address and port of the H.248 ephemeral that it selected initially. In the ALERTING response to the SETUP request the ISDN terminal specifies a bearer which may result in a different the IP address and/or port. This requires that the UAS sends a further UPDATE with a modified sdp offer to change the IP address and/or port prior to sending the 200 OK.
While this scenario can occur for an initial INVITE it may also be possible for a re-INVITE; e.g. when a new media type is added to an existing session.
I am uncertain as to whether this will occur in this situation and I would welcome input from the list to show that it cannot.
My point was that while an invite/reinvite is in progress, any offer the
UAS might want to send in an UPDATE can instead be sent in a reliable
provisional response.
This *does* present a problem if the UAC supports UPDATE but doesn't
support reliable provisional responses. Is that an important case? Does
anybody do that?
If we must deal with the case where a UAC doesn't support 100rel, but
does support UPDATE, then this proposal won't work. If so, I don't
currently have any alternative.
Paul
Ian Elz
System Manager
DUCI LDC UK
(Lucid Duck)
Office: + 44 24 764 35256
gsm: +44 7801723668
ian.elz at ericsson.com
-----Original Message-----
From: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] On Behalf Of Paul Kyzivat
Sent: 03 July 2008 15:57
To: sipping
Cc: Mary Barnes; Gonzalo Camarillo
Subject: Re: [Sipping] Current status of response to 3gpp Liaison Statement on offer/answer procedures
I have been thinking about how we might solve the UPDATE ambiguity issue
which the MULTI-OA-TRANSACTION has. I have a potential solution, which
involves the following new restrictions:
1) A UAS for a reINVITE MUST NOT send UPDATE requests
within the scope of that INVITE. It must refrain from sending
UPDATE until it has received an ACK for the INVITE.
Note that this isn't much of a restriction, since the same things
can be accomplished with reliable provisional responses before
the INVITE completes, and reINVITE can be used after sending a
final response. The only limitation I can see is if reliable
provisionals are not being used and yet a change is desired
before completion of the INVITE. But I doubt that is a realistic
case.
2) A UAC for an INVITE or reINVITE MUST NOT send an UPDATE request
immediately *after* the completion of the INVITE. It must refrain
until the timer has expired on the ACK. (I forget which timer that
is.)
This also isn't much of a restriction. Anything that can be done
by the UPDATE can also be done with a reINVITE.
With these restrictions, the recipient of an UPDATE never has any
question of whether it should be part of the prior INVITE or not. To be
sure, lets cover the cases:
UAC (for the INVITE):
- An UPDATE that was legally sent by the UAS will arrive after the
final response for the INVITE is received and the ACK sent.
It will be unaffected by failure of the prior reINVITE.
- There is no possibility that a legally sent UPDATE will arrive
before the final response. If one arrives it must have been sent
by a UAS not compliant to these new rules. If one does arrive,
I propose that it be assumed to have been sent within the
INVITE, and hence be rolled back if the INVITE eventually fails.
- There is no e is no possibility that a legally sent UPDATE will arrive
after the receipt of a failing final response, and before any
ACK has been sent. If one arrives it must have been sent
by a UAS not compliant to these new rules. If one does arrive,
I propose that it be assumed to have been sent after the
final response, and hence not be subject to rollback.
UAS (for the INVITE):
- An UPDATE that is received before the final response to the
INVITE has been sent is assumed to belong within the INVITE.
If the final response is a failure, then any o/a effects of
the UPDATE will be rolled back.
- An UPDATE that is received after the final response to the
INVITE has been sent, but before the ACK has been received,
is assumed to have been sent before the final response was
received. Hence it is subject to rollback if the final response
was failure. Since it hasn't yet been processed, and is to be
rolled back, the response to it should be an error - perhaps
487.
I think the above will resolve the issue and be interoperable with
current implementations except in cases of message reordering. I doubt
we can do any better than that.
Thanks,
Paul
Paul Kyzivat wrote:
Some time ago 3gpp requested liaison regarding offer/answer procedures.
The liaison document may be found at:
https://datatracker.ietf.org/liaison/444/
Information about the discussion can be found at:
http://www.ietf.org/mail-archive/web/sipping/current/msg15771.html
Some of us (especially Christer and I) have been discussing this
privately. Mary has asked for a clarification of the current status to
the group. This is my attempt to do so:
To summarize the issue:
- Assume one issues a re-INVITE,
- and that results in multiple offer/answer exchanges
(via PRACK and UPDATE) prior to the completion of
the re-INVITE,
- and then the re-INVITE *fails* (response >= 300)
Then in what state is the session left, with regard to SDP and media
sessions?
None of the RFCs clearly cover this case. The offer/answer draft touched
on it, but is not normative and so could not resolve it.
We have concluded that there are two plausible ways of treating this:
MULTI-OA-TRANSACTION:
The re-INVITE, and all the offers/answers that take place within
its scope, are treated as a transaction. All succeed or fail
together based on the outcome of the re-INVITE. So, if the
re-INVITE fails, then the media state reverts to what it had been
before the re-INVITE began.
SINGLE-OA-TRANSACTION:
Each time an answer is transmitted *reliably*, that is considered
final, regardless of what happens subsequently. A failure of the
re-INVITE only rolls back an offer that offer that was not reliably
answered prior to the failure response.
The merits of MULTI-OA-TRANSACTION:
The advantage of the MULTI-OA-TRANSACTION approach is that it aligns
with a real need. In some cases it is necessary to do multiple o/a
exchanges to transition from one stable state to another.
A clear example of this is when preconditions are used. Multiple
exchanges are required to resolve the preconditions, and the
intermediate states may not be useful for exchanging media. The ultimate
failure is likely an indication that the preconditions could not be
resolved. Rolling back to the state prior to the re-INVITE cleanly
resolves this.
A key to making this work is, when a re-INVITE failure occurs, the UAC
and UAS must agree on on which offers and answers were part of the
re-INVITE and hence must be rolled back. Those carried in the re-INVITE
itself, its responses, in PRACKs, and in the ACK, are clearly within the
scope of the re-INVITE. The UPDATEs that are sent within the scope of
the re-INVITE also must be included, but in that case there is a
problem. When an UPDATpossibility that a legally sent UPDATE will arrive
after the receipt of a failing final response, and before any
ACK has been sent. If one arrives it must have been sent
by a UAS not compliant to these new rules. If one does arrive,
I propose that it be assumed to have been sent after the
final response, and hence not be subject to rollback.
UAS (for the INVITE):
- An UPDATE that is received before the final response to the
INVITE has been sent is assumed to belong within the INVITE.
If the final response is a failure, then any o/a effects of
the UPDATE will be rolled back.
- An UPDATE that is received after the final response to the
INVITE has been sent, but before the ACK has been received,
is assumed to have been sent before the final response was
received. Hence it is subject to rollback if the final response
was failure. Since it hasn't yet been processed, and is to be
rolled back, the response to it should be an error - perhaps
487.
I think the above will resolve the issue and be interoperable with
current implementations except in cases of message reordering. I doubt
we can do any better than that.
Thanks,
Paul
Paul Kyzivat wrote:
Some time ago 3gpp requested liaison regarding offer/answer procedures.
The liaison document may be found at:
https://datatracker.ietf.org/liaison/444/
Information about the discussion can be found at:
http://www.ietf.org/mail-archive/web/sipping/current/msg15771.html
Some of us (especially Christer and I) have been discussing this
privately. Mary has asked for a clarification of the current status to
the group. This is my attempt to do so:
To summarize the issue:
- Assume one issues a re-INVITE,
- and that results in multiple offer/answer exchanges
(via PRACK and UPDATE) prior to the completion of
the re-INVITE,
- and then the re-INVITE *fails* (response >= 300)
Then in what state is the session left, with regard to SDP and media
sessions?
None of the RFCs clearly cover this case. The offer/answer draft touched
on it, but is not normative and so could not resolve it.
We have concluded that there are two plausible ways of treating this:
MULTI-OA-TRANSACTION:
The re-INVITE, and all the offers/answers that take place within
its scope, are treated as a transaction. All succeed or fail
together based on the outcome of the re-INVITE. So, if the
re-INVITE fails, then the media state reverts to what it had been
before the re-INVITE began.
SINGLE-OA-TRANSACTION:
Each time an answer is transmitted *reliably*, that is considered
final, regardless of what happens subsequently. A failure of the
re-INVITE only rolls back an offer that offer that was not reliably
answered prior to the failure response.
The merits of MULTI-OA-TRANSACTION:
The advantage of the MULTI-OA-TRANSACTION approach is that it aligns
with a real need. In some cases it is necessary to do multiple o/a
exchanges to transition from one stable state to another.
A clear example of this is when preconditions are used. Multiple
exchanges are required to resolve the preconditions, and the
intermediate states may not be useful for exchanging media. The ultimate
failure is likely an indication that the preconditions could not be
resolved. Rolling back to the state prior to the re-INVITE cleanly
resolves this.
A key to making this work is, when a re-INVITE failure occurs, the UAC
and UAS must agree on on which offers and answers were part of the
re-INVITE and hence must be rolled back. Those carried in the re-INVITE
itself, its responses, in PRACKs, and in the ACK, are clearly within the
scope of the re-INVITE. The UPDATEs that are sent within the scope of
the re-INVITE also must be included, but in that case there is a
problem. When an UPDATE is senE is sent near the time when the re-INVITE fails,
the recipient of it cannot clearly determine if it was sent before or
after the re-INVITE failed. This case is discussed in section xxx of yyy.
Adopting answer (1) requires that we find a resolution to this
ambiguity. The need to solve this problem is a disadvantage of
MULTI-OA-TRANSACTIONs.
Another possible disadvantage is that this requires the UAC and UAS to
maintain enough state to accomplish the rollback.
The merits of SINGLE-OA-TRANSACTION:
These are, unsurprisingly, pretty much the inverse of
MULTI-OA-TRANSACTIONs.
One advantage is that less state need be kept. Once an answer is
received reliably, or the confirmation of an answer sent reliably is
received, prior state may be discarded.
Another advantage is that the ordering of an UPDATE relative to the
completion of the prior re-INVITE need not be of concern.
The main disadvantage of this approach arises when multiple o/a
exchanges are required to achieve a stable state, such as with
preconditions. With this approach, each o/a exchange is locked in as it
occurs. If the re-INVITE subsequently fails, there may be wreckage to
clean up. Until it is cleaned up, the state of the media session(s) may
be problematic.
General discussion:
While I have used preconditions as an example of the need for multiple
o/a exchanges, they are not the only example. While I don't recall
seeing them in any of our use-case documents, I have definitely seem
them in the wild. For instance there are cases where initial offers are
made with a=inactive, and later revised to a=sendrecv, not because the
call is initially on hold, but because the caller is waiting to see how
things come out. This may be "poor man's preconditions". These aren't
always done within the re-INVITE, but could be.
Either approach will require some normative change, since the existing
text seems ambiguous as to which of these is the "correct"
interpretation. The MULTI-OA-TRANSACTION requires additional work to
define a mechanism for determining of an UPDATE near the end of an
INVITE transaction falls within it, or beyond it. So far there has been
no proposal for how to do this. It seems likely that it will require
that something new be placed into some messages. And this may present
backward compatibility issues.
Many UAs will never experience a re-INVITE containing multiple O/A
exchanges. But even those are impacted by this issue. If a re-INVITE has
an offer, and it is answered in a reliable provisional response, and
then the re-INVITE fails, we still have the issue. If one side assumes
the O/A is rolled back, and the other assumes it remains in effect, then
we have an interoperability error. So it is important to come to some
conclusion.
NOTE: There is a related issue which we have agreed to rule out of scope
for the current discussion. This is whether a change of Contact address
during a re-INVITE is rolled back if the re-INVITE fails. We concluded
that the two issues should not be constrained to have the same answer.
This latter issue is left for another day.
Thanks,
Paul
Paul Kyzivat wrote:
Robert Sparks wrote:
(off-list reply)
I'm mostly comfortable with that approach. Let me ask a question or
two to see if I can remove some of the dangling bits of discomfort.
The conversation so far has been described to me (I haven't been
following it closely - sorry) as focusing _only_ on the impact on
the session(s) being negotiated.
It is _not_ attempting to answer some of the gnarly dialog-state
questions we've uncovered for these failed requests (specifically
what happens to a failed attempt
to update a remote target (by changing the Contact in new requests),
correctt near the time when the re-INVITE fails,
the recipient of it cannot clearly determine if it was sent before or
after the re-INVITE failed. This case is discussed in section xxx of yyy.
Adopting answer (1) requires that we find a resolution to this
ambiguity. The need to solve this problem is a disadvantage of
MULTI-OA-TRANSACTIONs.
Another possible disadvantage is that this requires the UAC and UAS to
maintain enough state to accomplish the rollback.
The merits of SINGLE-OA-TRANSACTION:
These are, unsurprisingly, pretty much the inverse of
MULTI-OA-TRANSACTIONs.
One advantage is that less state need be kept. Once an answer is
received reliably, or the confirmation of an answer sent reliably is
received, prior state may be discarded.
Another advantage is that the ordering of an UPDATE relative to the
completion of the prior re-INVITE need not be of concern.
The main disadvantage of this approach arises when multiple o/a
exchanges are required to achieve a stable state, such as with
preconditions. With this approach, each o/a exchange is locked in as it
occurs. If the re-INVITE subsequently fails, there may be wreckage to
clean up. Until it is cleaned up, the state of the media session(s) may
be problematic.
General discussion:
While I have used preconditions as an example of the need for multiple
o/a exchanges, they are not the only example. While I don't recall
seeing them in any of our use-case documents, I have definitely seem
them in the wild. For instance there are cases where initial offers are
made with a=inactive, and later revised to a=sendrecv, not because the
call is initially on hold, but because the caller is waiting to see how
things come out. This may be "poor man's preconditions". These aren't
always done within the re-INVITE, but could be.
Either approach will require some normative change, since the existing
text seems ambiguous as to which of these is the "correct"
interpretation. The MULTI-OA-TRANSACTION requires additional work to
define a mechanism for determining of an UPDATE near the end of an
INVITE transaction falls within it, or beyond it. So far there has been
no proposal for how to do this. It seems likely that it will require
that something new be placed into some messages. And this may present
backward compatibility issues.
Many UAs will never experience a re-INVITE containing multiple O/A
exchanges. But even those are impacted by this issue. If a re-INVITE has
an offer, and it is answered in a reliable provisional response, and
then the re-INVITE fails, we still have the issue. If one side assumes
the O/A is rolled back, and the other assumes it remains in effect, then
we have an interoperability error. So it is important to come to some
conclusion.
NOTE: There is a related issue which we have agreed to rule out of scope
for the current discussion. This is whether a change of Contact address
during a re-INVITE is rolled back if the re-INVITE fails. We concluded
that the two issues should not be constrained to have the same answer.
This latter issue is left for another day.
Thanks,
Paul
Paul Kyzivat wrote:
Robert Sparks wrote:
(off-list reply)
I'm mostly comfortable with that approach. Let me ask a question or
two to see if I can remove some of the dangling bits of discomfort.
The conversation so far has been described to me (I haven't been
following it closely - sorry) as focusing _only_ on the impact on
the session(s) being negotiated.
It is _not_ attempting to answer some of the gnarly dialog-state
questions we've uncovered for these failed requests (specifically
what happens to a failed attempt
to update a remote target (by changing the Contact in new requests),
correct?
Ea?
Early in the thread I proposed separating the concerns. The remainder
of the thread had indeed focused on the o/a issues.
I do think that the other dialog state, notably the contact, issues
need to be addressed. But I think we must not constrain them to have
the same answer that works for o/a. We can start a separate thread to
discuss that now, or we can wait for the current o/a discussion to
settle first to avoid losing focus.
If I misunderstand and the second thing's in scope for this effort,
then my comfort is much lower.
Paul - you responded separately that you think this touches 3261 as
well - roughly what is the character of those touches?
Hopefully it touches only slightly. The current text regarding rolling
back state to where it was prior to reinvite *may* need some tweaking
depending on what solution we come to.
*If* we agree on the solution that does indeed cause rollback even if
there have been PRACKs and/or UPDATEs along the way, then maybe it
won't need to be changed at all.
I am personally still undecided on which is the better solution. They
have complementary pros and cons. It really is a matter of picking
your poison. The precondition stuff really does cause nasty problems.
I just posted another response in the thread about that.
I earlier suggested splitting off the precondition issues as their own
problem, and solving the rest. But apparently 3gpp wants this resolved
precisely *because* they want to know how it impacts preconditions. So
my suggestion wasn't helpful.
It would be helpful to get some additional perspectives into this
discussion. So far there have been very few participants.
Paul
RjS
On Jun 9, 2008, at 5:18 AM, Gonzalo Camarillo wrote:
Hi Paul,
yes, it may make more sense to update RFCs 3262 and 3311 than to update
RFC 3264... do people agree that the way to document the resolution of
this issue would be to write a new RFC that would clarify how
offer/answer works with re-INVITEs, PRACKs, and UPDATEs, and would
include discussions on preconditions?
Cheers,
Gonzalo
Paul Kyzivat wrote:
Gonzalo,
I generally agree with your characterization below. But as I see it
there likely are no changes needed to 3264. It is intentionally
focused
on the SDP, and not the conveyance of the SDP in some containing
protocol. The following is about the extent of it in 3264:
Protocol operation begins when one agent sends an initial offer to
another agent. An offer is initial if it is outside of any context
that may have already been established through the higher layer
protocol. It is assumed that the higher layer protocol provides
maintenance of some kind of context which allows the various SDP
exchanges to be associated together.
The agent receiving the offer MAY generate an answer, or it MAY
reject the offer. The means for rejecting an offer are dependent on
the higher layer protocol. The offer/answer exchange is atomic; if
the answer is rejected, the session reverts to the state prior to
the
offer (which may be absence of a session).
SIP messed this up somewhat with the offerless-invite, and more
when it
introduced PRACK and UPDATE. The offerless-invite creates a case
when it
is impossible to reject an offer. But we aren't discussing that case
here. Without PRACK and UPDATE, and with an offer in the INVITE, it
the
success or failure of the INVITE that determines the acceptance or
rejection of the offer. (With an offerless invite, the ACK always
accepts the offer, for better or worse.)
The use of PRACK and UPDATE while arly in the thread I proposed separating the concerns. The remainder
of the thread had indeed focused on the o/a issues.
I do think that the other dialog state, notably the contact, issues
need to be addressed. But I think we must not constrain them to have
the same answer that works for o/a. We can start a separate thread to
discuss that now, or we can wait for the current o/a discussion to
settle first to avoid losing focus.
If I misunderstand and the second thing's in scope for this effort,
then my comfort is much lower.
Paul - you responded separately that you think this touches 3261 as
well - roughly what is the character of those touches?
Hopefully it touches only slightly. The current text regarding rolling
back state to where it was prior to reinvite *may* need some tweaking
depending on what solution we come to.
*If* we agree on the solution that does indeed cause rollback even if
there have been PRACKs and/or UPDATEs along the way, then maybe it
won't need to be changed at all.
I am personally still undecided on which is the better solution. They
have complementary pros and cons. It really is a matter of picking
your poison. The precondition stuff really does cause nasty problems.
I just posted another response in the thread about that.
I earlier suggested splitting off the precondition issues as their own
problem, and solving the rest. But apparently 3gpp wants this resolved
precisely *because* they want to know how it impacts preconditions. So
my suggestion wasn't helpful.
It would be helpful to get some additional perspectives into this
discussion. So far there have been very few participants.
Paul
RjS
On Jun 9, 2008, at 5:18 AM, Gonzalo Camarillo wrote:
Hi Paul,
yes, it may make more sense to update RFCs 3262 and 3311 than to update
RFC 3264... do people agree that the way to document the resolution of
this issue would be to write a new RFC that would clarify how
offer/answer works with re-INVITEs, PRACKs, and UPDATEs, and would
include discussions on preconditions?
Cheers,
Gonzalo
Paul Kyzivat wrote:
Gonzalo,
I generally agree with your characterization below. But as I see it
there likely are no changes needed to 3264. It is intentionally
focused
on the SDP, and not the conveyance of the SDP in some containing
protocol. The following is about the extent of it in 3264:
Protocol operation begins when one agent sends an initial offer to
another agent. An offer is initial if it is outside of any context
that may have already been established through the higher layer
protocol. It is assumed that the higher layer protocol provides
maintenance of some kind of context which allows the various SDP
exchanges to be associated together.
The agent receiving the offer MAY generate an answer, or it MAY
reject the offer. The means for rejecting an offer are dependent on
the higher layer protocol. The offer/answer exchange is atomic; if
the answer is rejected, the session reverts to the state prior to
the
offer (which may be absence of a session).
SIP messed this up somewhat with the offerless-invite, and more
when it
introduced PRACK and UPDATE. The offerless-invite creates a case
when it
is impossible to reject an offer. But we aren't discussing that case
here. Without PRACK and UPDATE, and with an offer in the INVITE, it
the
success or failure of the INVITE that determines the acceptance or
rejection of the offer. (With an offerless invite, the ACK always
accepts the offer, for better or worse.)
The use of PRACK and UPDATE while an INVITEn INVITE transaction is is progress
creates an ambiguous situation due to the following from section
14.1 of
3261:
If a UA receives a non-2xx final response to a re-INVITE, the
session
parameters MUST remain unchanged, as if no re-INVITE had been
issued.
This implies that changes made via PRACK and UPDATE during the INVITE
transaction must be rolled back. Since the problem created by 3262 and
3311, in conjunction with 3261, I think the fixes will have to
apply to
those, not to 3264.
Also, the issue about changing Contact addresses clearly has
nothing to
do with 3264. And I am becoming increasingly convinced that the rules
for "committing" a change of Contact address ought to be decoupled
from
the rules for "committing" a change to media sessions.
Before we get into the specifics, does the above make sense?
Thanks,
Paul
Gonzalo Camarillo wrote:
Hi,
we should be providing 3GPP with an answer to their liaison soon:
https://datatracker.ietf.org/liaison/444/
The thing is that when working on the offer/answer usage draft below,
we kept from making normative changes to offer/answer:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-08.txt
However, it seems that there are a few cases that would require
normative updates to RFC 3264. In this thread, two cases have been
identified: roll back and address changes during ongoing
transactions.
I would like to see a list of such pending updates in order to decide
whether we need to revise RFC 3264 at this point or document the
current issues (like we are doing with RFC 3261) for a future update.
Thanks,
Gonzalo
Christer Holmberg wrote:
Hi,
I do NOT think John's case is connected to the rollback issue.
The rollback issue is: what happens to data that has been updated
between the re-INVITE request and failure response? It of course
included the target, but is not related to where responses are sent.
Responses are, afaik, always sent to where the request came from, so
if one updates the local target he has to make sure that he listens
to the "old" port if there are ongoing transactions.
Regards,
Christer
________________________________
Lähettäjä: Paul Kyzivat [mailto:pkyzivat at cisco.com]
Lähetetty: pe 16.5.2008 14:38
Vastaanottaja: Elwell, John
Kopio: Christer Holmberg; sipping List
Aihe: Re: [Sipping] Liaison Statement on offer/answer procedures
John,
This is a good point.
It does expose a potentially long window when address changes are
problematic. I guess if a quick address change is necessary then the
INVITE, or reINVITE, can be CANCELed.
IMO this is starting to identify an area that could stand to have
more
specification. I guess this sounds like a best practices draft,
but its
still a little fuzzy to me. And I am far from clear whether this is
tightly connected to the o/a rollback issue.
Thanks,
Paul
Elwell, John wrote:
Paul,
-----Original Message-----
From: sipping-bounces at ietf.org
[mailto:sipping-bounces at ietf.org] On Behalf Of Paul Kyzivat
Sent: 15 May 2008 14:48
To: Christer Holmberg
Cc: sipping List
Subject: Re: [Sipping] Liaison Sta transaction is is progress
creates an ambiguous situation due to the following from section
14.1 of
3261:
If a UA receives a non-2xx final response to a re-INVITE, the
session
parameters MUST remain unchanged, as if no re-INVITE had been
issued.
This implies that changes made via PRACK and UPDATE during the INVITE
transaction must be rolled back. Since the problem created by 3262 and
3311, in conjunction with 3261, I think the fixes will have to
apply to
those, not to 3264.
Also, the issue about changing Contact addresses clearly has
nothing to
do with 3264. And I am becoming increasingly convinced that the rules
for "committing" a change of Contact address ought to be decoupled
from
the rules for "committing" a change to media sessions.
Before we get into the specifics, does the above make sense?
Thanks,
Paul
Gonzalo Camarillo wrote:
Hi,
we should be providing 3GPP with an answer to their liaison soon:
https://datatracker.ietf.org/liaison/444/
The thing is that when working on the offer/answer usage draft below,
we kept from making normative changes to offer/answer:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-08.txt
However, it seems that there are a few cases that would require
normative updates to RFC 3264. In this thread, two cases have been
identified: roll back and address changes during ongoing
transactions.
I would like to see a list of such pending updates in order to decide
whether we need to revise RFC 3264 at this point or document the
current issues (like we are doing with RFC 3261) for a future update.
Thanks,
Gonzalo
Christer Holmberg wrote:
Hi,
I do NOT think John's case is connected to the rollback issue.
The rollback issue is: what happens to data that has been updated
between the re-INVITE request and failure response? It of course
included the target, but is not related to where responses are sent.
Responses are, afaik, always sent to where the request came from, so
if one updates the local target he has to make sure that he listens
to the "old" port if there are ongoing transactions.
Regards,
Christer
________________________________
Lähettäjä: Paul Kyzivat [mailto:pkyzivat at cisco.com]
Lähetetty: pe 16.5.2008 14:38
Vastaanottaja: Elwell, John
Kopio: Christer Holmberg; sipping List
Aihe: Re: [Sipping] Liaison Statement on offer/answer procedures
John,
This is a good point.
It does expose a potentially long window when address changes are
problematic. I guess if a quick address change is necessary then the
INVITE, or reINVITE, can be CANCELed.
IMO this is starting to identify an area that could stand to have
more
specification. I guess this sounds like a best practices draft,
but its
still a little fuzzy to me. And I am far from clear whether this is
tightly connected to the o/a rollback issue.
Thanks,
Paul
Elwell, John wrote:
Paul,
-----Original Message-----
From: sipping-bounces at ietf.org
[mailto:sipping-bounces at ietf.org] On Behalf Of Paul Kyzivat
Sent: 15 May 2008 14:48
To: Christer Holmberg
Cc: sipping List
Subject: Re: [Sipping] Liaison Statement otement on offer/answer
procedures
Christer,
Saying "you shouldn't do it" to changing contact address or media
address ignores facts of life that may require doing it. This
overlaps
strongly with the session mobility discussion that is
currently going on.
Specifically, if a UA is losing possession of its address, or
connectivity via that address, then it will have to do
*something*. If
we are going to say that you shouldn't change the contact
address in a
dialog, and shouldn't change the media address in a media
session, then
we need to specify some alternative.
Clearly there are at least two distinct cases here:
- there is a desire to switch to a new address, but the old
address
can continue to be supported until and unless use of the new one
can be established
[JRE] So if the contact address changes and we successfully
conclude
the
UPDATE transaction, and then the old contact address disappears,
it is
likely that the Via list on the re-INVITE request will have become
invalidated too, so the final response will not reach the UAC.
Correct?
John
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP
n offer/answer
procedures
Christer,
Saying "you shouldn't do it" to changing contact address or media
address ignores facts of life that may require doing it. This
overlaps
strongly with the session mobility discussion that is
currently going on.
Specifically, if a UA is losing possession of its address, or
connectivity via that address, then it will have to do
*something*. If
we are going to say that you shouldn't change the contact
address in a
dialog, and shouldn't change the media address in a media
session, then
we need to specify some alternative.
Clearly there are at least two distinct cases here:
- there is a desire to switch to a new address, but the old
address
can continue to be supported until and unless use of the new one
can be established
[JRE] So if the contact address changes and we successfully
conclude
the
UPDATE transaction, and then the old contact address disappears,
it is
likely that the Via list on the re-INVITE request will have become
invalidated too, so the final response will not reach the UAC.
Correct?
John
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP