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
