Re: Comments on sip-info-events-01

Some followups to John's comments. I've trimmed down to relevant stuff.

	Thanks,
	Paul

Elwell, John wrote:

> - I think I suggested once before that we should not treat
> Send-Info/Recv-Info exchanges like offer/answer, but should just have a
> simple rule that says that a UA can send these header fields at any time
> and they supersede any sent previously. A UA MUST not send INFO unless
> the package has been identified in the last Send-Info sent and the last
> Recv-Info received. A UA MUST (SHOULD?) discard a received INFO unless
> the package has been identified in the last Recv-Info sent, and MUST be
> prepared to receive an INFO for a package as soon as it has sent a
> Recv-Info identifying that package. These header fields MAY be included
> in an INVITE request, in a dialog-forming response to an INVITE request,
> or in any other request or response in the context of an early or full
> INVITE-initiated dialog. This would be a lot simpler. Is there any
> reason it would not work? I am not certain I have enumerated all the
> rules here, but I doubt if very much more would need to be said
> normatively.

I think this will work as long as he contents of these headers on one 
side are not coupled with those on the other side. IOW, I should be able 
to mention a package in Recv-Info even if it wasn't mentioned by the 
other side, and visa versa.

But can somebody remind me why we need Send-Info at all?

However in any case we must accept that there is a race condition, when 
an INFO is in flight at the same time as a Recv-Info in the other 
direction that forbids sending it. I think that is fine - it will just 
be rejected, and that should not be considered a serious error.

> "If the UAS receives an INFO request with a Info-Package the UAC
>    advertised with a Send-Info in the last dialog state update"
> It was not clear to me that every dialog state update MUST contain
> Send-Info/Recv-Info. In other words, if I send an UPDATE request without
> these header fields, e.g., for session timer refresh, does this cancel
> any previous negotiation of Info Packages? I would prefer that it did
> not, that it simply left things unchanged.

We need to be careful here, to prevent breaking 3pcc. If a transfer is 
done via 3pcc, how can we ensure that the desires of the unchanged party 
are made known to the transfer target? This could be ensured that the 
Send-Info/Recv-Info headers are always sent when an offer or answer is sent.

> - "If a server receives an INFO request with a body it understands, but
>    it has no Info-Package header, the UAS MAY render the body."
> This is the first mention of "render". In fact there is nothing to say
> that a UAS must/should/may render a body when an INFO request is not in
> error, so it seems odd to talk about rendering when there is an apparent
> error in the INFO request. Is "rendering" necessarily the appropriate
> thing to do with a received and valid INFO request. Should we instead
> say "...the UAS MAY make use of the body"?

Yeah, "render" could be quite confusing. Perhaps "process"?

> - "The UAS MUST send a 481 Call Leg/Transaction Does Not Exist message
>    if the INFO request does not match any existing dialog."
> Shouldn't this say "...does not match any INVITE-initiated dialog"?

INVITE-dialog-usage?

(I could have a dialog that was initiated with an INVITE, then 
piggybacked with a SUBSCRIBE, then BYE to the INVITE, but subscription 
remains. That is still an INVITE-initiated dialog, but INFO isn't valid.)

> - "The INFO message MUST NOT change the state of the SIP dialog.  The
>    only exception to this rule is for specific failure responses as
>    documented in RFC 5057 [RFC5057], which may cause the INVITE dialog
>    to terminate."

This jogs another question in my mind. Is it permissible to pass 
Send-Info / Recv-Info headers in an INFO? If so, then IMO those change 
the state of the dialog.

> - "A UAC, the sender of the OPTIONS request, MAY include Send-Info and
>    Recv-Info headers, populated appropriately for the packages the UAC
>    supports.  The UAS MAY include its set of Send-Info and Recv-Info
>    packages.  The UAS and UAC MUST NOT consider the OPTIONS request to
>    be part of a capabilities negotiation.  The OPTIONS request is purely
>    a probe."
> The semantics of these header fields in an INVITE request or another
> message in an INVITE-initiated dialog means I am prepared to
> send/receive these packages in the context of this dialog. However, for
> OPTIONS there is no dialog. So what exactly are the semantics of these
> header fields in OPTIONS request? Presumably it just means I support
> these packages and may be prepared to send/receive them in the context
> of an INVITE-initiated dialog. This should be clarified.

I agree. (I have similar problems with everything in an OPTIONS.)

> - In 5.1, Why is Contact allowed in an INFO request but not in a 2xx
> response to INFO? Since INFO is not allowed to change dialog state, it
> cannot change target URIs, so what would be the meaning of Contact in an
> INFO request. I think we should align with BYE and not allow Contact in
> INFO.

Agree.

> - "For the purposes of matching Info Package types indicated in Send-
>    Info or Recv-Info with those in the Info-Package header field value,
>    one compares the Info-package-name portion of the Info-package-type
>    portion of the "Info-Package" header byte-by-byte with that of the
>    same in the "Send-Info" or "Recv-Info" header values."
> Presumably comparison is case-sensitive. Should we state this?

By default I would assume case-insensitive behavior. That is the norm 
for most things. Is there a reason to be case sensitive here?

_______________________________________________
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