Re: [splices] SIP INVOKE method v1

"Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com> Tue, 14 June 2011 17:42 UTC

Return-Path: <rifatyu@avaya.com>
X-Original-To: splices@ietfa.amsl.com
Delivered-To: splices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAB411E8192 for <splices@ietfa.amsl.com>; Tue, 14 Jun 2011 10:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.036
X-Spam-Level:
X-Spam-Status: No, score=-3.036 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-iRBuuSqN4E for <splices@ietfa.amsl.com>; Tue, 14 Jun 2011 10:42:12 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 504AD11E8195 for <splices@ietf.org>; Tue, 14 Jun 2011 10:42:12 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag8BAGKc902HCzI1/2dsb2JhbABSl0yPB3eIc6RQApwEhiQEljyLDw
X-IronPort-AV: E=Sophos;i="4.65,365,1304308800"; d="scan'208";a="251336987"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Jun 2011 13:42:10 -0400
X-IronPort-AV: E=Sophos;i="4.65,365,1304308800"; d="scan'208";a="666075107"
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Jun 2011 13:42:09 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 14 Jun 2011 13:42:08 -0400
From: "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>
To: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>, Paul Kyzivat <pkyzivat@cisco.com>, "splices@ietf.org" <splices@ietf.org>
Date: Tue, 14 Jun 2011 13:42:08 -0400
Thread-Topic: [splices] SIP INVOKE method v1
Thread-Index: AcwnpwHyWdPZ0GtcQdet0Lc+UVQPIgCJvnyQADiYGNAAANdDQAABoVVg
Message-ID: <6369CB70BFD88942B9705AC1E639A33822CDA8144A@DC-US1MBEX4.global.avaya.com>
References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> <6369CB70BFD88942B9705AC1E639A33822CDA812C4@DC-US1MBEX4.global.avaya.com> <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net>
In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [splices] SIP INVOKE method v1
X-BeenThere: splices@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <splices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/splices>, <mailto:splices-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/splices>
List-Post: <mailto:splices@ietf.org>
List-Help: <mailto:splices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/splices>, <mailto:splices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2011 17:42:13 -0000

Andy,

> The list of potential actions and associated parameters is huge and for this
> kind of problem I believe that an XML body would be a much better solution. I
> guess I much prefer XML to BNF.
> 
This actually calls for a header rather than an XML body, because the idea is to control what get standardized and what not and clearly define the actions that get standardized. With an XML body you actually create a tunnel over SIP and you lose control over what get defined.

Regards,
 Rifaat


> -----Original Message-----
> From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]
> Sent: Tuesday, June 14, 2011 1:18 PM
> To: Shekh-Yusef, Rifaat (Rifaat); Paul Kyzivat; splices@ietf.org
> Subject: RE: [splices] SIP INVOKE method v1
> 
> Hi Rifaat,
> 
> I am not saying that the current proposal is not extensible but I believe that
> an XML body would be a much better solution to the extensibility problem that
> using a SIP header.
> 
> The list of potential actions and associated parameters is huge and for this
> kind of problem I believe that an XML body would be a much better solution. I
> guess I much prefer XML to BNF.
> 
> There is also an architectural issue as the actions don't relate directly to
> the management of the SIP session and therefore most likely need to passed to
> the application layer in the SIP UA to handle. It is much cleaner
> architecturally if the body can simply be removed and passed to the
> responsible component in the UA rather than the SIP component having to
> extract the information from SIP headers.
> 
> Regards
> Andy
> 
> 
> 
> 
> > -----Original Message-----
> > From: Shekh-Yusef, Rifaat (Rifaat) [mailto:rifatyu@avaya.com]
> > Sent: 14 June 2011 17:32
> > To: Hutton, Andrew; Paul Kyzivat; splices@ietf.org
> > Subject: RE: [splices] SIP INVOKE method v1
> >
> > Andy,
> >
> > > The issue is I believe extensibility which any mechanism for
> > > invoking services will need and this is the reason why an XML body
> > would be
> > > better than using SIP headers.
> >
> > What makes you think that the current proposal is not extensible?
> >
> > Regards,
> >  Rifaat
> >
> >
> > > -----Original Message-----
> > > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On
> > Behalf Of
> > > Hutton, Andrew
> > > Sent: Monday, June 13, 2011 10:04 AM
> > > To: Paul Kyzivat; splices@ietf.org
> > > Subject: Re: [splices] SIP INVOKE method v1
> > >
> > > Hi All,
> > >
> > > Whilst I still question whether the mechanism described in this draft
> > actually
> > > falls within the SPLICES WG charter as it defines new mechanism I
> > have a few
> > > comments.
> > >
> > > I tend to agree with Paul's comments below but would go further to
> > say that
> > > even some of the supposedly simply actions such as "decline" &
> > "ignore" are
> > > also features which will be difficult to agree the semantics for. All
> > of the
> > > actions will need to be specified rigorously a quick look at ECMA-269
> > which
> > > specifies these kind of services for CSTA will give you an idea of
> > what would
> > > need to be done. I don't believe that even in the CSTA world which
> > defines a
> > > very large number of services the services "ignore" or "decline" were
> > > specified.
> > >
> > > With regard to the discussion on headers vs body the draft states.
> > >
> > > "There has been some discussion on the list on the question of header
> > field vs
> > > message body.  This is not the real issue, as either could
> > conceivably be
> > > used.  Instead, the main issue is what is being invoked:  is it a
> > named
> > > feature/action/event, or is it a script".
> > >
> > > I must have missed the discussion about scripting but I don't think
> > this is
> > > the issue. The issue is I believe extensibility which any mechanism
> > for
> > > invoking services will need and this is the reason why an XML body
> > would be
> > > better than using SIP headers.
> > >
> > > Regards
> > > Andy
> > >
> > >
> > > > -----Original Message-----
> > > > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On
> > > > Behalf Of Paul Kyzivat
> > > > Sent: 10 June 2011 20:46
> > > > To: splices@ietf.org
> > > > Subject: Re: [splices] SIP INVOKE method v1
> > > >
> > > > This is getting better with age!
> > > >
> > > > Splitting off the subscription is good.
> > > >
> > > > An area that still needs work is in the semantics of the urns.
> > > > Some of them are more clear than others. Some are "limited" in ways
> > > > that
> > > > might not matter to some but that could prove a problem in the end.
> > > > Specifically:
> > > >
> > > >      o  Answer call       - urn:invoke:call:answer
> > > >      o  Terminate call    - urn:invoke:call:terminate
> > > >      o  Decline call      - urn:invoke:call:decline
> > > >      o  Ignore call       - urn:invoke:call:ignore
> > > >
> > > > The above need some elaboration, but I think its just work -
> > probably
> > > > anybody who does it will end up with an equivalent result.
> > > >
> > > >      o  Send call to VM   - urn:invoke:call:sendvm
> > > >
> > > > VM is a "feature", and we haven't standardized features much,
> > except
> > > > for
> > > > bliss. How does one know if the recipient understands VM and what
> > to do
> > > > to send a call there? What if there are multiple VM options (e.g.
> > what
> > > > to say, etc.) And what if the call isn't a voice call. (Maybe VM
> > now
> > > > means voice/video mail. But the "call" could be IM.)
> > > >
> > > >      o  Hold call         - urn:invoke:call:hold
> > > >      o  Unhold call       - urn:invoke:call:unhold
> > > >      o  Mute call         - urn:invoke:call:mute
> > > >      o  Unmute call       - urn:invoke:call:unmute
> > > >
> > > > Similarly these are all "features" that we all have some
> > expectations
> > > > about, but that are not rigorously defined. (But perhaps
> > Mute/Unmute
> > > > could be formalized by using the 'transducer' option.
> > > > (Transducer=none?)
> > > >
> > > > My concern with all these "features" is that we are being put into
> > a
> > > > box
> > > > where we must either:
> > > > - define them with sufficient rigor
> > > > - fall back on "do what I mean", which has proved to be a bad idea,
> > > >    because not everybody has the same notion of what they mean.
> > > >
> > > >      o  Conference        - urn:invoke:conference:add
> > > >                           - urn:invoke:conference:remove
> > > >
> > > > This one may be clearer due to the existence of xcon specs.
> > > >
> > > > Regarding action parameters:
> > > >
> > > >      o  media=audio|video|audvid
> > > >
> > > > I'm troubled by audvid. I would rather see "audio,video".
> > Specifically,
> > > > what is the namespace here, and what does specifying it mean? I
> > think
> > > > the namespace could be: one or more values allowable as the <media>
> > > > parameter in the m-line in SDP.
> > > >
> > > > Defining exactly what it means when present is a little harder.
> > When
> > > > answering a call that has an offer, I guess it could mean: refuse
> > any
> > > > m-lines with media type that doesn't match one of these, and accept
> > as
> > > > many of the remaining as you can.
> > > >
> > > > For answering an offerless invite, I guess it could mean: offer
> > > > whatever
> > > > media you are capable of offering that match one of these, but
> > don't
> > > > offer anything that doesn't match.
> > > >
> > > > Is there likely to be a need to get more specific? E.g. about what
> > > > codecs to use? (Hopefully not - that could get very messy.)
> > > >
> > > >      o  transducer=speaker|headset
> > > >
> > > > My deskphone has three possibilities: speaker|headset|handset.
> > > > And I'm far from certain this is exhaustive. (The clue wg is
> > defining a
> > > > much more complex environment.) This at least needs to be
> > extensible.
> > > > We
> > > > may need some sort of extended model of a UA that includes this
> > sort of
> > > > stuff.
> > > >
> > > >      o  target=<AOR>
> > > >      o  direction=recvonly|sendonly|sendrecv
> > > >      o  abort
> > > >
> > > > None of this is intended as objection to the work so far. Its just
> > a
> > > > start at identifying what else there is to do. The whole notion of
> > > > naming features to invoke causes me the most concern.
> > > >
> > > > 	Thanks,
> > > > 	Paul
> > > >
> > > > On 6/10/2011 3:08 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> > > > > Hi,
> > > > >
> > > > > We have just submitted a new version of the SIP INVOKE method
> > draft
> > > > that
> > > > > does not include implicit subscription.
> > > > >
> > > > > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/
> > > > >
> > > > > We would appreciate it if you review the document and provide us
> > with
> > > > > your feedback.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Rifaat
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > splices mailing list
> > > > > splices@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/splices
> > > > _______________________________________________
> > > > splices mailing list
> > > > splices@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/splices
> > > _______________________________________________
> > > splices mailing list
> > > splices@ietf.org
> > > https://www.ietf.org/mailman/listinfo/splices