-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com] Sent: Monday,
August 04, 2008 12:58 PM
To: DRAGE, Keith (Keith)
Cc: Robert Sparks; sipping; Mary Barnes; Gonzalo Camarillo
Subject: Re: [Sipping] Current status of response to 3gpp Liaison
Statementon offer/answer procedures
I will defer to Robert for a definitive statement on this. But
AFAIK this is *not* *written* anywhere. I think it is a
consequence of the specs - that as the state machines are defined
they *will not work
correctly* if the two ends don't have he same values.
Paul
DRAGE, Keith (Keith) wrote:
Robert wrote:
It is a hard requirement that any pair of transaction
state machines
(the client and server machines for any given hop) have the same
timer values. Without that, behavior becomes very
incorrect. And for
INVITE/ 200/ACK the TU timers (which are all based on T1)
have to be
the same or you get into broken territory. The result is
that if you
change a timer somewhere in the network, you either change
it across
the whole network or you put in a node that's essentially
playing the
role of a SIP-SIP gateway that deals with complexity of
having timers
different on each side.
Is this actually written anywhere. I expected to find it in
RFC 3261 if it was written but a scan did not reveal this.
I know IMS uses, for the mobile accesses, timer values that
are T1 * 4 for UA to 1st proxy, and then the normal values in the
network.
Robert, can you be more specific on the implications of
such a mismatch.
Regards
Keith
-----Original Message-----
From: sipping-bounces at ietf.org
[mailto:sipping-bounces at ietf.org] On Behalf Of Robert Sparks
Sent: Monday, July 28, 2008 3:51 PM
To: Paul Kyzivat
Cc: sipping; Mary Barnes; Gonzalo Camarillo
Subject: Re: [Sipping] Current status of response to 3gpp
Liaison Statementon offer/answer procedures
One comment inline:
On Jul 25, 2008, at 3:58 PM, Paul Kyzivat wrote:
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.
It is a hard requirement that any pair of transaction
state machines
(the client and server machines for any given hop) have the same
timer values. Without that, behavior becomes very
incorrect. And for
INVITE/ 200/ACK the TU timers (which are all based on T1)
have to be
the same or you get into broken territory. The result is
that if you
change a timer somewhere in the network, you either change
it across
the whole network or you put in a node that's essentially
playing the
role of a SIP-SIP gateway that deals with complexity of
having timers
different on each side.
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 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.
- There 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 UPDATE 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), correct?
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 an 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-offe
ranswer-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 on
offer/answer
procedures
Christer,
Saying "you shouldn't do it" to changing contact
address or