Re: [Sip] Comments on sip-info-events-01

[Eric Burger]

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?

   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?

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

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.

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
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