Subject: [siprec] Protocol draft - SRS SDP Procedures.

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 10 Feb 2012 18:57:13 +0100

Hi All,

Currently section 6.1.1 of http://tools.ietf.org/html/draft-ietf-siprec-protocol-02#section-6.1.1 describes how the SRC can add and remove media lines during a recording session.

However there is no corresponding section describing how the SRS can do the same. I assume that that the SRS could for example terminate a stream during recording for example it might decide it no longer wants to record the video stream but will continue recording the audio. 

We need to describe the use of offerless INVITE's by the SRS for example when the SRS initiates the recording.

Regards
Andy

---

From: Leon Portman <[email-masked]>
Date: Tue, 14 Feb 2012 18:22:58 +0200

But today, if SRS does not want to record something, or pause recording , it will use media-inactive attribute. Do we want for SRS to be able remove m-lines?

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Friday, February 10, 2012 7:57 PM
To: [email-masked]
Subject: [siprec] Protocol draft - SRS SDP Procedures.

Hi All,

Regards
Andy

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

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 14 Feb 2012 18:56:37 +0100

I assume the SRS can remove m-lines and we should say something about this in the protocol draft.

Regards
Andy

> From: Leon Portman [mailto:[email-masked]]
> Sent: 14 February 2012 16:23
> To: Hutton, Andrew; [email-masked]
> Subject: RE: Protocol draft - SRS SDP Procedures.
> 
> But today, if SRS does not want to record something, or pause recording
> , it will use media-inactive attribute. Do we want for SRS to be able
> remove m-lines?
> 
> Leon
> 
> Currently section 6.1.1 of http://tools.ietf.org/html/draft-ietf-
> siprec-protocol-02#section-6.1.1 describes how the SRC can add and
> remove media lines during a recording session.
> 
> However there is no corresponding section describing how the SRS can do
> the same. I assume that that the SRS could for example terminate a
> stream during recording for example it might decide it no longer wants
> to record the video stream but will continue recording the audio.
> 
> We need to describe the use of offerless INVITE's by the SRS for
> example when the SRS initiates the recording.
> 
> Regards
> Andy
> 
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 14 Feb 2012 10:46:01 -0800

I assume that by remove you mean set port=0, correct?

Charles

> Sent: Tuesday, February 14, 2012 9:57 AM
> To: Leon Portman; [email-masked]
> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Feb 2012 13:59:25 -0500

> I assume the SRS can remove m-lines and we should say something about this in the protocol draft.

s/remove/refuse/
(by setting port to zero in the answer)

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 15 Feb 2012 20:51:25 -0800

You're right, the SRS should be allowed to remove media streams from the
session for streams that the SRS does not want to record. Somehow I had
the impression that the SRS need to BYE the session to do so, however,
an SRS should not be able to add a media stream on its own.

Henry

> Sent: February-14-12 12:57 PM

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 16 Feb 2012 06:02:36 +0000

Henry & All,

This question is coming around multiple times in the different form whether SRS is allowed to send offer or not. In case SRS is allowed to initial the offer, it is possible for SRS to add the stream. IIUC, it was decided not to send offer during metadata request. Whether it is possible to say that SRS MUST NOT initiate offer towards SRC?

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Henry Lum
>Sent: Thursday, February 16, 2012 10:21 AM
>To: Hutton, Andrew; Leon Portman; [email-masked]

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 16 Feb 2012 08:41:39 -0800

I do not see any need for such as a restriction.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ravindran, Parthasarathi
> Sent: Wednesday, February 15, 2012 10:03 PM
> To: Henry Lum; Hutton, Andrew; Leon Portman; [email-masked]
> This question is coming around multiple times in the different form
> whether SRS is allowed to send offer or not. In case SRS is allowed to
> initial the offer, it is possible for SRS to add the stream. IIUC, it
> was decided not to send offer during metadata request. Whether it is
> possible to say that SRS MUST NOT initiate offer towards SRC?
> 
> Thanks
> Partha
> 
> >> I assume the SRS can remove m-lines and we should say something
> about
> >> this in the protocol draft.
> >>
> >> Regards
> >> Andy
> >>
> >> > However there is no corresponding section describing how the SRS
> can
> >> do

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 16 Feb 2012 17:27:00 +0000

Hi Charles,

As a follow up query, whether SRS SHOULD be allowed to add the stream in its offer? As per your earlier statement, SRS should be allowed. Please correct me in case I misunderstand your statement.

Thanks
Partha

>From: Charles Eckel (eckelcu) [mailto:[email-masked]]
>Sent: Thursday, February 16, 2012 10:12 PM
>To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon Portman;
>[email-masked]
>Subject: RE: [siprec] Protocol draft - SRS SDP Procedures.
>
>> Behalf
>> >> Behalf Of Hutton, Andrew
>> >> > Behalf Of Hutton, Andrew

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 16 Feb 2012 09:36:19 -0800

Hi Partha,

While I do not have a specific use case in mind that requires this, I do
not see any benefit gained by explicitly not allowing it. I'd like to
avoid placing unnecessary restrictions. If an SRS tries to add a media
line and an SRC does not want to accept it, if can simply answer with
port=0. That sounds fine to me.

Cheers,
Charles

> From: Ravindran, Parthasarathi [mailto:[email-masked]]
> Sent: Thursday, February 16, 2012 9:27 AM
> To: Charles Eckel (eckelcu); Henry Lum; Hutton, Andrew; Leon Portman;
> [email-masked]
> As a follow up query, whether SRS SHOULD be allowed to add the stream
> in its offer? As per your earlier statement, SRS should be allowed.
> Please correct me in case I misunderstand your statement.
> 
> Thanks
> Partha
> 
> >> >You're right, the SRS should be allowed to remove media streams
> from
> >> the
> >> >session for streams that the SRS does not want to record. Somehow
I
> >> had
> >> >> > , it will use media-inactive attribute. Do we want for SRS to
> be
> >> >able
> >> >> > remove m-lines?
> >> >> >
> >> >> > Leon
> >> >> >
> >> >> > the same. I assume that that the SRS could for example
> terminate
> >a
> >> >> > stream during recording for example it might decide it no
> longer
> >> >> wants

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 16 Feb 2012 17:44:13 +0000

Hi Charles,

I agree with you as I don't see the strong reason to restrict. Let offer/answer exchange between SRC and SRS is same as offer/answer exchange between any two SIP UA. The exception is required for metadata request scenario as it creates cross wire scenario unnecessarily by SRS wherein SRS MUST NOT create offer till SRC sends offer.

Thanks
Partha

>Sent: Thursday, February 16, 2012 11:06 PM

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 16 Feb 2012 09:57:00 -0800

Works for me.

> Sent: Thursday, February 16, 2012 9:44 AM
> I agree with you as I don't see the strong reason to restrict. Let
> offer/answer exchange between SRC and SRS is same as offer/answer
> exchange between any two SIP UA. The exception is required for
metadata
> request scenario as it creates cross wire scenario unnecessarily by
SRS
> wherein SRS MUST NOT create offer till SRC sends offer.
> 
> Thanks
> Partha
> 
> >> >> whether SRS is allowed to send offer or not. In case SRS is
> allowed
> >> to
> >> >> initial the offer, it is possible for SRS to add the stream.
> IIUC,
> >> it
> >> >> was decided not to send offer during metadata request. Whether
it
> >is
> >> >> >> From: [email-masked]
[mailto:[email-masked]]
> >On
> >> >> >> > But today, if SRS does not want to record something, or
> pause
> >> >> >> recording
> >> >> >> > From: [email-masked] [mailto:siprec-
> [email-masked]]
> >> On
> >> >> >> > Behalf Of Hutton, Andrew
> >> >> >> > Currently section 6.1.1 of
http://tools.ietf.org/html/draft-
> >> ietf-
> >> >> >> > siprec-protocol-02#section-6.1.1 describes how the SRC can
> add
> >> >and
> >> >> >> > However there is no corresponding section describing how
the
> >> SRS
> >> >> >> > We need to describe the use of offerless INVITE's by the
SRS
> >> for

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Feb 2012 13:00:43 -0500

The problem with this is that the SRC is the one that knows what media 
it needs to send, and what media characteristics it needs to do so. If 
the SRS sends the offer, then the SRC has to decide if and how it can 
map what it needs to send onto that offer. It may or may not be able to 
do that. It certainly complicates the life of the SRC if it must be 
prepared to do that. It is somewhat easier for it to offer what it 
needs, and then cope with any refusals it gets.

We can still allow this, but the outcomes may be somewhat unpredictable.

	Thanks,
	Paul

On 2/16/12 12:44 PM, Ravindran, Parthasarathi wrote:
>>>>> Henry&  All,

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 16 Feb 2012 21:30:55 +0100

Is there a difference between the initial offer and subsequent offers to update SDP here?

It seems difficult for an SRC to be able to handle an initial offer from the SRS or any offer which adds new media lines especially if we mandate metadata and require the SRC to label each media line as a handle to the associated metadata.

However there is probably a need to allow the SRS to be able to terminate media lines which would require the SRS to create an offer.

Therefore could we say that the SRS can only create offer's to terminate media lines (i.e. port=0).

Regards
Andy

> Behalf Of Paul Kyzivat
> Sent: 16 February 2012 19:01
> To: [email-masked]
> exchange between any two SIP UA. The exception is required for metadata
> request scenario as it creates cross wire scenario unnecessarily by SRS

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Feb 2012 15:41:19 -0500

> Therefore could we say that the SRS can only create offer's to terminate media lines (i.e. port=0).

This can be handled more easily by having the SRS send an offerless 
invite. Then the SRC will have to send an offer, and the SRS can refuse 
(port=0) the m-lines it doesn't want.

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 16 Feb 2012 21:47:56 +0100

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 16 February 2012 21:41
> To: Hutton, Andrew
> Cc: [email-masked]
> > It seems difficult for an SRC to be able to handle an initial offer
> from the SRS or any offer which adds new media lines especially if we
> mandate metadata and require the SRC to label each media line as a
> handle to the associated metadata.
> >
> > However there is probably a need to allow the SRS to be able to
> terminate media lines which would require the SRS to create an offer.
> >

[AndyH] Whether that is easier to implement or not I think we could debate but I could also live with it as at least we would have simple rule that the SRC always creates the offer.

> >>>> While I do not have a specific use case in mind that requires
> this,
> >> I do

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 17 Feb 2012 14:32:31 +0530

I agree with Paul that having SRS send offer may lead to complex
scenarios for SRC.

For e.g
Assume we have a SRS send a INVITE/UPDATE mid call with a new offer and
SRC does not support the codec, it would reject the offer.  In this case
should SRC stops forking the media ? or should it continue to record ?
or Should SRS send another offer with previously negotiated codec ( or
atleast with a codec it knows SRC can record) ?

On the other hand if SRC has the capability to transcode from one codec
to another it may very well accept the new offer from SRS.

We will have document/define the behavior for all these cases if we are
to support SRS generated offer. 

Regards,
Ram

> Sent: Thursday, February 16, 2012 11:31 PM
> To: [email-masked]
metadata
SRS
it
add