Subject: [Sip] Re:draft-elwell-sip-state-update-01.txt

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Apr 2004 09:49:45 -0400

John,

I agree with you that some clarification would be helpful. I just have a 
few nits with your draft:

Some other potential pieces of state could be mentioned in section 2:

- a body part with a content-disposition of "alert"
- a body part with the content-disposition of "icon"

These have never been very well explained, and have some semantic 
overlap with the Alert-Info and Call-Info header. It may be that the 
best way to deal with them would be to simply remove these content 
dispositions, or document that they must be used together with a 
Content-Id and a reference from an Alert-Info or Call-Info header.

Section 3.1 says "The UPDATE mechanism [2] provides a means for updating 
the session using a 2-message sequence (request/response) during an 
INVITE-initiated dialog." AFAIK it isn't limited to use in 
invite-initiated dialogs. For instance, it could be used for target 
refresh in a subscribe-initiated dialog.

Section 4 makes some specific proposals. One it doesn't make, that 
shoudl be considered, is updating 3261 to further elaborate the state 
that is maintained as part of a dialog, and that is subject to change.

Re the open issue in section 5: presumably the purpose of sending an 
UPDATE is to change some aspect of the state of the dialog. No matter 
what piece of state that is, sending overlapping UPDATE requests makes 
it difficult to reach a consistent agreement about what the state of the 
dialog is. For instance:

	A                   B
	| (1)UPDATE(From=C) |
	|------------------>|
	|                   |
	| (2)UPDATE(From=D) |
	|------------------>|
	|                   |
	| 200 OK (2)        |
	|<------------------|
	| 200 OK (1)        |
	|<------------------|

(Perhaps this happened because message (1) got lost in the network for 
awhile.)

You could try to tighten this up by saying that you can't have 
concurrent requests outstanding that revise the same aspect of state. 
But that starts to get very complex to define precisely, especially 
since some aspects of state (like the Contact) are required to be 
transmitted in every UPDATE or reINVITE, even if unchanged.

But its perhaps simpler to just leave this alone.

	Paul

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip