Comments in
line.
-Rockson
-----Original Message-----
From:
sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] On Behalf Of OKUMURA Shinji
Sent: Wednesday, September
10, 2008 6:04 PM
To: sip at ietf.org; sipping at ietf.org
Subject: [Sipping]
UPDATE with offer
Hi,
I have any questions about sending offer by
UPDATE request.
RFC3311/5.1 Sending an UPDATE says,
The rules for inclusion of offers and answers in SIP messages as
defined in Section 13.2.1 of RFC 3261 still apply. These rules
exist
to guarantee a consistent view of the session state.
This means
that, for the
caller:
o If the UPDATE is being
sent before completion of the
initial
INVITE transaction,
and the initial INVITE contained an
offer,
the UPDATE can
contain an offer if the callee generated
an
answer in a reliable
provisional response, and the caller
has
received answers to any
other offers it sent in either PRACK
or
UPDATE, and has generated
answers for any offers it received
in
an UPDATE from the
callee.
o If the UPDATE is being
sent before completion of the
initial
INVITE transaction,
and the initial INVITE did not contain
an
offer, the UPDATE can
contain an offer if the callee
generated
an offer in a
reliable provisional response, and the
UAC
generated an answer in
the corresponding PRACK. Of course,
it
can't send an UPDATE if
it has not received answers to
any
other offers it sent in
either PRACK or UPDATE, or has
not
generated answers for
any other offers it received in an
UPDATE
from the
callee.
o If the UPDATE is being
sent after the completion of the
initial
INVITE transaction,
it cannot contain an offer if the
caller
has generated or
received offers in a re-INVITE or UPDATE
which
have not been
answered.
According to the description above, The following scenarios
seem to be allowed.(before sending PRACK)
A
B
|
|
|ini-INVITE
(offer0)
|
|------------------------------>|
|
|
|
1xx-rel (answer0)|
|<------------------------------|
|
|
|UPDATE
(offer1)
|
|==============================>|
|
|
[RL] IMO, this is intended
scenario, UPDATE here is used to update caller's ip address if caller is
mobile.
A
B
|
|
|re-INVITE
(offer0)
|
|------------------------------>|
|
|
|
1xx-rel (answer0)|
|<------------------------------|
|
|
|UPDATE
(offer1)
|
|==============================>|
|
|
[RL] this is allowed, however, I seldom
see any reliable response
used for re-INVITE.
A
B
|
|
|re-INVITE (no
offer)
|
|------------------------------>|
|
|
|UPDATE
(offer1)
|
|==============================>|
|
|
[RL] this is subject to race condition. B is probably sending its 200 with its own offer simultaneously,
so this two offers
cross over causing overlapping offer.
and for the
callee:
o If the UPDATE is being
sent before the completion of the
INVITE
transaction, and the
initial INVITE contained an offer,
the
UPDATE cannot be sent
with an offer unless the callee
has
generated an answer in a
reliable provisional response,
has
received a PRACK for
that reliable provisional response,
has
not received any
requests (PRACK or UPDATE) with offers that
it
has not answered, and has
not sent any UPDATE requests
containing offers that have not been
answered.
o If the UPDATE is being
sent before completion of the
INVITE
transaction, and the
initial INVITE did not contain an
offer,
the UPDATE cannot be
sent with an offer unless the callee
has
sent an offer in a
reliable provisional response, received
an
answer in a PRACK, and
has not received any UPDATE
requests
with offers that it
has not answered, and has not sent
any
UPDATE requests
containing offers that have not been
answered.
o If the UPDATE is being
sent after the completion of the
initial
INVITE transaction,
it cannot be sent with an offer if
the
callee has generated or
received offers in a re-INVITE
or
UPDATE which have not
been answered.
According to the description above, The following
scenarios seem to be allowed.(before receiving PRACK)
A
B
|
|
|
re-INVITE (offer0)|
|<------------------------------|
|
|
|1xx-rel
(answer0)
|
|------------------------------>|
|
|
|UPDATE
(offer1)
|
|==============================>|
|
|
A
B
|
|
|
re-INV (no offer)|
|<------------------------------|
|
|
|UPDATE
(offer1)
|
|==============================>|
|
|
[RL] you can send 200 with
offer here instead more naturally, why bother with UPDATE??
Is my
understanding correct?
Some scenarios seem to be allowed only for
re-INVITE.
is this what the author intended?
If not, which is not intended
scenario?
Regards,
Shinji
_______________________________________________
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
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip