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
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
