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

From: "Christian Stredicke" <[email-masked]>
Date: Tue, 19 Jul 2005 11:49:41 +0200

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

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

Last, the formatting of the document seems to be not 100 % IETF draft
compliant.
 
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

---

From: Venkatesh <[email-masked]>
Date: Tue, 19 Jul 2005 11:29:46 -0700

Christian:

Thanks for your comments. Replies inline...

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

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

> resource allocation would be independant from that.

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

> compliant.

 Will fix this.
 Thanks
Venkatesh

CS