Subject: [Sip] New version of draft-ietf-sip-199

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 27 Aug 2008 12:45:26 +0200

Hi,

Based on a large number of good comments and suggestions off-line I have
produced and submitted a new version (-01) of the draft-ietf-sip-199
draft.

Until available, it can also be found at:

http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-01.txt

Some work is still needed on the security section.

I also realized that, in the reference section, I still refer to the
dialog-usage draft document, eventhough it became an RFC.

Regards,

Christer

_______________________________________________
Sip mailing list  https://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: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Aug 2008 10:44:43 -0400

Hi Christer,

This seems to have covered most things. The addition of descriptions of 
the sorts of resources that can be released is quite helpful. I have a 
few comments on the new version

>    If multiple usages [RFC5057] are used within an early dialog, and it
>    is not clear which dialogusage the 199 response terminates, SIP
>    entities that keep dialog state SHALL NOT release resources
>    associated with the early dialog when they receive the 199 response.

Under what circumstances can it not be clear which usage the 199 applies 
to? AFAIK the 199 should only be used with an INVITE dialog usage, and 
there can only be one of those per dialog. (We don't allow early dialogs 
for other usages.)

>    5. limited access resources - in case of forking and multiple stream
>    there may not be possible to allow early media on all dialogs, so
>    some dialogs may e.g. be set to "inactive".  When a dialog is
>    terminated, media can be allowed on other dialogs.

s/there may not be possible/it may not be possible/

>    When a forking proxy receives a non-2xx final response which
>    terminates one or more early dialogs and the proxy does not intend to
>    forward the final response immediately (due to the rules for a
>    forking proxy), and the UAC has indicated support of the 199 response
>    code, the forking proxy MUST send a 199 provisional response, for
>    each associated early dialog that it can associate with the final
>    response, upstream towards the sender of the associated request.  The
>    199 provisional response MUST contain a To header tag parameter,
>    which identifies the early dialog that has been terminated.

This still seems to require sending a 199 even if a 199 was previously 
received and forwarded. IMO the proxy should never send a 199 if one was 
previously received and forwarded for the same dialog. Keeping record of 
that should be a requirement for any proxy that intends to send a 199.

>    Since all SIP entities involved in a session setup do not necessarily
>    support the specific meaning of the 199 Early Dialog Terminated
>    provisional response, the sender of the response MUST be prepared to
>    receive SIP requests and responses associated with the dialog for
>    which the 199 response was sent (a proxy may receive SIP messages
>    from either direction).  If such request is received, and the
>    receiver maintains state of the dialogs, the receiver MUST reply to
>    such requests with a 481 final response.  A UAC that receives a 199
>    response for an early dialog MUST NOT send any further requests on
>    that dialog, except for requests which acknowledge reliable
>    responses.

I'm dubious of requiring, or even expecting or allowing, proxies to 
generate 481 responses. For instance, the UAC is still permitted to send 
PRACKs, and the proxies had better forward them. So I think it would be 
best for a proxy to always forward requests even if it thinks the dialog 
has ceased to exist.

>    NOTE: According to [RFC3262] and [RFC3264], if the INVITE request did
>    not contain an SPD offer, the first relaible response (provisonal or
>    final) MUST contain an SDP offer.  However, since 199 is only sent on
>    established early dialog, it will never be the first response sent.

IMO a better rationale here is that the 199 response is not sent 
reliably, and so isn't obligated to carry the offer. I think the above 
logic is weaker and questionable - an early dialog can be established 
without sending a reliable response. And I *think* a 199 can still be 
used in that case.

I guess the UAS is permitted to send a reliable 199, but it would be 
sufficient to say that it must not do so if that would obligate it to 
include an offer. Better yet, lets just say that 199 should *never* be 
sent reliably.

>    This section registers a new SIP response code, 199.  The required
>    information for this registration, as specified in RFC 3261, is:

I have mixed feelings about using "199" as the option-tag. It is 
syntactically valid, but using an all-numeric token bothers me. It could 
be something like "use199". But if nobody else is bothered by a numeric 
token I can live with it.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 27 Aug 2008 19:31:51 +0200

Hi Paul,

>there can only be one of those per dialog. (We don't allow early dialogs 

I think it's clear that the 199 applies to the invite dialog usage. But, what if there are other usages? You would need to know whether the error response which triggered the 199 also affects those usages.

Again, this would only happen if you have established the other usage during the early phase of the invite dialog (which I think is only theoretical).

>s/there may not be possible/it may not be possible/

I'll fix that.

>that should be a requirement for any proxy that intends to send a 199.

Yes, I was thinking about the same thing. Having two 199s sent (one by the forking proxy, and one by the UAS) is not a good thing.

>best for a proxy to always forward requests even if it thinks the dialog 

Yes. I was thinking of an UAS only, so I will clarify that this does not apply to proxies.

>include an offer. Better yet, lets just say that 199 should *never* be 

I have no problem saying that. But, again, I don't think there are cases where you would be obligated  to include an offer/answer in 199, because you have already sent at least one 18x.

Of course, one use-case is when the UAS first sends a 18x unreliably, and then send a 199 reliably. In this case, if the INVITE didn't contain an offer, the 199 would have to contain one, since it's the first RELIABLE provisional response sent.

But, I have no problem saying that 199 must not be sent reliably (not even by a UAS), if people are ok with that.

>token I can live with it.

We can use another value, if someone comes up with something more sexy than "199" :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Aug 2008 20:45:49 -0400

Comments inline. I think we are in substantial agreement.

	Thanks,
	Paul

> Again, this would only happen if you have established the other usage during the early phase of the invite dialog (which I think is only theoretical).

OK. I think I see what you are getting at, but it is somewhat obscure.

Lets suppose for a minute we have an early invite dialog usage, and have 
another dialog usage sharing the dialog with it. (E.g. maybe we sent a 
REFER and got a refer subscription going.) [At this point Robert runs 
out of the room, screaming.]

Of course the invite was also forked, and we have another early dialog 
going as well.

Now something happens that leads the forking proxy to want to send a 199 
response. Because this is a 1xx class response, it must be something 
that has happened pertaining to the INVITE, since we now only allow 
provisionals for INVITE. I guess the question is whether the response 
that provokes the 199 might *also* imply the termination of the dialog 
as a whole rather than just the invite dialog usage. That can only be 
determined if the actual final response is known, and we have excluded 
that have we not?

> Of course, one use-case is when the UAS first sends a 18x unreliably, and then send a 199 reliably. In this case, if the INVITE didn't contain an offer, the 199 would have to contain one, since it'…

Good - you found your own counterexample!

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 28 Aug 2008 08:17:48 +0200

Hi Paul, 

>>>Under what circumstances can it not be clear which usage the 199 
>>>applies to? AFAIK the 199 should only be used with an INVITE dialog 
>>>usage, and there can only be one of those per dialog. (We don't allow

>>>early dialogs for other usages.)
>> 
>>I think it's clear that the 199 applies to the invite dialog usage.
But, what if there are other usages? You would need to know whether the
error response which triggered the 199 also affects 
>>those usages.
>> 
>>Again, this would only happen if you have established the other usage
during the early phase of the invite dialog (which I think is only
theoretical).
>Lets suppose for a minute we have an early invite dialog usage, and
have another dialog usage sharing the dialog with it. (E.g. maybe we
sent a REFER and got a refer subscription going.) [At 
>this point Robert runs out of the room, screaming.]
>
going as well.
>
>Now something happens that leads the forking proxy to want to send a
199 response. Because this is a 1xx class response, it must be something
that has happened pertaining to the INVITE, since 
>we now only allow provisionals for INVITE. I guess the question is
whether the response that provokes the 199 might *also* imply the
termination of the dialog as a whole rather than just the 
>invite dialog usage. That can only be determined if the actual final
response is known, and we have excluded that have we not?

We have not excluded it, but we don't mandate it. 

In Dublin we decided that the 199 draft will not talk about transfering
SIP headers, response codes etc in the 199 response - but it won't
forbid it either. Then, if someone wants to use 199 e.g. to solve HERFP,
he/she will have to separately specify what headers to included.

>>>IMO a better rationale here is that the 199 response is not sent
reliably, and so isn't obligated to carry the offer. I think the 
>>>above logic is weaker and questionable - an early dialog can be
established
used in that case.

>>>include an offer. Better yet, lets just say that 199 should *never* 
>>>be sent reliably.
>> 
>>I have no problem saying that. But, again, I don't think there are
cases where you would be obligated  to include an offer/answer in 199,
because you have already sent at least one 18x.
>> 
>>Of course, one use-case is when the UAS first sends a 18x unreliably,
and then send a 199 reliably. In this case, if the INVITE didn't contain
an offer, the 199 would have to contain one, 
>>since it's the first RELIABLE provisional response sent.
>

DOH! :)

Of course, since it is only the UAS which is currently allowed to send
199 reliably, I guess it wouldn't matter even if the UAS inserted an SDP
body. But, if there are some entities which don't understand 199, they
may look at the SDP and think that the UAS is trying to establish a
media path, which is not good.

So, either we say that 199 must not (or should not, if there is a future
use-case where it would be useful to send it reliably) ne be sent
reliably, or we say that 199 should not (or must not) be sent reliably
if it is required to carry SDP.

Regards,

Christer