Re: 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