Comments inline. I think we are in substantial agreement.
Thanks,
Paul
Christer Holmberg wrote:
> Hi Paul,
>
>> 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.)
>
> 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).
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?
>> 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/
>
> I'll fix that.
>
>
>
>> 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.
>
> 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.
>
>
>
>> 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.
>
> Yes. I was thinking of an UAS only, so I will clarify that this does not
> apply to proxies.
>
>
>
>> 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.
>
> 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.
Good - you found your own counterexample!
> But, I have no problem saying that 199 must not be sent reliably (not even by
> a UAS), if people are ok with that.
>
>
>
>> 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.
>
> We can use another value, if someone comes up with something more sexy than
> "199" :)
>
> Regards,
>
> Christer
>
>
>
>
>
> Christer Holmberg wrote:
>> 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 PROTECTED] for questions on current sip
>> Use [EMAIL PROTECTED] for new developments on the application of sip
>>
>
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
