Subject: [siprec] SRC, SRS feature tags in a REGISTER

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 9 Feb 2012 16:26:34 +0100

Hi All,

What are the views of the group regarding including the "srs" and "src" feature tags in a REGISTER request and what should be stated in the siprec protocol draft?

The current text in http://tools.ietf.org/html/draft-ietf-siprec-protocol-02#section-5.1 & section 5.2 is a bit woolly only for example section 5.1. states "a registrar could discover that a UA is an SRC based on the presence of this feature tag in a registration" and there is similar text in 5.2.

I am thinking that it is not necessarily always going to be useful to provide this information in REGISTER so some text such as "The SRC MAY include the "src" feature tag in a REGISTER request is probably what we want to say.

Any comment?

Regards
Andy

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 9 Feb 2012 15:47:22 -0800

I'm somewhere between SHOULD and MUST for this. If we do not think it is
really useful, then why define it in the first place?

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hutton, Andrew
> Sent: Thursday, February 09, 2012 3:27 PM
> To: [email-masked]
> Subject: [siprec] SRC, SRS feature tags in a REGISTER
> 
> Hi All,
> 
> What are the views of the group regarding including the "srs" and
"src"
> feature tags in a REGISTER request and what should be stated in the
> siprec protocol draft?
> 
> The current text in http://tools.ietf.org/html/draft-ietf-siprec-
> protocol-02#section-5.1 & section 5.2 is a bit woolly only for example
> section 5.1. states "a registrar could discover that a UA is an SRC
> based on the presence of this feature tag in a registration" and there
> is similar text in 5.2.
> 
> I am thinking that it is not necessarily always going to be useful to
> provide this information in REGISTER so some text such as "The SRC MAY
> include the "src" feature tag in a REGISTER request is probably what
we
> want to say.
> 
> Any comment?
> 
> Regards
> Andy
> 
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Feb 2012 23:43:45 -0500

IMO MUST is appropriate here.

Otherwise there will be interop issues. The presence of the SRC tag 
allows the same URI to be used to contact a UA as an SRS and for other 
purposes (e.g. as some other sort of media processor.) And the presence 
of the SRS tag allows the SRC to discover it has connected to an 
inappropriate server.

	Thanks,
	Paul

On 2/9/12 6:47 PM, Charles Eckel (eckelcu) wrote:
>> protocol-02#section-5.1&  section 5.2 is a bit woolly only for example

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 10 Feb 2012 16:02:36 +0100

The primary use of the feature tag's is used to identify the role of the UA within the recording session it seems to me it is not so useful in the REGISTER but don't have a strong opinion. Maybe we should just make it a MUST to reduce the options.

Regards
Andy 

> From: Charles Eckel (eckelcu) [mailto:[email-masked]]
> Sent: 09 February 2012 23:47
> To: Hutton, Andrew; [email-masked]
> Subject: RE: [siprec] SRC, SRS feature tags in a REGISTER
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 10 Feb 2012 16:49:20 +0100

Hi All,

Another related question.

When include in an INVITE the 'src' and 'srs' feature tag's indicate that for this session the UA generating the request acts as either a SRC or a SRS and therefore they are mutually exclusive.

If included in a REGISTER requests then it just indicates a capability and therefore I guess they are not mutually exclusive although it would be an unusual case for a UA to be able to act as both. We probably should also say something about usage in OPTIONS.

I don't have a huge opinion on this just think we need to clarify the protocol draft.

Regards
Andy

> Sent: 10 February 2012 15:03
> To: Charles Eckel (eckelcu); [email-masked]
> Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER
> 
> The primary use of the feature tag's is used to identify the role of
> the UA within the recording session it seems to me it is not so useful
> in the REGISTER but don't have a strong opinion. Maybe we should just
> make it a MUST to reduce the options.
> 
> Regards
> Andy
> 
> 
> 
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 13 Feb 2012 12:34:38 -0800

I agree that we should specify something. 
For REGISTER, I think indicating both src and srs is valid.
For INVITE and OPTIONS, I think indicating src vs. srs is driven by the
request. If the request contains src, I would expect the response to
indicate srs, and vice versa. If the request indicates neither src nor
srs, I think responding with src is generally useful, whereas responding
with srs or both src and srs is a bit odd but perhaps still legal.

Cheers,
Charles

> Sent: Friday, February 10, 2012 7:49 AM
> To: [email-masked]
> When include in an INVITE the 'src' and 'srs' feature tag's indicate
> that for this session the UA generating the request acts as either a
> SRC or a SRS and therefore they are mutually exclusive.
> 
> If included in a REGISTER requests then it just indicates a capability
> and therefore I guess they are not mutually exclusive although it
would
> be an unusual case for a UA to be able to act as both. We probably
> should also say something about usage in OPTIONS.
> 
> > > I'm somewhere between SHOULD and MUST for this. If we do not think
> it
> > > is
> > > > The current text in
http://tools.ietf.org/html/draft-ietf-siprec-
> > > > I am thinking that it is not necessarily always going to be
> useful
> > to
> > > > provide this information in REGISTER so some text such as "The
> SRC
> > > MAY

---

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

Agree

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: Monday, February 13, 2012 10:35 PM
To: Hutton, Andrew; [email-masked]
Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER

I agree that we should specify something. 
For REGISTER, I think indicating both src and srs is valid.
For INVITE and OPTIONS, I think indicating src vs. srs is driven by the request. If the request contains src, I would expect the response to indicate srs, and vice versa. If the request indicates neither src nor srs, I think responding with src is generally useful, whereas responding with srs or both src and srs is a bit odd but perhaps still legal.

Cheers,
Charles

would

---

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

I don't suppose we would disallow those unusual but technically legal
uses?

I don't have a strong position here on whether we should use a MUST or
SHOULD, but using MAY does seem a little too weak if we even mention it
in those sections.

Henry

> Behalf Of Charles Eckel (eckelcu)
> Sent: February-13-12 3:35 PM
> > I don't have a huge opinion on this just think we need to clarify
the
> > protocol draft.
> > > > > feature tags in a REGISTER request and what should be stated
in
> > the
> > > > > section 5.1. states "a registrar could discover that a UA is
an
> > SRC
> > > > > based on the presence of this feature tag in a registration"
> and
> > > > there
> > > > > is similar text in 5.2.
> > > > >
> > > > > include the "src" feature tag in a REGISTER request is
probably
> > > what