Re: [splices] SIP INVOKE method v1

"Hutton, Andrew" <> Mon, 13 June 2011 14:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A563D9E800B for <>; Mon, 13 Jun 2011 07:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b-9-taAVbySG for <>; Mon, 13 Jun 2011 07:04:07 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 559699E8009 for <>; Mon, 13 Jun 2011 07:04:07 -0700 (PDT)
X-VirusChecked: Checked
X-StarScan-Version: 6.2.17; banners=-,-,-
X-Originating-IP: []
Received: (qmail 14180 invoked from network); 13 Jun 2011 14:04:06 -0000
Received: from unknown (HELO senmx11-mx) ( by with SMTP; 13 Jun 2011 14:04:06 -0000
Received: from (unknown []) by senmx11-mx (Server) with ESMTP id 08CF41EB83D3; Mon, 13 Jun 2011 16:04:06 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Mon, 13 Jun 2011 16:04:06 +0200
From: "Hutton, Andrew" <>
To: Paul Kyzivat <>, "" <>
Date: Mon, 13 Jun 2011 16:04:03 +0200
Thread-Topic: [splices] SIP INVOKE method v1
Thread-Index: AcwnpwHyWdPZ0GtcQdet0Lc+UVQPIgCJvnyQ
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
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-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Jun 2011 14:04:08 -0000

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.  


> -----Original Message-----
> From: [] On
> Behalf Of Paul Kyzivat
> Sent: 10 June 2011 20:46
> To:
> 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.
> >
> >
> >
> > We would appreciate it if you review the document and provide us with
> > your feedback.
> >
> > Thanks,
> >
> > Rifaat
> >
> >
> >
> > _______________________________________________
> > splices mailing list
> >
> >
> _______________________________________________
> splices mailing list