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

["Christer Holmberg" <[e-mail]>]

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



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

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 [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip