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

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 2 Feb 2015 14:56:48 +0000

Per the discussions in IETF 91 I am going ahead with the following
approach:

1) Define a new XML element with name “insipid” which would be a
unrestricted string (type is xs:string).

The XML for <session> element will be modified to have insipid as a new
XML element (where we can have zero or more occurrences of insipid in a CS)

<xs:complexType name="session">
  <xs:sequence>
    <xs:element name=“insipid” type=xs:string” minOccurs=“0”
maxOccurs=“unbounded”/>        ――――> newly added
    <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>

Will add following normative text:

"Each Communication Session (CS) MAY have zero or more insipid
   identifiers.  When present, the identifier MUST follow the syntax
   defined in section 5 of [I-D.ietf-insipid-session-id].

“

Let me know if there are any objections.

Regards,
Ram

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

>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
>
>>On 11/9/14, 7:47 PM, "Ram Mohan R (rmohanr)" <[email-masked]> wrote:
>>
>>>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
>>>
>>>>On 11/7/14 3:06 AM, Ram Mohan R (rmohanr) wrote:
>>>>> Here is the updated schema after incorporating the changes below.
>>>>>With
>>>>> this we can allow zero or more instances of SessionId in session
>>>>>element.
>>>>> 
>>>>> 
>>>>> Updated schema with the proposed change:
>>>>>    <xs:complexType name="session">
>>>>>    <xs:sequence>
>>>>>     <xs:element name=“sessionID” type=tns:sessionID” minOccurs=“0”
>>>>>       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>
>>>>
>>>>That seems ok. (Though I am still troubled by the name.)
>>>
>>>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.
>
>Ok. I will leave the name as “SessionID” 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.
>
>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
>
>
>>
>>Cheers,
>>Charles
>>
>>>
>>>
>>>>
>>>>> 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}(0..1))"/>
>>>>>    </xs:restriction>
>>>>>      </xs:simpleType>
>>>>
>>>>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.
>>>
>>>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.
>>>
>>>>
>>>>It seems wasteful to include the "remote=", but maybe it is easier to
>>>>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
>>>
>>>>
>>>>> 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.
>>>>
>>>>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
>>>>
>>>>> 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]>
>>>>> Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata
>>>>> 
>>>>>> 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
>>>>>>
>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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
>>>>>>>
>>>>>>> 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) ?
>>>>>>
>>>>>>>
>>>>>>>> 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”/>*
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>>
>>>>>>> Unfortunately I see no easy solution to this ambiguity.
>>>>>>>
>>>>>>> 	Thanks,
>>>>>>> 	Paul
>>>>>>>
>>>>>>>>      <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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> siprec mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> siprec mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>
>>>>> 
>>>>
>>>
>>>_______________________________________________
>>>siprec mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/siprec
>>
>

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 3 Feb 2015 06:58:41 +0000

Hi Ram - 

I have one objection: we really shouldn't use 'insipid' as the name for the identifier since that has no significance aside from being the name of the WG. You won't find that name referenced in any of the documents defining the end-to-end session identifier. I'd suggest we find an alternate tag that's a bit more descriptive.

Thanks,  

Gonzalo

> On Feb 2, 2015, at 9:56 AM, Ram Mohan R (rmohanr) <[email-masked]> wrote:
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 3 Feb 2015 08:00:04 +0000

Hi Gonzalo,

Thanks for the review.

Sure. Will change the name. I am inclined to go with “sipSessionId” as the
XML element name and will stick to it unless some one else has a better
suggestion.

Regards,
Ram

-----Original Message-----
From: "Gonzalo Salgueiro   (gsalguei)" <[email-masked]>
Date: Tuesday, 3 February 2015 12:28 pm
To: Cisco Employee <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata

>Hi Ram - 
>
>I have one objection: we really shouldn't use 'insipid' as the name for
>the identifier since that has no significance aside from being the name
>of the WG. You won't find that name referenced in any of the documents
>defining the end-to-end session identifier. I'd suggest we find an
>alternate tag that's a bit more descriptive.
>
>Thanks,  
>
>Gonzalo
>
> 
>>>>>>>    <xs:pattern
>>>>>>>value="([0-9a-f]{32}(*);remote=[0-9a-f]{32}(0..1))"/>
>>>>>>>   </xs:restriction>
>>>>>>>     </xs:simpleType>
>>>>>>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 4 Feb 2015 17:02:52 +0000

Here is proposal and text that I plan to add to SIPREC Metadata draft.
Please do suggest any comments/inputs.

Proposed XML Schema for session-ID

1) Define a new XML element with name “sipSessionID” which would be a
unrestricted string (type is xs:string).

2) The session-ID will be a child XML element inside <session> element of
Metadata. The Metadata schema would allow  a CS
   to have zero or more session-ID elements. More than one session-ID is
primarily to accommodate conference use-cases.
   For e.g; 

3) The val of the sipSessionID element MUST follow the ABNF format of
session-id-value as defined in section 5 of
   [I-D.ietf-insipid-session-id].

4) If there are changes in CS, the same will be indicated in the metadata
snapshot from SRC to SRS and this might include
    sipSessionID changes as well. For e.g;
   Assume A and B are two participants in a CS and a SRC (B2BUA) in the CS
reports the session id as
   <sipSessionID>A;remote=B</sipSessionID> a time t1 to SRS
   At a later time if there is transfer in the same CS and B drops and C
joins, then the SRC(B2BUA) reports the session id as
    <sipSessionID>A;remote=C</sipSessionID> at time t2 to SRS

   and so on.

5) It is possible that a SRC reports a session id having only one half
(like <sipSessionID>D;remote=0</sipSessionID>

6)The order in which the SRC reports the sesssion-ID should not matter. If
the SRC(say EP1) is one of the ends of the CS, then it would
   report the session id as EP1;remote=EP2. If the SRC is a B2BUA,
depending on which side of the B2BUA the recording is being done it would
  report the session id as it sees.

Let me know if any has any concerns in including the session-Id and the
behaviour as mentioned above in the metadata draft.

Regards,
Ram

-----Original Message-----
From: Cisco Employee <[email-masked]>
Date: Tuesday, 3 February 2015 1:30 pm
To: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata

>>>>>>>>>>>http://www.ietf.org/mail-archive/web/insipid/current/msg00285.ht
>>>>>>>>>>>m
>>>>>>>>>>>l)