Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 1 Nov 2014 13:15:14 +0000

Here is a initial proposal for including INSIPID sessionID in metadata XML schema. Since a CS is a logical entity and can have multiple SIP dialogs as Paul said we should potentially allow a Session XML element to have 1 or more SessionIDs in them.

So I suggest we can include
1) SessionID (with the XML element name as “SessionID”) as a child element inside <session> XML element).
2) An instance of <session> XML element must have atleast 1  <sessionID> element and MAY have  more as well

For e.g:

<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
   <start-time>2010-12-16T23:41:07Z</start-time>
    <sessionID>i1Pz3to5hGk8fuXl+PbwCw==</sessionID>
</session>

3) A question - Since a CS can have multiple Session Ids (due to the fact that a CS can have multiple SIP dialogs) is there a need to know to which SIP dialog a SessionID belongs to ?

Schema updates:
Current Schema for session in ver 16 of draft
 <xs:complexType name="session">
  <xs:sequence>
   <xs:element name="reason" type="tns:reason" minOccurs="0"
       maxOccurs="unbounded"/>
   <xs:element name="group-ref" type="xs:base64Binary"
      minOccurs="0" maxOccurs="1"/>
   <xs:element name="start-time" type="xs:dateTime"
     minOccurs="0" maxOccurs="1"/>
   <xs:element name="stop-time" type="xs:dateTime"
     minOccurs="0" maxOccurs="1"/>
   <xs:any namespace='##other'
          minOccurs='0'
          maxOccurs='unbounded'
          processContents='lax'/>
  </xs:sequence>
<xs:attribute name="session_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>

Updated schema with the proposed change:
  <xs:complexType name="session">
  <xs:sequence>
  <xs:element name=“sessionID” type=xs:base64Binary” minOccurs=“1”
     maxOccurs=“unbounded”/>
   <xs:element name="reason" type="tns:reason" minOccurs="0"
       maxOccurs="unbounded"/>
   <xs:element name="group-ref" type="xs:base64Binary"
      minOccurs="0" maxOccurs="1"/>
   <xs:element name="start-time" type="xs:dateTime"
     minOccurs="0" maxOccurs="1"/>
   <xs:element name="stop-time" type="xs:dateTime"
     minOccurs="0" maxOccurs="1"/>
   <xs:any namespace='##other'
          minOccurs='0'
          maxOccurs='unbounded'
          processContents='lax'/>
  </xs:sequence>
<xs:attribute name="session_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>

Please let me know your comments/suggestions.

Ram

-----Original Message-----
From: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Date: Friday, 10 October 2014 7:53 am
To: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>, Parthasarathi R <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata

Hi Paul,

-----Original Message-----
From: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
Date: Friday, 10 October 2014 7:02 am
To: Parthasarathi R <[email-masked]<mailto:[email-masked]>>, Cisco Employee
<[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata

One thing to keep in mind is that a single siprec session may correspond
to multiple sip dialogs. (E.g. when a conference focus is the SRC.) So
we should probably allow multiple insipid session-ids.

Good point. Agree that we may have such a scenario where multiple insipid
session-ids may need to be carried in the metadata.

Ram

Alternately CS groups might be used for that. In *some* cases a CS group
might correspond to a *half* insipid session-id. But that need not be
the case. I doubt we need to talk about that.

Thanks,
Paul

On 10/9/14 8:15 PM, Parthasarathi R wrote:
Hi Ram,

I agree with Paul & you for adding optional XML element to carry INSIPID
session-id.

We need to clearly explain the interaction of CS group id with INSIPID
session-id as INSIPID session-id shall act as CS group ID as well.
Updating
example draft with the usage of these unique-id for call transfer
scenario
will provide better clarity.

Thanks
Partha

-----Original Message-----
From: siprec [mailto:[email-masked]] On Behalf Of Ram Mohan R
(rmohanr)
Sent: Wednesday, October 08, 2014 10:28 PM
To: Paul Kyzivat; [email-masked]<mailto:[email-masked]>
Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata

To add to below, One issue I see by mapping INSIPID Session_id to CS
xml
id is -  when a SRS receives metadata it will not know if the received
id
in CS is INSIPID session_id or SRC generated UUID. It is important for
SRS
to know this, since INSIPID session_id scope is much larger and the SRS
may want to use that Session_id for some other things.

Ram

-----Original Message-----
From: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 8 October 2014 10:13 pm
To: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>
Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata

Hi Paul,

Please see inline

-----Original Message-----
From: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 8 October 2014 9:57 pm
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata

On 10/8/14 2:45 AM, Ram Mohan R (rmohanr) wrote:
We had discussed this in the past (see this archive email -
http://www.ietf.org/mail-archive/web/insipid/current/msg00285.html)
however at that time since INSIPID WG and Session-ID document was
in
early
stage we deferred including Session-ID in the metadata. Now that
Session-ID is a mature document I believe it is good to include the
same
in the Metadata XML as part of CS.

My initial thought is to include it as a element of CS.

Let me know your thoughts ?

IMO we can't depend on the session id being present, so we can't use
it
as one of our identifiers.

Yes. Agree. What I am saying if a CS has INSIPID Session_id present
and a
SRC who is part of that CS happens to read this id, then it can pass
it in
the metadata to SRS. IMO the SRC need not worry about how the INSIPID
session_id is derived. All we need is a carrier(field) to carry the
received Session_id to SRS. Note this is independent of the ids we
have in
the XML. The ids we have will continue to be present. I don¹t see a
need
to link.

SRCs that want to coordinate, and that know they are in an
environment
that uses session-id *could* derive their IDs based on the session-
id.

Well I don¹t know if we want to say that and create some dependancy. I
am
open to have that but think it can create confusion as we need to
define
both the cases (when Session_id present and when it is not). Rather I
would think we should leave the current CS Id scope as is.

We wouldn't have to standardize that, but it would only work with
SRCs
that have an agreement.

We could also allow the session-id to be added as an optional element
in
the metadata.

Yes that is what I was coming to. We need a field in metadata
(possibly a
child XML element inside <session> element) that can carry INSIPID
session_id of CS ( if present in CS) as is to SRS. An SRS may use it
for
relating sessions or for whatever it needs.

Regards,
Ram

That wouldn't cause two SRCs in the same call to choose
the same siprec id for the call, but the SRS could then correlate
them.

Thanks,
Paul

_______________________________________________
siprec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/siprec

_______________________________________________
siprec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/siprec

_______________________________________________
siprec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 01 Nov 2014 10:51:38 -0400

On 11/1/14 9:15 AM, Ram Mohan R (rmohanr) wrote:
> Here is a initial proposal for including INSIPID sessionID in metadata
> XML schema. Since a CS is a logical entity and can have multiple SIP
> dialogs as Paul said we should potentially allow a Session XML element
> to have 1 or more SessionIDs in them.
>

You want to *require* a SessionID????? Why?

> </session>
> *3) A question - Since a CS can have multiple Session Ids (due to the
> fact that a CS can have multiple SIP dialogs) is there a need to know to
> which SIP dialog a SessionID belongs to ? *
>
> Schema updates:
> *  <xs:element name=“sessionID” type=xs:base64Binary” minOccurs=“1”*
> *     maxOccurs=“unbounded”/>*

Why is it base64? I see no advantage.

The format is: Session-id: <hex-local-part>;remote=<hex-remote-part>.
So somehow the local and remote parts need to be captured.

Also, it is getting very confusing having <session-id> and <sessionID>, 
especially when <sessionID> contains the encoding of a Session-ID header 
field.

Unfortunately I see no easy solution to this ambiguity.

	Thanks,
	Paul

> From: Cisco Employee <[email-masked] <mailto:[email-masked]>>
> To: Paul Kyzivat <[email-masked] <mailto:[email-masked]>>,
> Parthasarathi R <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     To: Parthasarathi R <[email-masked]
>     <mailto:[email-masked]>>, Cisco Employee
>     <[email-masked] <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>                 To: Paul Kyzivat; [email-masked] <mailto:[email-masked]>
>                 To: Paul Kyzivat <[email-masked]
>                 <mailto:[email-masked]>>, "[email-masked]
>                 <mailto:[email-masked]>"
>                 <[email-masked] <mailto:[email-masked]>>
>                     To: "[email-masked] <mailto:[email-masked]>"
>                     <[email-masked] <mailto:[email-masked]>>
>                         [email-masked] <mailto:[email-masked]>
>                     [email-masked] <mailto:[email-masked]>
>                 [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 3 Nov 2014 08:13:04 +0000

Inline

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
Date: Saturday, 1 November 2014 8:21 pm
To: "[email-masked]" <[email-masked]>
Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata

>You want to *require* a SessionID????? Why?

My initial thought was that CS would always have atleast one Session-Id.
But I realise we can’t guarantee that. So its right to change it to “zero
or more” instances in the XML. I will change this.

A question here which I had asked the group in my previous mail as well

In case a CS has multiple SIP dialogs, it can potentially have multiple
SessionIds as well. Is it sufficient if we just send them as it is
(multiple sessionID XML elements inside <session> element) to SRS ? OR  Do
we need to send the relation of SessionId to its corresponding SIP dialog
(as the SRC sees) ?

>Why is it base64? I see no advantage.

Yes. It should have been hexBinary. But I think even that won’t fit for
the type defined for SessionID. So perhaps we need to define a new data
type whose values is as defined in the SessionId draft. Regarding the
remote part I see it is optional and may or may not be present. I will
have to see how to represent it in the schema.
>especially when <sessionID> contains the encoding of a Session-ID header

Yes. I don’t know what other name we can give to this XML element. It has
to some thing that says its SessionID and the value of that XML element
has to be value of SessionID header

I will check on how to represent the remote and local in the Schema.

Regards,
Ram

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 7 Nov 2014 08:06:06 +0000

Here is the updated schema after incorporating the changes below. With
this we can allow zero or more instances of SessionId in session element.

   <xs:element name=“sessionID” type=tns:sessionID” minOccurs=“0”

Here sessionID is a simpleElement of base type  xs:string but with some
restrictions as defined below:

<xs:simpleType name="sessionID">
 <xs:restriction base="xs:string">
   <xs:pattern value="([0-9a-f]{32}(*);remote=[0-9a-f]{32})"/>
  </xs:restriction>
    </xs:simpleType>

Or should we simply leave it as xs:string in which case there would not be
any type needed. It would just be
 <xs:element name=“sessionID” type=xs:string” minOccurs=“0”
     maxOccurs=“unbounded”/>
Included in <session> element.

Let me know your thoughts.

Regards,
Ram

-----Original Message-----
From: Cisco Employee <[email-masked]>
Date: Monday, 3 November 2014 1:49 pm
To: Paul Kyzivat <[email-masked]>, "[email-masked]"
<[email-masked]>

>>> 2) An instance of <session> XML element must have atleast 1
>>><sessionID>
>>> element and MAY have  more as well
>>
>>><mailto:[email-masked]>>,
>>>             session-id as INSIPID session-id shall act as CS group ID
>>>as
>>>             well.
>>>             Updating
>>>                 in CS is INSIPID session_id or SRC generated UUID. It
>>>is
>>>                 important for
>>>                 SRS
>>>                             Session-ID is a mature document I believe
>>>it
>>>                             is good to include the
>>>                             same
>>>                     received Session_id to SRS. Note this is
>>>independent
>>>                     of the ids we
>>>
>>>                 have in
>>>
>>>                         SRCs that want to coordinate, and that know
>>>they
>>>                         are in an
>>>
>>>                 environment
>>>
>>>                     Yes that is what I was coming to. We need a field
>>>in
>>>                     metadata
>>>
>>>                 (possibly a
>>>
>>>                     child XML element inside <session> element) that
>>>can
>>>                     carry INSIPID
>>>                         That wouldn't cause two SRCs in the same call
>>>to
>>>                         choose

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Nov 2014 11:59:20 -0500

>   <xs:attribute name="session_id" type="xs:base64Binary"

That seems ok. (Though I am still troubled by the name.)

>     <xs:pattern value="([0-9a-f]{32}(*);remote=[0-9a-f]{32})"/>

I forget if there are cases where the remote part is absent. There used
to be, but I think maybe they got changed to require insertion of zeros.

It seems wasteful to include the "remote=", but maybe it is easier to
just lift the entire thing from the sip message.

> Included in <session> element.

I don't have a strong preference. Lets see how the discussion goes.
If it had no structure, we would still need to say exactly what it
included. (That it doesn't include the "Session-ID: " part.)

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 10 Nov 2014 05:47:21 +0000

Inline

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
Date: Friday, 7 November 2014 10:29 pm
To: Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata

>That seems ok. (Though I am still troubled by the name.)

Yeah. I don’t know what better name we can give. Perhaps SIPSessionID ?

>>     <xs:pattern value="([0-9a-f]{32}(*);remote=[0-9a-f]{32}(0..1))"/>
>>    </xs:restriction>
>>      </xs:simpleType>
>

The sessionID draft abnf says it can be null or have a uuid string.
However the text below in the same section says the sender would have to
insert 32 zeros as remote-uuid. So I think it will be present but will
have either a valid value or zeros.

>just lift the entire thing from the sip message.

Yes. That’s the idea. We have to just copy the entire contents of
SessionID header (excluding the “SessionID:” part) and just send it in
XML. The above definition of schema is to have a restriction to have a
specific pattern,  other wise we can just leave it as xs:string in which
it can take any string. I would assume SRS would really not validate the
value in this field. Rather it would use it for relating /co-relating when
it talks to other devices that support sessionID. If an SRS needs to
validate then there is a value in having a specific pattern otherwise
xs:string is also good enough.

Regards,
Ram

>>>>>          One thing to keep in mind is that a single siprec session
>>>>>may
>>>>>          correspond
>>>>>          to multiple sip dialogs. (E.g. when a conference focus is
>>>>>the
>>>>>          SRC.) So
>>>>>      Good point. Agree that we may have such a scenario where
>>>>>multiple
>>>>>      insipid
>>>>>          Alternately CS groups might be used for that. In *some*
>>>>>cases a
>>>>>          CS group
>>>>>          might correspond to a *half* insipid session-id. But that
>>>>>need
>>>>>          not be
>>>>>              I agree with Paul & you for adding optional XML element
>>>>>to
>>>>>              carry INSIPID
>>>>>              session-id.
>>>>>
>>>>>              We need to clearly explain the interaction of CS group
>>>>>id
>>>>>              with INSIPID
>>>>>                  From: siprec [mailto:[email-masked]] On
>>>>>Behalf
>>>>>                  Of Ram Mohan R
>>>>>                  (rmohanr)
>>>>>                  id is -  when a SRS receives metadata it will not
>>>>>know
>>>>>                  if the received
>>>>>                  id
>>>>>                      Subject: Re: [siprec] Carrying Session-ID in
>>>>>SIPREC
>>>>>                      metadata
>>>>>
>>>>>                              We had discussed this in the past (see
>>>>>this
>>>>>                              archive email -
>>>>>              
>>>>>                              however at that time since INSIPID WG
>>>>>and
>>>>>                              Session-ID document was
>>>>>
>>>>>                  in
>>>>>
>>>>>                              early
>>>>>                              stage we deferred including Session-ID
>>>>>in
>>>>>                              the metadata. Now that
>>>>>                      SRC who is part of that CS happens to read this
>>>>>id,
>>>>>                      then it can pass
>>>>>
>>>>>                  it in
>>>>>
>>>>>                          that uses session-id *could* derive their
>>>>>IDs
>>>>>                          based on the session-
>>>>>
>>>>>                  id.
>>>>>
>>>>>
>>>>>                      Well I don¹t know if we want to say that and
>>>>>create
>>>>>                      some dependancy. I
>>>>>
>>>>>                  am
>>>>>
>>>>>                      open to have that but think it can create
>>>>>confusion
>>>>>                      as we need to
>>>>>
>>>>>                  define
>>>>>
>>>>>                      both the cases (when Session_id present and
>>>>>when it
>>>>>                      is not). Rather I
>>>>>                      would think we should leave the current CS Id
>>>>>scope
>>>>>                      as is.
>>>>>
>>>>>
>>>>>                          We could also allow the session-id to be
>>>>>added
>>>>>                          as an optional element
>>>>>
>>>>>                  in
>>>>>
>>>>>                          the metadata.
>>>>>
>>>>>
>>>>>                      session_id of CS ( if present in CS) as is to
>>>>>SRS.
>>>>>                      An SRS may use it
>>>>>
>>>>>                  for
>>>>>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 10 Nov 2014 18:35:33 +0000

>Yeah. I don’t know what better name we can give. Perhaps SIPSessionID ?

No, because the insipid session ID is not restricted to being used for SIP
only.
That said, being able to correlate the SessionID with the SIP dialog seems
useful. I’ll leave it to others to state if they think it is really
necessary.

Cheers,
Charles

>>>>>> fact that a CS can have multiple SIP dialogs) is there a need to
>>>>>>know
>>>>>> to
>>>>>>              example draft with the usage of these unique-id for
>>>>>>call
>>>>>>              transfer
>>>>>>              scenario
>>>>>>                  to know this, since INSIPID session_id scope is
>>>>>>much
>>>>>>                  larger and the SRS
>>>>>>                              My initial thought is to include it as
>>>>>>a
>>>>>>                              element of CS.
>>>>>>
>>>>>>                      Yes. Agree. What I am saying if a CS has
>>>>>>INSIPID
>>>>>>                      Session_id present
>>>>>>
>>>>>>                  and a
>>>>>>
>>>>>>                          We wouldn't have to standardize that, but
>>>>>>it
>>>>>>                          would only work with
>>>>>>
>>>>>>                  SRCs
>>>>>>
>>>>>>                          that have an agreement.
>>>>>>
>>>>>>                          the same siprec id for the call, but the
>>>>>>SRS
>>>>>>                          could then correlate
>>>>>>
>>>>>>                  them.
>>>>>>
>>>>>>
>>>>>>                          Thanks,
>>>>>>                          Paul
>>>>>>
>>>>>>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 11 Nov 2014 04:24:33 +0000

Hi Charles,

-----Original Message-----
From: "Charles Eckel   (eckelcu)" <[email-masked]>
Date: Tuesday, 11 November 2014 12:05 am
To: Cisco Employee <[email-masked]>, Paul Kyzivat
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata

>No, because the insipid session ID is not restricted to being used for SIP

Ok. I will leave the name as “SessionID” only.

>useful. I’ll leave it to others to state if they think it is really

I had this question in my earlier email but have not seen any feedback in
the WG so far. Since a CS can have multiple SIP dialogs the <session> XML
can potentially carry multiple SessionIDs from SRC to SRS. I would like to
hear (especially from SRS folks) on whether is a value in providing some
information that will co-relate the SIP dialog and its related SessionID.

Regards,
Ram

>>>> Or should we simply leave it as xs:string in which case there would
>>>>not
>>>>be
>>>>> (multiple sessionID XML elements inside <session> element) to SRS ?
>>>>>OR
>>>>> Do
>>>>>> The format is: Session-id:
>>>>>><hex-local-part>;remote=<hex-remote-part>.
>>>>>>>                  To add to below, One issue I see by mapping
>>>>>>>INSIPID
>>>>>>>                  Session_id to CS
>>>>>>>                  xml
>>>>>>>                          IMO we can't depend on the session id
>>>>>>>being
>>>>>>>                          present, so we can't use
>>>>>>>
>>>>>>>                  it
>>>>>>>
>>>>>>>                      the metadata to SRS. IMO the SRC need not
>>>>>>>worry
>>>>>>>                      about how the INSIPID