Subject: RE: [Sipping] updated dialog package

From: "Paul Pepper" <[email-masked]>
Date: Wed, 25 Feb 2004 15:32:25 -0000

Hi,

Comments in-line.

Thanks,

Paul.

> -----Original Message-----
> 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).

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

> > 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:[email-masked]]
> >> Sent: Thursday, February 19, 2004 6:00 PM
> >> To: sipping
> >> Cc: [email-masked]
> >> 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 [email-masked] for questions on current sip
> >> Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 25 Feb 2004 09:28:50 -0800

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

> 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