Subject: Re: [Sipping] Review of: draft-allen-sipping-poc-p-answer-state-header-00.txt

From: "Andrew Allen" <[email-masked]>
Date: Sat, 23 Jul 2005 05:47:46 -0400

Paul

Maybe you can do me the favour of also forwarding this response to the SIPPING list since I seem to still be "persona non grata" on the list and all my emails seem to need moderator approval which tends towards infinity!

Ok first point I think we have agreement :)

2nd point - I agree it appears a little strange to include the P-Answer-State header as a header of the NOTIFY however inventing a 100 Trying that does not exist in order to include it in a sipfrag in the message body seems even more strange to me and not really above board. I think I would like to hear the views of others on this.

I did consider in this particular scenario including the P-Answer-State header in the 200 or 202 response to the REFER but I was concerned that this might cause implementation issues for some stacks which may send a 2xx response to the REFER before reaching the Application layer.

However the only scenario where a REFER is used with P-Answer-State header in the OMA POC architecture is a little different than the scenario you describe. This is the pre-established session scenario as shown in the second set of example flows in the draft. In this scenario UA A establishes a dialog with B (PTT Server) using INVITE then when A wished to establish a call to UA C it sends a REFER to B that request B to send an INVITE to C containg the SDP already negotiated between A and B. Normally in the OMA architecture the INVITE to C will traverse other PTT Servers on the way to C (such as the PTT server that hosts C) however in the case that both A and C are hosted by B this is not necessary. 

When C is hosted by another PTT server D that knows the answer mode of C, D will return a P-Answer-State header in a 183 response to B and B will then include the P-Answer-State header in a sipfrag of the 183 in the NOTIFY. However when A and C are both hosted by the B there is no 183 involved. The semantics of receiving the P-Answer-State header as a header in the NOTIFY are that the session is currently only established as far as B and no other node has yet been contacted on the route to C. The semantics of receiving the P-Answer-State header in a sipfrag are that at least one other node has been contacted on the route to C.

You asked "What would happen if somebody other than A sent a refer to B?" In the OMA POC case the REFER would be sent on a different pre-established dialog than that between A and B so there should be no interaction between the two sessions with B.

Again I would invite comments on this - if everyone is happy to invent a 100 Trying sipfrag body in the very rare case that you don't have one I'm happy to do this.

Last issue OK how about "PTT Server" instead of "Intermeadiate Node"? Comments?

Gonzalo - seems we may have an issue here that warrants some discussion time in SIPPING in Paris. Is it possible to add some agenda time for this?

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 <[email-masked]>
To: Andrew Allen <[email-masked]>
CC: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Fri Jul 22 18:29:21 2005
Subject: 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 <[email-masked]>
> To: Dean Willis <[email-masked]>
> CC: sipping ((E-mail)) <[email-masked]>; Andrew Allen <[email-masked]>; Rohan Mahy <[email-masked]>; Gonzalo Camarillo <[email-masked]>
> 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 [email-masked] for questions on current sip
>>Use [email-masked] 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.
> 

---------------------------------------------------------------------
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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 23 Jul 2005 18:17:38 +0300

Andrew,

> Maybe you can do me the favour of also forwarding this response to
> the SIPPING list since I seem to still be "persona non grata" on the
> list 

if you send emails to this list from an address that is not subscribed 
to the list, your messages will not get thru. Now I have added your 
address to the accept filter, so you should not have any further 
problems sending emails to this list.

> Gonzalo - seems we may have an issue here that warrants some
> discussion time in SIPPING in Paris. Is it possible to add some
> agenda time for this?

Could you please fill the template I sent to the list for agenda 
requests, including the length of the time slot, drafts people should 
read, etc, and send it to me? I will then log your agenda request.

Based on all the agenda requests received, we will elaborate the final 
agenda, which will be ready by Monday.

Thanks,

Gonzalo