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

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 8 Oct 2014 06:45:00 +0000

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 ?

Regards,
Ram

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 8 Oct 2014 06:48:47 +0000

Hi Ram - 

> in the Metadata XML as part of CS.

I also believe it would be a very good thing.  

FYI - Chair status update: we are preparing to WGLC that document.

Cheers,

Gonzalo

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Oct 2014 12:27:29 -0400

> 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.

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. 
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. 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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 8 Oct 2014 16:43:52 +0000

Hi Paul,

Please see inline

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

>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.
>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.

>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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 8 Oct 2014 16:57:49 +0000

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]>
Date: Wednesday, 8 October 2014 10:13 pm
To: Paul Kyzivat <[email-masked]>, "[email-masked]"
<[email-masked]>

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 10 Oct 2014 05:45:40 +0530

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

> 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]
> >>> however at that time since INSIPID WG and Session-ID document was
> in
> >>>early

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Oct 2014 21:32:29 -0400

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.

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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 10 Oct 2014 02:18:07 +0000

Hi Paul,

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

>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