Subject: RE: [Sipping] Comments on draft-anil-sipping-bla-02.txt

From: "Christian Stredicke" <[email-masked]>
Date: Thu, 21 Jul 2005 03:20:19 +0200

Comments inline.

________________________________

	From: Venkatesh [mailto:[email-masked]] 
	Sent: Wednesday, July 20, 2005 3:46 AM
	To: Christian Stredicke
	Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
	Subject: Re: [Sipping] Comments on draft-anil-sipping-bla-02.txt

	Christian:
	
	Thanks for your comments. Replies inline...

	On 7/19/05, Christian Stredicke <[email-masked]>
wrote: 

		First of all, this draft addresses a real-world problem
that must be
		solved soon.
		
		My comments:
		
		- I would not describe the architecture for implementing
this, at least
		not in such a detailed fashion. By involving a proxy
things get really
		complicated, and integrating subscrptions for
registrations is also a 
		smart idea, but can be left for the implementor.

	The goal was to provide some background as to how the feature
got used before we
	detailed the approach. We will try to remove some of the details
in our next revision.

		- The tricky thing in this draft is the resource
allocation. I must say
		I did not understand how this allocation process should
work. Ok, you 
		have a state agent. But assume that two phones lift
their handset at the
		same time: how do they know what line to use? That
became not clear to
		me. Maybe an example would be helpful.

	It is the UA that requests the state agent as to what
line/resource it wants to use. This is
	typically based on what line/key the end user chose to place an
outbound call. The decision of
	whether to grant the resource to the UA is made by the state
agent (so the state agent
	does the arbitration when multiple UA's are requesting the same
line/resource). Think we 
	captured this information in words in a couple of sections of
the draft. We will 
	provide an example call flow to clarify the same.

		- As an alternative, you might add something next to the
dialog stuff
		that deals only with the line allocation. Maybe
something like "give me 
		a free line", "release that line". Request-response. If
you do this, the
		dialog stuff would only be used for LED/status control
while the
		resource allocation would be independant from that. 
		 
		[CS] I saw an example where the state agent returns a
500 code to that NOTIFY. Thats not a good idea (although very
pragmatic). How will the UA know if the state agent is dead or it can
just not use that line? Should it retry another line? The inventors of
SIP, HTTP and whatever will get a heartattack if they see this.

	I am not sure if your suggestion was to add a seperate package
to handle resource allocation
	or add something to dialog state payload to indicate the same.
The solution outlined in the
	draft uses the latter approach (the x-instance-id in the NOTIFY
payload).
	
	If it is the former:
	 
	Resource allocation is closely tied to dialog state for this
application. LED/Status control
	is dependent purely on the dialog state... You acquire a
line/resource with the intent of
	placing a call. The resource is free to be used when the call
terminates. Thus, dialog state
	controls what lines/resources are in use/free (and thus the
LED/status). Keeping them seperate 
	could add more complexity from a UA's perspective. For example,
when does a UA decide to show
	a resource as free? (A) when the dialog terminates or (B) when
it receives a "release that line"
	message? What if a UA only received a dialog terminate but never
received a "release that line"
	message?? 
	 
	[CS] Hmm. Hmm. Hmm. I am not so sure. The UA must have a method
to allocate the line. Maybe it is ok to piggyback that on the dialog
state somehow. For example, when going offhook you put a tag into the
notify that must show up in the notify for that line. But you need two
subscriptions anyway. One from the UA to the agent and one in the other
direction. 
	 
	If you make the line allocation with something else than dialog
state, you will also have two subscritions, one for the resource
allocation and one for the dialog state. My personal feeling is that
this is more clean.

		Last, the formatting of the document seems to be not 100
% IETF draft
		compliant.

	Will fix this.
	 
	Thanks
	Venkatesh

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

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

---

From: Venkatesh <[email-masked]>
Date: Wed, 20 Jul 2005 18:46:27 -0700

Comments inline....

On 7/20/05, Christian Stredicke <[email-masked]> wrote: 
> 
> Comments inline.
> 
>  ------------------------------
> *From:* Venkatesh [mailto:[email-masked]] 
> *Sent:* Wednesday, July 20, 2005 3:46 AM
> *To:* Christian Stredicke
> *Cc:* [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> *Subject:* Re: [Sipping] Comments on draft-anil-sipping-bla-02.txt
> 
>   Christian:
> 
>  On 7/19/05, Christian Stredicke <[email-masked]> wrote: 
> > 
> > First of all, this draft addresses a real-world problem that must be
> > solved soon.
> > 
> > My comments:
> > 
> > - I would not describe the architecture for implementing this, at least
> > not in such a detailed fashion. By involving a proxy things get really
> > complicated, and integrating subscrptions for registrations is also a 
>  The goal was to provide some background as to how the feature got used 
> before we
> detailed the approach. We will try to remove some of the details in our 
> next revision.
> 
> - The tricky thing in this draft is the resource allocation. I must say
> > I did not understand how this allocation process should work. Ok, you 
> > have a state agent. But assume that two phones lift their handset at the
> > same time: how do they know what line to use? That became not clear to
>  It is the UA that requests the state agent as to what line/resource it 
> wants to use. This is
> typically based on what line/key the end user chose to place an outbound 
> call. The decision of
> whether to grant the resource to the UA is made by the state agent (so the 
> state agent
> captured this information in words in a couple of sections of the draft. 
> We will 
>  - As an alternative, you might add something next to the dialog stuff
> > that deals only with the line allocation. Maybe something like "give me 
> > a free line", "release that line". Request-response. If you do this, the
> > dialog stuff would only be used for LED/status control while the
> >  [CS] I saw an example where the state agent returns a 500 code to that 
> > NOTIFY. Thats not a good idea (although very pragmatic). How will the UA 
> > know if the state agent is dead or it can just not use that line? Should it 
> > retry another line? The inventors of SIP, HTTP and whatever will get a 
> > heartattack if they see this.
> > 
> 
[VV] If the state agent is dead you would get a timeout waiting for a 
response. We needed to return a non 2xx response code to indicate that the 
request to allocate a line is not being honored. It is a sort of a small 
window that can occur should two or more UA's attempt to use the same 
resource. The State Agent honors one of them and indicates that the line is 
in use to the rest in the group. It rejects the other requests. Think we 
also proposed the UA look at the Retry-After header in the response to 
decide when to retry the request should it need the specific line/resource. 
The idea was that under such a situation even before the retry-after timer 
expires, the UA would have received a NOTIFY from the State Agent saying 
that the line being requested is in use by some other entity and it can use 
this the same to notify the end user via visual or other means... Beyond 
that requesting another resource on a failure is entirely upto the 
implementation... Such an attempt does not affect the feature operation per 
say in any way. I guess we could choose something more appropriate (may be a 
491 Glare Detected) rather than a 500 response as the resource being 
requested is being allocated to another entity. If you have any other 
alternatives in mind we are open to suggestions.

   I am not sure if your suggestion was to add a seperate package to handle 
> resource allocation
> or add something to dialog state payload to indicate the same. The 
> solution outlined in the
> draft uses the latter approach (the x-instance-id in the NOTIFY payload).
> 
> If it is the former:
>  Resource allocation is closely tied to dialog state for this application. 
> LED/Status control
> is dependent purely on the dialog state... You acquire a line/resource 
> with the intent of
> placing a call. The resource is free to be used when the call terminates. 
> Thus, dialog state
> controls what lines/resources are in use/free (and thus the LED/status). 
> Keeping them seperate 
> could add more complexity from a UA's perspective. For example, when does 
> a UA decide to show
> a resource as free? (A) when the dialog terminates or (B) when it receives 
> a "release that line"
> message? What if a UA only received a dialog terminate but never received 
> a "release that line"
> message?? 
>  [CS] Hmm. Hmm. Hmm. I am not so sure. The UA must have a method to 
> allocate the line. Maybe it is ok to piggyback that on the dialog state 
> somehow. For example, when going offhook you put a tag into the notify that 
> must show up in the notify for that line. But you need two subscriptions 
> anyway. One from the UA to the agent and one in the other direction. 
>  If you make the line allocation with something else than dialog state, 
> you will also have two subscritions, one for the resource allocation and one 
> for the dialog state. My personal feeling is that this is more clean.
> 
> 
[VV] I am not sure I understand your thought process here. With your 
suggestion, you would need 3 subscriptions. There needs to be one 
subscription for dialog state between the state agent and the UA (as the 
State Agent needs to know about status of various calls/dialogs and their 
dialog identifiers so that the same can be propogated to others in the 
group. This information would be required when an attempt to pick calls from 
other UA's are made). You need one subscription from the UA to the State 
Agent so that the UA in the group can know about the dialog states of 
various calls in the group so that when the user attempts to pick a call it 
knows the dialog identifiers. In addition to the above, should you go with a 
seperate subscription for the resource allocation stuff, you would need a 
third subscription between the state agent and the UA so that this can be 
exchanged.

  Last, the formatting of the document seems to be not 100 % IETF draft