[Insipid] FW: [siprec] Carrying Session-ID in SIPREC metadata

["Ram Mohan R (rmohanr)" <[e-mail]>]

We are adding session-ID to SIPREC Metadata
draft(draft-ietf-siprec-metadata)  and below is the proposed approach.
If you have any comments, please send to [e-mail]

Thanks,
Ram

-----Original Message-----
From: Cisco Employee <[e-mail]>
Date: Wednesday, 4 February 2015 10:32 pm
To: "Gonzalo Salgueiro (gsalguei)" <[e-mail]>, "[e-mail]"
<[e-mail]>
Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata

>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 <[e-mail]>
>Date: Tuesday, 3 February 2015 1:30 pm
>To: "Gonzalo Salgueiro (gsalguei)" <[e-mail]>
>Cc: "[e-mail]" <[e-mail]>
>Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata
>
>>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)" <[e-mail]>
>>Date: Tuesday, 3 February 2015 12:28 pm
>>To: Cisco Employee <[e-mail]>
>>Cc: "[e-mail]" <[e-mail]>
>>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
>>>
>>> 
>>>> On Feb 2, 2015, at 9:56 AM, Ram Mohan R (rmohanr) <[e-mail]>
>>>>wrote:
>>>> 
>>>> 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 <[e-mail]>
>>>> Date: Tuesday, 11 November 2014 10:01 am
>>>> To: "[e-mail]" <[e-mail]>, "Charles Eckel (eckelcu)"
>>>> <[e-mail]>
>>>> Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata
>>>> 
>>>>> Hi Charles,
>>>>> 
>>>>> -----Original Message-----
>>>>> From: "Charles Eckel   (eckelcu)" <[e-mail]>
>>>>> Date: Tuesday, 11 November 2014 12:05 am
>>>>> To: Cisco Employee <[e-mail]>, Paul Kyzivat
>>>>> <[e-mail]>, "[e-mail]" <[e-mail]>
>>>>> Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata
>>>>> 
>>>>>> On 11/9/14, 7:47 PM, "Ram Mohan R (rmohanr)" <[e-mail]>
>>>>>>wrote:
>>>>>> 
>>>>>>> Inline
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Paul Kyzivat <[e-mail]>
>>>>>>> Date: Friday, 7 November 2014 10:29 pm
>>>>>>> To: Cisco Employee <[e-mail]>, "[e-mail]"
>>>>>>> <[e-mail]>
>>>>>>> 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 <[e-mail]>
>>>>>>>>> Date: Monday, 3 November 2014 1:49 pm
>>>>>>>>> To: Paul Kyzivat <[e-mail]>, "[e-mail]"
>>>>>>>>> <[e-mail]>
>>>>>>>>> Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata
>>>>>>>>> 
>>>>>>>>>> Inline
>>>>>>>>>> 
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Paul Kyzivat <[e-mail]>
>>>>>>>>>> Date: Saturday, 1 November 2014 8:21 pm
>>>>>>>>>> To: "[e-mail]" <[e-mail]>
>>>>>>>>>> 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 <[e-mail]
>>>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>>>> Date: Friday, 10 October 2014 7:53 am
>>>>>>>>>>>> To: Paul Kyzivat <[e-mail]
>>>>>>>>>>>> <mailto:[e-mail]>>,
>>>>>>>>>>>> Parthasarathi R <[e-mail]
>>>>>>>>>>>> <mailto:[e-mail]>>, "[e-mail]
>>>>>>>>>>>> <mailto:[e-mail]>" <[e-mail]
>>>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>>>> Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata
>>>>>>>>>>>> 
>>>>>>>>>>>>     Hi Paul,
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>     -----Original Message-----
>>>>>>>>>>>>     From: Paul Kyzivat <[e-mail]
>>>>>>>>>>>>     <mailto:[e-mail]>>
>>>>>>>>>>>>     Date: Friday, 10 October 2014 7:02 am
>>>>>>>>>>>>     To: Parthasarathi R <[e-mail]
>>>>>>>>>>>>     <mailto:[e-mail]>>, Cisco Employee
>>>>>>>>>>>>     <[e-mail] <mailto:[e-mail]>>,
>>>>>>>>>>>> "[e-mail]
>>>>>>>>>>>>     <mailto:[e-mail]>" <[e-mail]
>>>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>>>>     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:[e-mail]]
>>>>>>>>>>>>On
>>>>>>>>>>>> Behalf
>>>>>>>>>>>>                 Of Ram Mohan R
>>>>>>>>>>>>                 (rmohanr)
>>>>>>>>>>>>                 Sent: Wednesday, October 08, 2014 10:28 PM
>>>>>>>>>>>>                 To: Paul Kyzivat; [e-mail]
>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>                 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 <[e-mail]
>>>>>>>>>>>>                 <mailto:[e-mail]>>
>>>>>>>>>>>>                 Date: Wednesday, 8 October 2014 10:13 pm
>>>>>>>>>>>>                 To: Paul Kyzivat <[e-mail]
>>>>>>>>>>>>                 <mailto:[e-mail]>>,
>>>>>>>>>>>>"[e-mail]
>>>>>>>>>>>>                 <mailto:[e-mail]>"
>>>>>>>>>>>>                 <[e-mail] <mailto:[e-mail]>>
>>>>>>>>>>>>                 Subject: Re: [siprec] Carrying Session-ID in
>>>>>>>>>>>> SIPREC
>>>>>>>>>>>> metadata
>>>>>>>>>>>> 
>>>>>>>>>>>>                     Hi Paul,
>>>>>>>>>>>> 
>>>>>>>>>>>>                     Please see inline
>>>>>>>>>>>> 
>>>>>>>>>>>>                     -----Original Message-----
>>>>>>>>>>>>                     From: Paul Kyzivat <[e-mail]
>>>>>>>>>>>>                     <mailto:[e-mail]>>
>>>>>>>>>>>>                     Date: Wednesday, 8 October 2014 9:57 pm
>>>>>>>>>>>>                     To: "[e-mail]
>>>>>>>>>>>> <mailto:[e-mail]>"
>>>>>>>>>>>>                     <[e-mail] <mailto:[e-mail]>>
>>>>>>>>>>>>                     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.h
>>>>>>>>>>>>t
>>>>>>>>>>>>m
>>>>>>>>>>>>l)
>>>>>>>>>>>>                             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
>>>>>>>>>>>>                         [e-mail]
>>>>>>>>>>>><mailto:[e-mail]>
>>>>>>>>>>>> 
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>                     siprec mailing list
>>>>>>>>>>>>                     [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>       
>>>>>>>>>>>>https://www.ietf.org/mailman/listinfo/siprec
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>       
>>>>>>>>>>>>_______________________________________________
>>>>>>>>>>>>                 siprec mailing list
>>>>>>>>>>>>                 [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>                 https://www.ietf.org/mailman/listinfo/siprec
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> siprec mailing list
>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> siprec mailing list
>>>>>>>>>>> [e-mail]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> siprec mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> siprec mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>
>>
>>_______________________________________________
>>siprec mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/siprec
>