[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
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)"
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). 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. 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. 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?
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.
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