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

From: "Christian Stredicke" <[email-masked]>
Date: Fri, 22 Jul 2005 04:59:38 +0200

What you could to to make the resource allocation more explicit.
Essentially we are talking about a RPC, therefore it would make sense to
just use something existing, e.g. SOAP. You know, there has been a long
discussion on how to do RPC, and we should not reinvent the wheel here.
An example line allocation would look like this:
 
Sent:
----------------------------------------
GET sip:[email-masked] SIP/2.0
Content-Type: application/xml
[Other headers not shown]
 
<?xml version="1.0"?>  
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ns="http://bla.ietf.org/soap/bla">
 <env:Body>
  <ns:AllocateLineRequest>
   <uri>sip:[email-masked]</uri>
  </ns:AllocateLineRequest>
 </env:Body>
</end:Envelope>
----------------------------------------
 
Received:
----------------------------------------
SIP/2.0 200 Ok
Content-Type: application/xml
[Other headers not shown]
 
<?xml version="1.0"?>  
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ns="http://bla.ietf.org/soap/bla">
 <env:Body>
  <ns:AllocateLineResponse>
   <line-appearance>1</line-appearance>
  </ns:AllocateLineResponse>
 </env:Body>
</end:Envelope>
----------------------------------------

To release the line you would do another request, e.g.
ns:ReleaseLineRequest, ReleaseLineResponse. That would be very clean!
 
BTW you could do this also via http/https, avoiding discussions in the
SIP chat rooms. But I think it would be smarter to use SIP
(NAT/Firewall/Configuration) as transport vehicle.
 
Then you need only one more subsciption for dialog state. The phone then
will control the LED according to the dialog state sent in the NOTIFY
coming from the state agent.
 
CS

________________________________

	From: Venkatesh [mailto:[email-masked]] 
	Sent: Thursday, July 21, 2005 10:01 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

	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:
			
			Thanks for your comments. Replies inline...

			On 7/19/05, Christian Stredicke <
[email-masked] <mailto:[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.

	[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
				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: Sat, 30 Jul 2005 06:14:15 -0700

Comments inline....

On 7/30/05, Christian Stredicke <[email-masked]> wrote: 
> 
> Hi Venkatesh!
>  We are on the same page on point 2. Notifying a user-agent with dialog 
> state is a good solution. No debate about that. This is a subscription that 
> is necessary.
>  The second job is is to *allocate* something (with the possibility that 
> the agent selects a free line of rejects the allocation), not to *notify* 
> someone. 
>  The problem is that the agent has the possiblity to reject the request, 
> e.g. when all lines are busy. And it might have to pick a free line! Do 
> you think the user agent should just try all possible lines one after 
> another with a dialog-notify? How does it know how many lines are available? 
> Should it try from the beginning when all lines were rejected? Questions, 
> questions, questions. I would not like to implement such a searching 
> algorithm. Therefore, "IMHO" dialog-state is not suitable. What you try to 
> do is to add additional semantics outside of dialog state (rejecting the 
> notify), and what I say this is dirty and no-no-no (that was the part with 
> the heart attack).
> 
 [VV]: The User-Agent already has information on the list of lines that are 
in use at any point in time (as it has subscribed to dialog state with the 
state-agent and is receiving information on all calls). It also has the list 
of lines that are 'free' for use by the end user... It is this information 
the UA displays to the end user.... When the user requests to place a call, 
he/she chooses which resource/line he/she wants to use when placing the 
call. The NOTIFY to request use of a line would be issued if and only if the 
user chose a line/resource that the UA displayed as being available for use 
at the time the selection was made by the user... Thus the possibility of 
rejecting the request comes into play only when another user ends up 
choosing the same resource at the same time. In this case, the UA could 
simply provide an indication that the user attempt to use a specific 
resource/line has failed and wait for user input rather than trying some 
line at random.... Thus the line selection process is not based on the UA 
sending NOTIFY's beginning with 0 and counting all the way up to n based on 
response received from the State Agent. 
 As of responding with a non 2xx response, I am not sure if it is adding 
additional semantics to the dialog state package per say. It is more of how 
the UA should react to non 2xx responses for a NOTIFY. Re-reading section 
3.2.2 of RFC 3265, "A NOTIFY request is considered failed if the response 
times out, or a non 2xx response code is received which has no retry-after 
header and no implied further action can be taken to retry the request". 
Based on the above, would I be incorrect in saying, should a NOTIFY be 
rejected with a non 2xx response with a Retry-After header, the NOTIFY 
request should not be considered failed? 

And finally if this is the only piece of the draft that you are not 
comfortable with, there seems to be an alternate proposal from Dale on the 
mailing list that we could explore. Using SOAP to accomplish a small subset 
(actually a race condition) of the feature seems like an overkill to me.

Venkatesh

---

From: "Christian Stredicke" <[email-masked]>
Date: Sun, 31 Jul 2005 08:41:39 +0200

Dale's proposal solves the race problem. However, I would propose that
the UA does not even try to allocate a line, and leave this job entirely
to the state agent. Then we can also handle the case that two UA go
offhook at the same time, and the first one gets line0 while the second
one gets line1.
 
The UA includes a "tag" (which might be the local contact or better the
id of the dialog) that is searched in the notify from the agent.
Something like:
 
(Send from UA to Agent:)
NOTIFY sip:agent SIP/2.0
Call-ID: first-subscription
...
 
<dialog-info entity="sip:[email-masked]">
  <dialog id="as7d900as8">
    <state>trying</state>
    ...
  </dialog>
</dialog-info>

(Received from Agent to UA:)
SIP/2.0 200 Ok
Call-ID: first-subscription
...
 
(Received from Agent to UA:)
NOTIFY sip:[email-masked] SIP/2.0
Call-ID: second-subscription
...
 
<dialog-info entity="sip:[email-masked]">
  <dialog id="as7d900as8">
    <local>  
      <target>
        ...
        <param pname="x-line-id" pvalue="0" />  
      </target>  
    </local>  
  </dialog>
</dialog-info>

(Send from UA to Agent:)
SIP/2.0 200 Ok 
Call-ID: second-subscription
...
 
It still does not win a beauty price (which the SOAP solution would
do.-). But it should solve the problems and it should be not too
difficult to implement this.
 
Sorry I can't be in Paris. But Nils is there and if you want to discuss
this "F2F", please contact him.

Best, Christian

	From: Venkatesh [mailto:[email-masked]] 
	Sent: Saturday, July 30, 2005 3:16 PM
	To: Christian Stredicke
	Cc: Sipping (E-mail)
	Subject: Re: [Sipping] Comments on draft-anil-sipping-bla-02.txt

	Comments inline....

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

		Hi Venkatesh!
		 
		We are on the same page on point 2. Notifying a
user-agent with dialog state is a good solution. No debate about that.
This is a subscription that is necessary. 
		 
		The second job is is to *allocate* something (with the
possibility that the agent selects a free line of rejects the
allocation), not to *notify* someone. 
		 
		The problem is that the agent has the possiblity to
reject the request, e.g. when all lines are busy. And it might have to
pick a free line! Do you think the user agent should just try all
possible lines one after another with a dialog-notify? How does it know
how many lines are available? Should it try from the beginning when all
lines were rejected? Questions, questions, questions. I would not like
to implement such a searching algorithm. Therefore, "IMHO" dialog-state
is not suitable. What you try to do is to add additional semantics
outside of dialog state (rejecting the notify), and what I say this is
dirty and no-no-no (that was the part with the heart attack). 

	[VV]: The User-Agent already has information on the list of
lines that are in use at any point in time (as it has subscribed to
dialog state with the state-agent and is receiving information on all
calls). It also has the list of lines that are 'free' for use by the end
user... It is this information the UA displays to the end user.... When
the user requests to place a call, he/she chooses which resource/line
he/she wants to use when placing the call. The NOTIFY to request use of
a line would be issued if and only if the user chose a line/resource
that the UA displayed as being available for use at the time the
selection was made by the user... Thus the possibility of rejecting the
request comes into play only when another user ends up choosing the same
resource at the same time. In this case, the UA could simply provide an
indication that the user attempt to use a specific resource/line has
failed and wait for user input rather than trying some line at
random.... Thus the line selection process is not based on the UA
sending NOTIFY's beginning with 0 and counting all the way up to n based
on response received from the State Agent. 
	 
	As of responding with a non 2xx response, I am not sure if it is
adding additional semantics to the dialog state package per say. It is
more of how the UA should react to non 2xx responses for a NOTIFY.
Re-reading section 3.2.2 of RFC 3265, "A NOTIFY request is considered
failed if the response times out, or a non 2xx response code is received
which has no retry-after header and no implied further action can be
taken to retry the request". Based on the above, would I be incorrect in
saying, should a NOTIFY be rejected with a non 2xx response with a
Retry-After header, the NOTIFY request should not be considered failed?

	And finally if this is the only piece of the draft that you are
not comfortable with, there seems to be an alternate proposal from Dale
on the mailing list that we could explore. Using SOAP to accomplish a
small subset (actually a race condition) of the feature seems like an
overkill to me. 
	
	Venkatesh