Subject: [Sip] RE: Clarification of Manyfolks-07 and "local" pre-conditions

From: "Chris Hogg"<[email-masked]>
Date: Tue, 14 May 2002 16:00:30 +0100

Hi Gonzalo,

Thanks for the quick response.  

Comments in line.

Regards,

Chris.

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: 14 May 2002 15:23
To: Hogg, Chris [MDN05:MA01:EXCH]
Cc: [email-masked]'; [email-masked]';
[email-masked]'
Subject: Re: Clarification of Manyfolks-07 and "local" pre-conditions

Hello,

>>No, it is not a bug in the spec. It is mandated to add two current
>>status *LINES*. If you are only using local preconditions, the remote
>>status lines will NOT have the value mandatory.

[CH] This was the way I thought the mechanism would work however is it
really necessary to mandate that if you have a pre-condition which is
completely local to one end (and for which there is no parallel requirement
to reserve resources in the peer) to have to include a remote status line
with a strength of "none"?  I'm thinking that if a pre-condition was totally
local to one end then it would be simpler just to send this and not have to
include a "dummy" remote pre-condition tag (with strength sent to "none"). 

>>About the possibility of having multiple preconditions of different
>>types for the same media line, it is mentioned in the spec. The section
>>you are referring to is the explanation of the mechanism, and it is kept
>>simple so that people understand it better. I believe it is better to
>>explain how preconditions of one type work and then say that you can
>>have multiple types than trying to explain everything together from the
>>beginning.

[CH] I understand your concerns for simplicity and that the text I'm
referring to is normative however, I couldn't find any text anywhere
(particularly within the non-normative sections of 5.1.1) saying that, when
constructing the offer, (for a given media line) you could include more than
1 pre-condition type and that "segmented" and "e2e" pre-conditions could
potentially co-exist within the same media line. I think it would be clearer
if it was stated somewhere that this was possible.  If I've missed
something, I'd be happy for you to point out the text to me.

Thanks,
Regards,
Chris.

Regards,

Gonzalo

Chris Hogg wrote:
> 
> Hi everyone,
> 
> I've been having a read through of the latest version of Manyfolks
> (Manyfolks-07) and would like to clarify a number of parts of the
> text.
> 
> From section 5.1.1 "SDP encoding"
> 
> "For the segmented status type, the user agent MUST generate two
> current status lines: one with the tag "local" and the other with the
> tag "remote". The user agent MUST add one or two desired status lines
> per segment (i.e., local and remote)."
> 
> And from section 9 "Unknown Precondition type"
> 
> "A UA that receives an unknown precondition-type
>  with a "mandatory" strength-tag in an offer MUST refuse the offer
>  unless the only unknown mandatory preconditions have the "local" tag.
> 
>  In this case, the UA does not need to be involved in order to meet
>  the preconditions. The UA will ask for confirmation of the
>  preconditions and, when the confirmation arrives, it will resume
>  session establishment."
> 
> From my understanding I thought that the text in section 9 regarding
> the ability of the UAS to accept an offer stating a "local"
> pre-condition that it does not understand was added (after agreement
> on the list) for the reason that there may be occasions whereby there
> are pre-conditions which are local to one end and for which the other
> end's UA does not need to understand (and hence asks for
> "confirmation" of the precondition status in the answer SDP).
> However, the text in section 5.1.1 seems to be mis-aligned with this
> since it requires the offerer to include both "local" and "remote"
> pre-conditions if the "segmented" status type is being used.  This
> would mean if a totally local pre-condition was included in the offer
> (without any associated "remote") then the text in section 9 would
> cause the far-end UA to reject the session with a 580 Pre-condition
> unknown response.  This is not the way I thought that "local to one
> end only with no parallel in the peer acess network" style
> pre-conditions were intended to behave.
> 
> I'm assuming that this is just a bug in the spec.
> 
> I've also noticed (normative) text in section 5 which indicates that
> only one type of pre-condition can be used in a given media stream
> (i.e. either "segmented" or "e2e").
> 
> "The offerer then decides whether it is going to use the end-to-end
>    status type or the segmented status type. If the status type of the
> 
>    media line will be end-to-end...."
> 
> Once again, from my understanding, the text in section 9 was
> introduced because it was agreed there could be some pre-conditions
> which may be local to the one end only and for which there was no
> parallel in the peer access network. It was my understanding, however,
> that given these "local" pre-conditions the SIP network may also
> require to use pre-conditions and that these pre-conditions could be
> either of type "segmented" or "e2e".
> 
> Comments?
> 
> Regards,
> 
> Chris
> 
> Chris Hogg
> Nortel Networks (UK)
> 

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo