Re: [splices] SIP INVOKE method v1

Paul Kyzivat <> Fri, 10 June 2011 19:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5342F11E8113 for <>; Fri, 10 Jun 2011 12:45:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.354
X-Spam-Status: No, score=-110.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8h7I+jTg8ZcY for <>; Fri, 10 Jun 2011 12:45:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E2A2B11E80B7 for <>; Fri, 10 Jun 2011 12:45:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3982; q=dns/txt; s=iport; t=1307735139; x=1308944739; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=aEDbIzgjmKDRglp53kXF0xk9rXq68YuKvoEIXZBrDPc=; b=Gw3DSRbpm35nSSyoxqJDsdPpNDbMwcEr1oCE/qC7WJ/gxlPD44J5/J/1 wa+PV/96ak1J049D6UTy4wD3ndDpxVKP3nNwJmRK2fJ4y3G8w3Th7K1c5 lUo172AyJKp8Fvecv9DGAxnG94QGYE/kTD68NLj8UwLL13ar4RGVY+Ugm s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EABB08k2tJV2c/2dsb2JhbABSpk13pw6eCYYjBJErhE6LJQ
X-IronPort-AV: E=Sophos;i="4.65,348,1304294400"; d="scan'208";a="287059860"
Received: from ([]) by with ESMTP; 10 Jun 2011 19:45:38 +0000
Received: from [] ( []) by (8.14.3/8.14.3) with ESMTP id p5AJjbUD027213 for <>; Fri, 10 Jun 2011 19:45:38 GMT
Message-ID: <>
Date: Fri, 10 Jun 2011 15:45:37 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Fri, 10 Jun 2011 19:45:41 -0000

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.

     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 

     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.


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