Buried in here is a discussion with OPTIONS. I believe OPTIONS is useful, but I could live without it. If we have it, it should do what OPTIONS always does, i.e. provide a means of discovering what would happen if I tried an INVITE request with the same characteristics. That means we have to agree what the parameters in an INVITE dialog provide us with first. regards Keith
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Eric Burger
Sent: Monday, November 17, 2008 2:21 AM
To: John Elwell; Paul Kyzivat
Cc: SIP IETF
Subject: Re: [Sip] Comments on sip-info-events-01
Inline.
On Nov 10, 2008, at 2:22 AM, Elwell, John wrote:
My responses to Paul:
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: 10 November 2008 04:10
To: Elwell, John
Cc: Eric Burger; SIP IETF
Subject: Re: [Sip] 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.
[JRE] I agree that this would be a consequence, and yet
a further
simplification.
I like it.
But can somebody remind me why we need Send-Info
at all?
You may be willing to send a package but not be willing to
receive a package. For example, you may be a phone that wants to send
only the DTMF package but have no need to receive any INFOs. You need a
way to advertise what you are willing to send.
In much older drafts, when it was really an offer/answer
handshake, there was some thought you might modify what you will
advertise. For example, if you advertised
Send-Info: old-foo, new-foo
and the response had
Recv-Info: old-foo, new-foo
the final response may just list
Send-Info: new-foo
to let the UAS know you will only be sending new-foo.
I am ambivalent about this. What say you?
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.
Agreed.
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.
[JRE] I don't object to mandating it, if this is what it
takes to make
it work in a 3PCC environment. Is it clear to everyone
what "dialog
state update" means?
Yes, and I would offer sending Send-Info/Recv-Info in every
(potential) state changing message means the protocol works in all
scenarios. It doesn't cost much in bytes, but I can see the argument
that if you ran a separate, light-weight keep-alive mechanism, it would
need to now know about INFO Packages.
- "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"?
Sounds good to me. I used render because its meaning is
well-known ("Do something with it").
- "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?
[JRE] Yes, that would be better.
(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.)
Will do.
- "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.
Nope. I'll fix.
- "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.)
Me, too.
- 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.
Yup.
- "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?
[JRE] I am happy for it to be case-insensitive, but the
most likely
interpretation of the existing words is case-sensitive.
The intention of the existing words is, in fact, case-sensitive.
Again, I can go either way.
_______________________________________________ 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
