Re: [Sipping] updated dialog package

[Rohan Mahy <[e-mail]>]

On Feb 25, 2004, at 7:32 AM, Paul Pepper wrote:

> Hi,
>
> Comments in-line.
>
> Thanks,
>
> Paul.
>
>> -----Original Message-----
>> From: Rohan Mahy [mailto:[e-mail]]
>> Sent: Tuesday, February 24, 2004 3:14 AM
>> To: Paul Pepper
>> Cc: Rohan Mahy; sipping
>> Subject: Re: [Sipping] updated dialog package
>>
>>
>>
>> On Feb 23, 2004, at 9:40 AM, Paul Pepper wrote:
>>
>>> Hi,
>>>
>>> I work for a company that has developed handset gateway devices that
>>> enable legacy, digital, business-grade telephones to be driven using
>>> SIP.  For example, this enables an existing legacy PBX user
>>> to retain
>>> their telephones and cabling, but to replace the PBX by a
>>> Softswitch or
>>> IP Centrex system.  As most business-grade telephone
>>> systems make use
>>> of
>>> a shared line facility, the addition of a shared line example to the
>>> dialog event package ID is of great interest to us, and others who
>>> support these types of feature.
>>>
>>> Although incorporating a shared line example is a step
>>> towards a common
>>> approach to shared line implementation, I don't believe it goes far
>>> enough.  Our current implementation of shared lines has
>>> shown that the
>>> following issues need to be addressed by the spec, and
>>> should be shown
>>> in the examples:
>>>
>>> o Line seize, an essential part of any shared line
>>> implementation, is
>>> not adequately described. When more than one user agent attempts to
>>> seize a line at approximately the same instant, a race condition
>>> arises.
>>> No description of how to handle the race is given - an example
>>> application/dialog-info+xml NOTIFY payload is provided, but
>>> this alone
>>> is inadequate, as message sequencing is an important part
>>> of seizing a
>>> line.  The Line Seize condition will be covered in the
>>> "anil-sipping-bla-draft" that Venkatesh refers to.
>>
>> Line seizure is well beyond what would be appropriate to
>> standardize in
>> SIPPING because for many types of UAs that concept does not
>> even exist.
>>   I was just trying to demonstrate a non-normative
>> description of how it
>> could be implemented. How you judge who "wins" a seizure race
>> condition
>> is an implementation specific issue.  In fact, its quite likely that
>> different behaviors will be desired by different customers.  When
>> talking about implementing this at Cisco, we concluded that a
>> configuration knob was needed to satisfy essentially opposite
>> requirements from two different customers.  Each customer was equally
>> adamant that he was "right" and the other was "wrong".  As a
>> result, I
>> find it unlikely that SIPPING could come to come to consensus on what
>> "proper seizing behavior" is even if we ignored the fact that
>> the bulk
>> of deployed SIP UAs are software UAs which have no lines to seize.
>>
>
>
> Yes, determining which user agents should win seize races is a matter 
> of
> policy, and implementation specific. However, the mechanism used to
> convey whether a seize race has been won seems to be a matter for
> standardisation (e.g. a non-200 final response to the NOTIFY requesting
> the seize could indicate that the seize operation has failed).

Now I see what you are getting at.  The particular mechanism that you 
mention is unlikely to go over favorably because it would have the side 
effect of terminating your subscription.  However, I agree it would be 
useful to have a standard way to convey something like this.  I'm not 
convinced that this belongs in the dialog package, but I'll think about 
this.


>>> o Handling of multiple instances of a shared line has been
>>> overlooked.
>>> On business-grade PBX systems a line will roughly
>>> correspond to an AOR.
>>> However, many such systems permit multiple "instances" of a
>>> shared line
>>> to appear on a single endpoint. For example, a number of
>>> instances of a
>>> "product support" shared line might appear on all the
>>> endpoints of the
>>> product support group, thereby allowing multiple calls to
>>> be taken and
>>> passed around within the group.
>>
>> This has not been overlooked at all.  You can have multiple
>> subscriptions (one per AOR), or you can subscribe to a list of AORs
>> with the event list extension:
>>
>> 	
>> http://www.ietf.org/internet-drafts/draft-ietf-simple-event-li
>> st-04.txt
>>
>
> I haven't been sufficiently clear on this point. As you point out, each
> shared AOR will have its own subscription. Take an example AOR of
> support@example. Although a single registration and two subscriptions
> (one in each direction, as subscriber and notifier, if a state agent is
> used) are used per AOR on each user agent, multiple calls to/from that
> AOR may be active at any time. If a user agent has the shared line
> capability then all calls to support@example will be presented on it 
> by,
> say, illuminating one button per call. (Of course this is constrained 
> to
> varying degrees by the user agent's display capabilities.) As each
> button shows a call to support@example the calls must be presented on
> those buttons in a consistent manner across all user agents on the
> network. This will allow Harry to put a call to support@example on hold
> and verbally tell Thelma which button to press in order to pick that
> call up. If all the calls to support@example are presented in an
> arbitrary manner on different user agents, then the coherency of call
> presentation is lost. This is a problem as coherent call presentation 
> is
> a requirement of existing PBX users, and gives the only meaningful use
> for this feature.
>
> One way of achieving a consistent mapping of calls to buttons (if
> buttons are the user interface mechanism used) is to index buttons on
> all the user agents. That way, a call can be mapped to the specific
> button on all user agents of an installation.

I expect that any such index would be conveyed as a target URI 
parameter using a device ID of some sort.  There is agenda time 
scheduled in SIPPING to discuss Instance ID requirements with the 
following reading list:

draft-stucker-sip-guid-00.txt
draft-jennings-sipping-instance-id-00.txt
draft-ietf-xmpp-core-22.txt (section 2.3)

thanks,
-rohan


>>> o The mechanism used to convey that a call has been placed on hold
>>> appears to rely upon implementation-specific parameters,
>>> found in the
>>> xml's <param> element. I can't see any reference to
>>> definitions of the
>>> values used by this element's pname and pval attributes
>>> (pname="+activity" pval="noninteractive"), so I assume they're
>>> non-standard.
>>
>> This was due to distraction on my part.  I had intended to include a
>> discussion of this in the current draft, but somehow left it
>> out at 2am
>> the day of the draft deadline.  I'm terribly sorry about that.  I'll
>> send out more about the hold issue tomorrow.
>>
>> thanks,
>> -rohan
>>
>>> Thanks,
>>>
>>> Paul.
>>>
>>>> -----Original Message-----
>>>> From: Rohan Mahy [mailto:[e-mail]]
>>>> Sent: Thursday, February 19, 2004 6:00 PM
>>>> To: sipping
>>>> Cc: [e-mail]
>>>> Subject: [Sipping] updated dialog package
>>>>
>>>>
>>>> Hi Everyone,
>>>>
>>>> I've updated the dialog packages with the changes we agreed to in
>>>> Minneapolis (removing CSeq and the Route-Set).
>>>>
>>>> I've also provided a detailed example of using the dialog
>>>> package for a
>>>> "shared-line" application.  I apologize for my tardiness
>>>> here.  I was
>>>> supposed to post something shortly after the meeting.  I
>>>> any case, I
>>>> believe this demonstrates that the current syntax is at least
>>>> sufficient for the use cases we've discussed.  I would like to hear
>>>> from all of you if this does the trick.
>>>>
>>>> many thanks,
>>>> -rohan
>>>>
>>>>
>>>> _______________________________________________
>>>> Sipping mailing list
>>>> https://www1.ietf.org/mailman/listinfo/sipping
>>>> This list
>>>> is for NEW development of the application of SIP
>>>> Use [e-mail] for questions on current sip
>>>> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP