Subject: RE: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt

From: [email-masked]
Date: Tue, 24 Jul 2001 19:34:26 +0300

Hi Christer

>-----Original Message-----
>From: ext Christer Holmberg [mailto:[email-masked]]
>Sent: 24. July 2001 8:45
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt
>
>
>
>Hello Bernhard,
>
>>>I'm the first to admit (I've mentioned it before) that the PRACK
>>>mechanism is very "heavy", and what you propose has been discussed
>>>before (I think I was even one of those who proposed it back 
>then...),
>>>but the argument against it was that it is against the SIP semantics,
>>>since ACK is the ONLY method which is sent without a response - and I
>>>think that makes very much sense.
>>>
>>>So, while we can (and we SHALL) come up with new cool 
>features for SIP,
>>>we should avoid touching the protocol core. In this case we 
>would have
>>>to change the semantics of a SIP transaction, since the bis specifies
>>>how INVITEs are handled, how ACKs are handled, and how ALL
>>>OTHER methods (standard- or extension methods) should be 
>handled - ie we
>>>would have to change the bis too. Do we want to do that?
>> 
>>This I-D does _not_ intend to change the core specs; meaning, 
>that it is an
>>extension mechanism, which can be used only if all intermediate proxy
>>servers (and the UAs) do understand the feature. If this is 
>the case, they
>>shall treat SPRACK similar than ACK.
>> 
>>Or do you mean, that the RFC2543bis specs strictly forbids 
>such kind of
>>extensions, although it is technically feasible and backwards 
>compatible?
>
>Well, I guess it's a question of definitions here.
>
>The core spec does define a SIP transaction, also for 
>extension methods.
>One could argue that an extension is allowed to change that, since it
>doesn't matter as long as every node understand the extension. BUT -
>then we may end up in a situation when people start changing other
>things in the core too. At the end we may even end up having completely
>different protocols (well, I know it sounds a little dramatic, but you
>get the point, right? :)
>
>One of the nice (maybe the nicest) feature of SIP is that it allows us
>to define extensions, without changing the core, and if a node doesn't
>understand the extension it simply ignores it. Ie, I can 
>define how many
>new methods I want, how many new headers I want, and how many 
>new option
>tags I want, without touching the core - as long as I define them
>according to what the core says. Of course some extensions require
>support from the other nodes, but again, that is not a problem as long
>as I use the mechanisms defined in the core.
>
>The problem here is that first came SIP, then came the need for being
>able to acknowledge provisional responses... :) So, I think that many
>people agree (at least I do :) that PRACK is not the nicest, best and
>far from the most efficient way to do it, but unfortunately it's the
>only way SIP allows us to do it.
>
>>What is the opinion of the authors of RFC2543bis concerning this?
>> 
>>>Also, lately we've also seen that PRACK probably will be 
>used for more
>>>than just acking a provisional response. The COMET draft shows one
>>>example, and Jonathan also gave a very interesting proposal to
>>>solve the early media issue using PRACK.
>> 
>>Does the 200 OK of PRACK carry some relevant information in 
>these cases?
>>If yes, the PRACK might be more appropriate for these cases.
>
>I would say that in most cases, especially when it's used only to
>acknowledge a 1xx response, it does carry any relevant information. 
>
>I don't think the question is about if SPRACK could be used instead of
>PRACK. In many cases I think it could, and what you propose has been
>discussed before. The issue is the core protocol.
>
> 
>> >These were only my personal opinions, though...
>> >
>> >I also have a few questions on the text in the draft.
>> >
>> >6.2. UAS Behavior
>> >
>> >The third chapter says:
>> >
>>>"If the request did not include a Proxy-Supported header
>>>indicating this
>>>feature is understood by every record-route proxy, but it included a
>>>Supported or a Require header indicating this feature, the UAS either
>>>SHOULD send the provisional response using the reliability mechanism
>>>defined in [6] or it SHOULD send the provisional response 
>unreliably."
>>>
>>>Q1: You have a "SHOULD-OR-SHOULD" statement here. I think that
>>>SHOULD as such confuses people enough, but now I'm really lost... :)
>>>
>>>Q2: You write that if SPRACK can't be used, the UAS SHOULD send the
>>>provisional response using the mechanism defined in [6] (the PRACK
>>>method). To me this indicates that the UAS also SHOULD support the
>>>mechanism defined in [6]...
>> 
>>It seems, that the relationship between s100rel and 100rel 
>needs some more
>>general explanations and the referred section some 
>refinement. Thanks for
>>your feedback.
>> 
>>I try to explain here what is meant:
>> 
>>- The s100rel package contains somehow the capabilities of the 100rel
>>package. Whenever a response is to be sent reliably and 
>s100rel can be used,
>>then use s100rel (SPRACK); otherwise use 100rel (PRACK)
>- 
>>- If _no_ Proxy-Supported (s100rel), but a Require (s100rel) 
>are present ,
>>then use always 100rel (i.e. response contains "Require: 
>100rel" and is
>>acknowledged by PRACK)
>> 
>>- If _no_ Proxy-Supported (s100rel), but a Supported 
>(s100rel) and _no_
>>Require (s100rel) are present, then either use 100rel or send 
>it unreliable
>>(as appropriate; decision by the UAS).
>
>That is how I understood it too, but it was the relationship that
>confused me a little. IF we are going to use SPRACK, I think the whole
>mechanism about reliability of provisional responses has to be
>re-designed, because like was said earlier: in many cases there is no
>idea to even implement PRACK if SPRACK is used.

The idea is a fall-back behavior: In the cases SPRACK is not possible, PRACK
can be used; thus the s100rel package contains somehow the 100rel package.

>Another question about the draft: What if we use a default outbound
>server, which does NOT record-route? How do we know if it supports
>SPRACK? I don't think one can always "assume" it does. 

This case should have been discussed in the I-D. It somehow got forgotten...
Thanks for the reminder.
The principle idea for this case is, that whoever uses an outbound proxy
MUST know about its support of the s100rel. Otherwise s100rel MUST NOT be
used.

br,
 Bernie

>Regards,
>
>Christer Holmberg
>Ericsson Finland
>
>
>
>
>
>
>> Hope this makes things clear...:)
>> 
>> >Regards,
>> >
>> >Christer Holmberg
>> >Ericsson Finland
>> 
>> cheers,
>>  Bernie
>

_______________________________________________
Sip mailing list  http://www.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: Christer Holmberg <[email-masked]>
Date: Wed, 25 Jul 2001 08:28:08 +0300

Hi Bernie,

>MUST know about its support of the s100rel. Otherwise s100rel MUST NOT be

I don't think it's a good approach to assume that, and the only time one
really could assume that is when the user has control of the outbound
proxy. Also, what stops the user from using SPRACK anyway, even if he
would know the outbound proxy does NOT support it?

The protocol defines ways to find out about the capabilities of nodes,
and I think that those methods should be used. 

Regards,

Christer Holmberg
Ericsson Finland