Subject: [siprec] recording callee capabilities

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Jul 2011 11:42:13 -0400

Based on discussions, I think we ought to provide for capturing "callee 
capabilities" as defined in RFC 3840 in the metadata. This would give 
access to properties such as "isFocus" that could be significant.

As defined in 3840, callee capabilities are passed around as header 
field parameters of the Contact header, both in REGISTER requests and in 
Contacts specifying the remote target of dialogs. Its the ones in 
dialogs that make sense for siprec.

The main questions I see about this are:
- where in the metamodel do these belong?
- how should these be represented in XML?

Regarding where these belong in the metamodel:

My first thought is that they are attributes of a Participant. Typically 
participants correspond to UAs involved in a session (dialog).

A problem with that approach is that we plan to share Participants among 
multiple sessions. But a Participant may not report the same 
capabilities in every dialog it is involved in. For instance, while a UA 
may be *capable* of being a focus, it will probably only report the 
isFocus capability in dialogs where it is actually serving as a focus. 
(This probably is evidence that isFocus is not a proper capability.)

To solve this, an SRC might have to represent a UA involved in two 
sessions as two *different* participants in order to correctly report 
the capabilities UA in each session. That in turn would make it harder 
for the SRS to determine that the two sessions have a common participant.

In spite of this problem, and with reservations, I do propose that we 
make capabilities attributes of Participant. Each Participant would have 
zero or more Capabilities.

How to represent capabilities in XML?

In the ABNF syntax of 3840, each capability is encoded as a feature-param:

    feature-param    =  enc-feature-tag [EQUAL LDQUOT (tag-value-list
                        / string-value ) RDQUOT]
    enc-feature-tag  =  base-tags / other-tags
    base-tags        =  "audio" / "automata" /
                        "class" / "duplex" / "data" /
                        "control" / "mobility" / "description" /
                        "events" / "priority" / "methods" /
                        "schemes" / "application" / "video" /
                        "language" / "type" / "isfocus" /
                        "actor" / "text" / "extensions"
    other-tags      =  "+" ftag-name
    ftag-name       =  ALPHA *( ALPHA / DIGIT / "!" / "'" /
                       "." / "-" / "%" )
    tag-value-list  =  tag-value *("," tag-value)
    tag-value       =  ["!"] (token-nobang / boolean / numeric)
    token-nobang    =  1*(alphanum / "-" / "." / "%" / "*"
                       / "_" / "+" / "`" / "'" / "~" )
    boolean         =  "TRUE" / "FALSE"
    numeric         =  "#" numeric-relation number
    numeric-relation  =  ">=" / "<=" / "=" / (number ":")
    number          =  [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT]
    string-value    =  "<" *(qdtext-no-abkt / quoted-pair ) ">"
    qdtext-no-abkt  =  LWS / %x21 / %x23-3B / %x3D
                            / %x3F-5B / %x5D-7E / UTF8-NONASCII

(When the optional value part is missing, the default is "TRUE". This is 
specified in section 8 of 3841.)

This needs to be represented as an XML element that can be present zero 
or more times in the 'participant' element. I'm no xml expert, so I'm 
hoping for one to help get this right. I see a few general approaches to 
defining this element:

- as a single value containing the entire feature-param. E.g.
   <capability>isFocus="TRUE"</capability>

- passing the capability name and value as xml attributes. E.g.
   <capability name="isFocus" value="TRUE"/>
   In this case we could either make value optional, or require that
   the default be filled out.

- passing the name and value as subelements. E.g.
   <capability>
       <name>isFocus</name>
       <value>TRUE</value>
   </capability>
   Again we could require the value or allow it to be optional

- a hybrid of the above. E.g.
   <capabilty name="isFocus"/>
   or
   <capability name="isFocus">TRUE</capability>

Another possibility would be to take the parsing a step further and 
provide separate xml syntax for string-value and tag-value-list, 
breaking out the individual tag-values of the tag-value-list.

Even if we don't do that, there may be character set and escaping issues 
to deal with. The string-value uses quoted-pair from 3261 (a backslash 
followed by two hex digits) to represent some characters. I don't know, 
but suspect that is alien to xml, which has its own escaping 
conventions. And token-nobang includes some special characters - are any 
of them problematic for xml?

	Thanks,
	Paul

---

From: Alan Johnston <[email-masked]>
Date: Wed, 20 Jul 2011 11:24:39 -0500

This is how it is done in RFC 4235:

       <local>
          <identity display="Alice">sip:[email-masked]</identity>
          <target uri="sip:[email-masked]">
            <param pname="isfocus" pval="true"/>
            <param pname="class" pval="personal"/>
          </target>
        </local>

- Alan -

On Wed, Jul 20, 2011 at 10:42 AM, Paul Kyzivat <[email-masked]> wrote:
> capabilities" as defined in RFC 3840 in the metadata. This would give access
> to properties such as "isFocus" that could be significant.
>
> As defined in 3840, callee capabilities are passed around as header field
> parameters of the Contact header, both in REGISTER requests and in Contacts
> specifying the remote target of dialogs. Its the ones in dialogs that make
> sense for siprec.
>
> multiple sessions. But a Participant may not report the same capabilities in
> every dialog it is involved in. For instance, while a UA may be *capable* of
> being a focus, it will probably only report the isFocus capability in
> dialogs where it is actually serving as a focus. (This probably is evidence
> that isFocus is not a proper capability.)
>
> To solve this, an SRC might have to represent a UA involved in two sessions
> as two *different* participants in order to correctly report the
> capabilities UA in each session. That in turn would make it harder for the
> SRS to determine that the two sessions have a common participant.
>
> In spite of this problem, and with reservations, I do propose that we make
> capabilities attributes of Participant. Each Participant would have zero or
> more Capabilities.
>
> This needs to be represented as an XML element that can be present zero or
> more times in the 'participant' element. I'm no xml expert, so I'm hoping
> for one to help get this right. I see a few general approaches to defining
> this element:
>
> Another possibility would be to take the parsing a step further and provide
> separate xml syntax for string-value and tag-value-list, breaking out the
> individual tag-values of the tag-value-list.
>
> Even if we don't do that, there may be character set and escaping issues to
> deal with. The string-value uses quoted-pair from 3261 (a backslash followed
> by two hex digits) to represent some characters. I don't know, but suspect
> that is alien to xml, which has its own escaping conventions. And
> token-nobang includes some special characters - are any of them problematic
> for xml?
>
>        Thanks,
>        Paul
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Jul 2011 13:51:09 -0400

>              <param pname="class" pval="personal"/>

Thanks Alan, I didn't think of that.
It does provide a precedent we can consider following.

It carries arbitrary contact parameters, not just capabilities.
We can do that too.

I am a little concerned about something it does (4.1.6.2):

    It can contain a list of Contact header parameters in param sub-
    elements (such as those defined in [10]).  The param element contains
    two required attributes, pname and pval.  Boolean parameters are
    represented by the explicit pval values, "true" and "false" (for
    example, when a feature parameter is explicitly negated).  Parameters
    that have no value at all are represented by the explicit pval value
    "true".   The param element itself has no contents.  To avoid
    repeating Contact information in each request, the subscriber can
    assume that the target URI and parameters are the same as in previous
    notifications if no target element is present in the corresponding
    local or remote element.  If a target element is present in the local
    or remote part of a notification, the new target tag and list of
    parameter tags completely supersedes the old target and parameter
    list in the corresponding part.  Note that any quoting (including
    extra angle-bracket quoting used to quote string values in [10]) or
    backslash escaping MUST be removed before being placed in a pval
    attribute.  Any remaining single quotes, double quotes, and
    ampersands MUST be properly XML escaped.

If I am not mistaken, the removal of the angle quoting used to 
distinguish string-values introduces an ambiguity, in that it will then 
be impossible to distinguish a string-value from a tag-value-list. That 
may be a bug in 4235. I'll have to look into that. Fixing that bug will 
require more than a token change.

	Thanks,
	Paul

> On Wed, Jul 20, 2011 at 10:42 AM, Paul Kyzivat<[email-masked]>  wrote:
>>    string-value    =  "<" *(qdtext-no-abkt / quoted-pair )">"

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Jul 2011 10:42:44 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 20 July 2011 16:42
> To: Ram Mohan R (rmohanr); Parthasarathi R (partr)
> Cc: [email-masked]
> Subject: [siprec] recording callee capabilities
> 
[JRE] I do agree with this, and you may recall I was a little uncomfortable about sharing a Participant across multiple CSs. Looking at that issue again, there are two obvious ways in which an SRC can conclude that a participant is common between two CSs:
1. They share the same identity. But since the identity (AoR) is forwarded to the SRS as an attribute of the Participant object, the SRS will have this information and be able to correlate Participant objects from different CS objects.
2. The SRC is aware that the CS has been created as a result of call transfer and one of the participants is assumed to be common between the two CSs. Even if the participant identity is unavailable or ambiguous (e.g., anonymous), we have the CS grouping mechanism to tell the SRS that the two recordings are somehow related.

So I would be happy to have the restriction that a Participant object relates only to a single CS and therefore allow the object to reflect the callee capabilities of that participant.

John (as individual)

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.