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

From: Venkatesh <[email-masked]>
Date: Fri, 29 Jul 2005 13:59:23 -0700

Christian:

Sorry, but I am still having trouble understanding your proposal. Are you 
proposing we use non SIP means for resource reservation? This feature is all 
about displaying dialog states to the end user. Requesting a resource is 
just one aspect of the feature. 
 For satisfactory operation of this feature, we would need two subscriptions 
for dialog state at a minimum.
 1. The first subscription is from the State Agent to the UA. This is to 
ensure that the UA notifies the State Agent when:
 (A) It answers an incoming call.
 (B) It puts a call that it previously answered/placed on Hold.
 (C) Disconnects a call that it placed or answered.
 (D) Decides to place an outbound call.

Your idea of using a SUBSCRIBE/NOTIFY for line sieze/resource reservation 
would get you (C) and (D) [and may be (A) if you choose to send a NOTIFY 
before you answer the incoming call]. You will still *need* to subscribe for 
the dialog state package as the State Agent will have to provide the dialog 
identifiers to other UA's in the group (as one of the feature requirements 
is that a UA can retrieve a call that is put on Hold at another UA. This 
means the that UA from which you are retrieving the Held call will need the 
SIP dialog identifiers to populate the Replaces Header in the INVITE).
 2. The UA in the BLA group should SUBSCRIBE to the State Agent for *dialog 
state*. This is needed to achieve the following:
  (A) Receive dialog identifier information of various calls across the 
various UA's. This is to facilitate
 - display to the end user about the states of various calls/dialogs (there 
might be one call that is active, one call that is on hold, no call on a 
third and so on). 
 - allow the end user to 'pick' a call that was put on hold by some other UA 
(this would require dialog identifiers conveyed).

Assuming that you agree with the above, which of the below were you 
proposing?
 (A) Replace the subscription for dialog state from the State Agent to the 
UA with some other event for resource reservation?
(B) A *new* Subscription for a new 'event' from the state agent to the UA 
for the purposes of resource reservation?
(C) use non SIP means for resource reservation.
 Using a seperate event or non SIP means only for resource reservations 
seems to open up a lot of interactions. You would now have to start worrying 
about how failures (like timeouts, or error responses) on one of them 
affects the other, what effect it would have on the end UA behavior (so what 
would a UA show the state of a resource as if it receives a message via 
dialog state indicating a line is in use, while someone else reports using 
the other package/non SIP means that they are using the line) and so on.... 

Venkatesh

 On 7/29/05, Christian Stredicke <[email-masked]> wrote: 
> 
> Hi Venkatesh, any new thoughts on this?
>  CS
> 
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Christian Stredicke
> *Sent:* Friday, July 22, 2005 5:16 AM
> *To:* Venkatesh
> *Cc:* [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> *Subject:* RE: [Sipping] Comments on draft-anil-sipping-bla-02.txt
> 
>  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]> 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
> > > 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: "Christian Stredicke" <[email-masked]>
Date: Sat, 30 Jul 2005 13:15:22 +0200

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).
 
SOAP (Simple Object Access Protocol) is a good protocol for allocations.
There are several bindings of SOAP, for example HTTP and Email. And SIP
can of course also be a binding for SOAP. I think SOAP is a perfect
vehicle for the allocation job, and the binding can be SIP. If my
proposal/example did not cover all cases of 1A-1D, that is no problem.
Just add another request/response pair for the other jobs.
 
SOAP is pretty much mainstream in the Java world and outside. Maybe
someone can support me in that it is a good protocol to get the resource
allocation job done.
 
Christian

________________________________

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

	Christian:
	
	Sorry, but I am still having trouble understanding your
proposal. Are you proposing we use non SIP means for resource
reservation? This feature is all about displaying dialog states to the
end user. Requesting a resource is just one aspect of the feature.  
	 
	For satisfactory operation of this feature, we would need two
subscriptions for dialog state at a minimum.
	 
	1. The first subscription is from the State Agent to the UA.
This is to ensure that the UA notifies the State Agent when:
	       (A) It answers an incoming call.
	       (B) It puts a call that it previously answered/placed on
Hold.
	       (C) Disconnects a call that it placed or answered.
	       (D) Decides to place an outbound call.
	
	Your idea of using a SUBSCRIBE/NOTIFY for line sieze/resource
reservation would get you (C) and (D) [and may be (A) if you choose to
send a NOTIFY before you answer the incoming call]. You will still
*need* to subscribe for the dialog state package as the State Agent will
have to provide the dialog identifiers to other UA's in the group (as
one of the feature requirements is that a UA can retrieve a call that is
put on Hold at another UA. This means the that UA from which you are
retrieving the Held call will need the SIP dialog identifiers to
populate the Replaces Header in the INVITE). 
	 
	2. The UA in the BLA group should SUBSCRIBE to the State Agent
for *dialog state*. This is needed to achieve the following:
	 
	    (A) Receive dialog identifier information of various calls
across the various UA's. This is to facilitate
	           -  display to the end user about the states of
various calls/dialogs (there might be one call that is active, one call
that is on hold, no call on a third and so on). 
	           - allow the end user to 'pick' a call that was put on
hold by some other UA (this would require dialog identifiers conveyed).
	
	Assuming that you agree with the above, which of the below were
you proposing? 
	 
	(A) Replace the subscription for dialog state from the State
Agent to the UA with some other event for resource reservation?
	(B) A  *new* Subscription for a new 'event' from the state agent
to the UA for the purposes of resource reservation?
	(C) use non SIP means for resource reservation.
	 
	Using a seperate event or non SIP means only for resource
reservations seems to open up a lot of interactions. You would now have
to start worrying about how failures (like timeouts, or error responses)
on one of them affects the other, what effect it would have on the end
UA behavior (so what would a UA show the state of a resource as if it
receives a message via dialog state indicating a line is in use, while
someone else reports using the other package/non SIP means that they are
using the line) and so on.... 

	Venkatesh

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

		CS

________________________________

			From: [email-masked] [mailto:
[email-masked] <mailto:[email-masked]> ] On Behalf
Of Christian Stredicke
			Sent: Friday, July 22, 2005 5:16 AM
			To: Venkatesh
			Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
			Subject: RE: [Sipping] Comments on
draft-anil-sipping-bla-02.txt

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

			<?xml version="1.0"?>  
			<env:Envelope xmlns:env="
http://schemas.xmlsoap.org/soap/envelope/
<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