Subject: [Sipping] updated dialog package

From: Rohan Mahy <[email-masked]>
Date: Thu, 19 Feb 2004 09:59:42 -0800

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Fri, 20 Feb 2004 13:07:41 -0800

Hi:

From a shared line application perspective:

* Altering the dialog state draft to support sending NOTIFY before phone actually goes off-hook was required !

* There are a piece missing from a implementation perspective for shared line appearances. 

   - Ability to signal Hold. I know there have been a few discussions in the SIPPING mailing list around this and it there was no conclusion about what "hold" actually is ! However, one of the important aspects of shared lines is the ability to communicate a held call to the other parties in the group. Currently the anil-sipping-bla draft uses the SDP information to help other UA's decide a dialog is transitioning to hold and off hold. It would be definitely useful to have the dialog state express this state to the far end rather than having to send out SDP information. For the purpose of SLA, instead of going down defining what is Hold, I was wondering if we can create  a state/or an attribute in the dialog state package say "pickable" dialog to indicate the same. I've heard comments saying a UA can block relevant fields of a dialog whenever it wants others to be able to pick or not to pick a dialog, however the same is not clean and it breaks when say the same UA that put the dialog on Hold, retrieves the dialog. Nothing in the dialog identifiers have changed.

The anil-sipping-bla-draft covers other various aspects of SLA from an application implementation perspective with call flow examples.

regards,
Venkatesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Rohan Mahy
Sent: Thursday, February 19, 2004 10:00 AM
To: sipping
Cc: [email-masked]
Subject: [Sipping] updated dialog package

Hi Everyone,

many thanks,
-rohan

---

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Thu, 26 Feb 2004 09:49:54 -0800

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:[email-masked]]
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
>
> 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.
>>
>>> From: Rohan Mahy [mailto:[email-masked]]
>>> 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.
>>>>
>>>>> From: Rohan Mahy [mailto:[email-masked]]
>>>>> Sent: Thursday, February 19, 2004 6:00 PM
>>>>> To: sipping
>>>>> Cc: [email-masked]
>>>>> Sipping mailing list
>>>>> https://www1.ietf.org/mailman/listinfo/sipping
>>>>> This list
>>>>> is for NEW development of the application of SIP