RE: [Sipping] updated dialog package

["Venkatesh Venkataramanan" <[e-mail]>]

Also while we are at the topic of being able to reject NOTIFY's without terminating subscriptions, another useful capability to have would be for a UA to reject a NOTIFY with a specific response code so that any NOTIFY's for that dialog alone can be supressed. For example with SLA there may be UA's in the group that are of varying capabilities. For example UA1 can have capabilities to display say 2 active dialogs at any point, while UA2 can have capabilities that permit it to show upto 5 active dialogs. When both the UA's are subscribed to dialog state, they receive dialog states of all dialogs. Now, if UA1 had an ability to respond to a NOTIFY for a third active dialog saying "Dont terminate my subscriptions; I want to continue getting notifications for all dialogs, but supress anything for this specific dialog as I have reached my limits", then it would avoid un-necessary NOTIFY overheads being sent towards UA1 and it having to accept it and throwing it away; keep track of what dialogs it has accepted without UI, so that all new NOTIFY's towards this dialog id are continued to be discarded silently ......

Venkatesh

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of
Rohan Mahy
Sent: Wednesday, February 25, 2004 9:29 AM
To: Paul Pepper
Cc: Rohan Mahy; sipping
Subject: Re: [Sipping] updated dialog package



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



_______________________________________________
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