Subject: RE: [Sipping] updated dialog package

From: "Paul Pepper" <[email-masked]>
Date: Mon, 23 Feb 2004 17:40:55 -0000

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.

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.

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.

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: Mon, 23 Feb 2004 19:14:24 -0800

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

> 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-list-04.txt

> (pname="+activity" pval="noninteractive"), so I assume they're

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