Re: Comments on sip-info-events-01

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