[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Review of: draft-allen-sipping-poc-p-answer-state-header-00.txt
Andrew Allen wrote:
Paul
Thanks for taking the time to read the draft during the busy run up to IETF.
I can take the comment about "contains an answer" rather than SDP answer on board in the next revision.
I think it may be useful to include in the first case an "(such as an SDP answer)"
Certainly. That would be fine.
On the issue of the P-Answer-State header being included in a NOTIFY. Normally it would be included in a sipfrag in the body (and this would be the normal usage in the OMA PoC architecture).
OK. That is what I thought.
However there is a possibility where the PTT Server that serves the terminating user is the same one that serves the Originating User and in that case if the PTT session is originated using a REFER the NOTIFY that is sent is just the one that is sent to in response to the REFER that creates the implicit subscription and not one sent as a result of a response.
OK. I think in that case there is normally no body.
In that case there is no response contents to include in the sipfrag so I did intend that the P-Answer-State header would be included in the NOTIFY not the body.
Well, that seems at least a bit peculiar.
Is your view that the P-Answer-State header should be included in a sipfrag even in the case where no response is received containing that header instead of including the P-Answer-State header in the NOTIFY?
Maybe we need to dig into the intended semantics more deeply.
Suppose we have:
A--------B--------C
|
|--------D
A invites B, then sends B a refer to C and talks for awhile.
The refer causes an INVITE from B to C, and in the normal case the
response to the invite contains the P-Answer-State header. This is then
returned to A in a sipfrag in a notify. This makes sense to A because it
applies to the state of C, not B.
In your other case where the P-Answer-State is among the notify headers
rather than in a sipfrag, it seems that this applies to the B. I don't
think it makes sense to do it both ways. From the point of view of A
these cases do not differ in any signficant way.
You can perhaps make a case either way, but I think the header should be
in the same place in both cases. And the semantics of what it says are
somewhat different - it changes which node's state A cares about.
To see the difference, assume that A remains in session with B and sends
B a refer to D. If the state comes back in a sipfrag, it will be clear
that it applies to D, but if it comes back in the notify headers it
looks kind of like a change in the state of the session with B. But it
isn't a very kosher way to do that.
What would happen if somebody other than A sent a refer to B? Then A
might be doing PTT with somebody different, but not know the state.
I am inclined to think it would be best to always use a sipfrag. If you
don't have a proper status back from the invite, you could just make up
a 100 Trying response.
I would like to receive further comments from the list whether I should introduce a proprietary architectural element (such as PTT server) into the draft rather than an Intermediate Node.
I don't think it has to be "proprietary" - it is just "distinguished" in
its behavior.
Paul
Andrew
--------------------------
Andrew Allen
Manager Standards
Research In Motion Ltd
BlackBerry Mobile +1 847 809 8636
http://www.rim.com/
Sent from my BlackBerry Wireless Handheld
-----Original Message-----
From: Paul Kyzivat <pkyzivat at cisco.com>
To: Dean Willis <dean.willis at softarmor.com>
CC: sipping ((E-mail)) <sipping at ietf.org>; Andrew Allen <aallen at rim.com>; Rohan Mahy <rohan at ekabal.com>; Gonzalo Camarillo <Gonzalo.Camarillo at ericsson.com>
Sent: Mon Jul 18 14:56:33 2005
Subject: Re: [Sipping] Review of: draft-allen-sipping-poc-p-answer-state-header-00.txt
Dean Willis wrote:
I received a request from OMA that we perform expert review of the
revised p-answer-state header draft.
Please have a look at:
http://www.ietf.org/internet-drafts/draft-allen-sipping-poc-p-answer-
state-header-00.txt
and raises any issues to the list ASAP.
We'll need a volunteer or two to do the actual review. Any takers?
I don't have time to go over it with a fine tooth comb. But I did read
it over and have the following comments:
There are a number of places where there is wording similar to "if the
response contains SDP". This isn't an accurate characterization of the
proper condition. I believe this may be more correctly stated as "if the
response contains an answer". Reasons for this change:
- An answer might be represented in SDPng rather than SDP
- a response could contain SDP that is an offer rather than
an answer
- a response could contain SDP that is neither offer nor answer
(using some other Content-Disposition.)
When mentioning that the P-Answer-Mode may be in a NOTIFY, please
clarify that it is in the sipfrag body carried in the NOTIFY, not in
amonst the NOTIFY headers. (This is already done in a few places, but
not nearly all.)
There is a lot of mention of "an intermediate node that acts as a
back-to-back user agent". However B2BUA behavior is not standardized, so
B2BUAs may act in a multitude of roles. The B2BUAs mentioned in this
draft have a special role and special responsibilities. (There could be
other B2BUAs in the call that act more like proxies as far as this draft
is concerned.) The draft should distinguish those elements to which it
intends normative behavior to apply, rather than simply applying to to
"B2BUA", or "intermediate node" generically. To achieve this I think it
will be necessary to assign a name to the component types whose behavior
is being specified. (E.g. PoC-Intermediate.)
Is P-Answer-Mode only used with initial INVITEs? Or can it be applicable
to reINVITEs as well? At first glance it would seem to only be
applicable to initial invites. But there may be cases where it would be
applicable. E.g. a blind transfer done in 3pcc mode might result in a
new participant being in unconfirmed mode for a time. I don't know the
answer here, but some discussion of the issue would be helpful. A state
model for confirmation state over the lifetime of a dialog could help.
Paul
Note:
idnits has the following minor things to say about this draft that will
have to be changed before it could go to the IESG:
* There are 54 instances of too long lines in the document, the longest
one being 5 characters in excess of 72.
Miscellaneous warnings:
- Line 200 has weird spacing: '...that it is...'
- Line 310 has weird spacing: '...er mode setti...'
- Line 456 has weird spacing: '...request in re...'
- Line 477 has weird spacing: '...med" in the r...'
- Line 478 has weird spacing: '...e" from the f...'
- (3 more instances...)
--
Dean
_______________________________________________
Sipping mailing list https://www1.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
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
Sipping mailing list https://www1.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