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

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 14 May 2002 17:23:12 +0300

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.

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.

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Chris Hogg"<[email-masked]>
Date: Tue, 14 May 2002 15:18:01 +0100

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 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'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"). 

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)