RE: [Sipping] updated dialog package

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

Hi,

Filtering as a mechanism would work well if the phone is receiving the NOTIFY's from one single entity. In applications based on dialog state where the UA could be receiving NOTIFY's from various entities, this would amount to the UA having to establish filters at each such entity that is providing the UA notifications which like you rightly comment would amount to more filtering install traffic than any meaningful exchange of information. Definitely like I said in my earlier email and your comment, an end UA can simply discard NOTIFY's once it reaches it limits, but limiting NOTIFY's at the source if possible would be nice to have feature. 

Also, what I am requesting for is not radically redefining the error response for a NOTIFY. The 4xx response is STILL terminating subscriptions, but with a narrower scope (just subscriptions to the dialog that was presented to it in the payload of the NOTIFY).

thanks
Venkatesh

-----Original Message-----
From: Rohan Mahy [mailto:[e-mail]]
Sent: Wednesday, February 25, 2004 2:39 PM
To: Venkatesh Venkataramanan
Cc: Paul Pepper; Rohan Mahy; sipping
Subject: Re: [Sipping] updated dialog package


Hi,

We can't just redefine the meaning of error responses to a NOTIFY.  The 
behavior is very explicit in RFC3265 and its not package specific.  It 
means "terminate my subscription immediately".

What you seem to want to accomplish is a type of filtering.  We have 
requirements for filtering and a proposed mechanism even.  I think it 
would be useful to compare your requirements to that work.  However, I 
am usually fairly skeptical about the value of asking for filtering 
when it is easy to throw away the information you don't want.  
Obviously in the case of filtering spam, you want someone upstream to 
be able to do that, but in many other cases, sending around the 
filtering rules themselves generates more traffic than the traffic the 
filter would have removed...

thanks,
-rohan


On Feb 25, 2004, at 11:51 AM, Venkatesh Venkataramanan wrote:

> 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