Subject: [straw] FW: New Version Notification for draft-ram-straw-b2bua-feature-tag-00.txt

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 6 Jul 2015 16:07:34 +0000

Hi All,

 We have published a new draft that extends the User Agent capabilities
specification(RFC 3840) to allow
   indication of Back-to-Back User Agent (B2BUA) types.
The motivation for this draft came out  of IESG review and subsequent
discussions of [I-D.ietf-straw-b2bua-stun] where it was pointed
that there is no existing mechanisms for B2BUA to indicate its presence
except for special cases like Focus.

Please review and provide your inputs.

Regards,
Authors

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Monday, 6 July 2015 8:08 pm
To: Cisco Employee <[email-masked]>, "Tirumaleswar Reddy (tireddy)"
<[email-masked]>, "Gonzalo Salgueiro (gsalguei)" <[email-masked]>,
"Gonzalo Salgueiro (gsalguei)" <[email-masked]>, "Tirumaleswar Reddy
(tireddy)" <[email-masked]>, Cisco Employee <[email-masked]>
Subject: New Version Notification for
draft-ram-straw-b2bua-feature-tag-00.txt

>
>A new version of I-D, draft-ram-straw-b2bua-feature-tag-00.txt
>has been successfully submitted by Ram Mohan Ravindranath and posted to
>the
>IETF repository.
>
>Name:		draft-ram-straw-b2bua-feature-tag
>Revision:	00
>Title:		A Session Initiation Protocol (SIP) Feature Tag for Back-to-Back
>User Agents (B2BUAs)
>Document date:	2015-07-06
>Group:		Individual Submission
>Pages:		8
>URL:            
>https://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-feature-tag-00.
>txt
>Status:         
>https://datatracker.ietf.org/doc/draft-ram-straw-b2bua-feature-tag/
>Htmlized:       
>https://tools.ietf.org/html/draft-ram-straw-b2bua-feature-tag-00
>
>
>Abstract:
>   The User Agent capabilities specification allows Session Initiation
>   Protocol (SIP) User Agents to convey their capabilities and
>   characteristics to other User Agents and to the registrar for its
>   domain.  This information is conveyed as parameters of the Contact
>   header field.  Amongst those capabilities are the type of User Agent
>   that is available at a SIP Uniform Resource Identifier (URI).  This
>   document extends the User Agent capabilities specification to allow
>   indication of Back-to-Back User Agent (B2BUA) types.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Jul 2015 12:47:38 -0400

Ram,

I am puzzled by this. I can't figure out when/how it would be used, or 
if/how it relates to RFC6809 (proxy-feature).

My problem is fundamentally whether the devices carrying this tag are to 
be viewed as endpoints or intermediaries. For the properties being 
described to be useful, I think one must view the device as an 
intermediary, that is somehow masking/modifying the intrinsic properties 
of the *actual* endpoint. Yet feature tags (callee capabilities) should 
be viewed as describing the target of communication.

RFC6809 provides a way of describing properties of intermediaries on the 
signaling (and potentially also the media) path. Perhaps this new 
property belongs there instead.

Another way to use a B2BUA is for me, as a user, to use a B2BUA as a 
foundation to build a virtual user agent, composed of one or more other 
UAs. That seems to fit your model. But in that case, other UAs 
interacting with it don't need to know that it is a B2BUA. Rather, they 
only need to know what capabilities it presents to the world. The fact 
that it is a B2BUA is simply an implementation detail.

	Thanks,
	Paul

On 7/6/15 12:07 PM, Ram Mohan R (rmohanr) wrote:
> _______________________________________________
> straw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/straw
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 13 Jul 2015 06:25:22 +0000

(As individual)

Hi,

I more or less share the questions raised by Paul.

Also, keep in mind that there might be multiple Contact modifying B2BUAs in the path, which means that any media feature tag(s) inserted by B2BUA #1 may be overwritten by B2BUA #2.

So, one question is: what information do you want to provide? If you want a list of *ALL* B2BUA types in the siganlling path then I think you would need another mechanism, e.g. a feature capability indicator (fci).

Another question is: do you want the information bound to the domain name/IP address of the B2BUA? If so, keep in mind that fcis by default do not indicate which entity the fci is associated with - only that there is *A* entity that that feature.

So, I think it would be good to write down what the requirements are. Perhaps they can be parsed from the text, but it would be good to have them explicitly stated in a separate section.

Thanks!

Regards,

Christer

-----Original Message-----
From: straw [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 6. heinäkuuta 2015 19:48
To: [email-masked]
Subject: Re: [straw] FW: New Version Notification for draft-ram-straw-b2bua-feature-tag-00.txt

Ram,

I am puzzled by this. I can't figure out when/how it would be used, or if/how it relates to RFC6809 (proxy-feature).

My problem is fundamentally whether the devices carrying this tag are to be viewed as endpoints or intermediaries. For the properties being described to be useful, I think one must view the device as an intermediary, that is somehow masking/modifying the intrinsic properties of the *actual* endpoint. Yet feature tags (callee capabilities) should be viewed as describing the target of communication.

RFC6809 provides a way of describing properties of intermediaries on the signaling (and potentially also the media) path. Perhaps this new property belongs there instead.

Another way to use a B2BUA is for me, as a user, to use a B2BUA as a foundation to build a virtual user agent, composed of one or more other UAs. That seems to fit your model. But in that case, other UAs interacting with it don't need to know that it is a B2BUA. Rather, they only need to know what capabilities it presents to the world. The fact that it is a B2BUA is simply an implementation detail.

	Thanks,
	Paul

On 7/6/15 12:07 PM, Ram Mohan R (rmohanr) wrote:
> Hi All,
>
>   We have published a new draft that extends the User Agent 
> capabilities specification(RFC 3840) to allow
> discussions of [I-D.ietf-straw-b2bua-stun] where it was pointed that 
> there is no existing mechanisms for B2BUA to indicate its presence 
> <[email-masked]>, "Gonzalo Salgueiro (gsalguei)" 
> <[email-masked]>, "Gonzalo Salgueiro (gsalguei)" 
> <[email-masked]>, "Tirumaleswar Reddy (tireddy)" 
> <[email-masked]>, Cisco Employee <[email-masked]>
>> has been successfully submitted by Ram Mohan Ravindranath and posted 
>> to the IETF repository.
>>
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>>
>> The IETF Secretariat
>>
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 20 Jul 2015 10:54:17 +0000

HI Christer,

Please see inline

-----Original Message-----
From: straw <[email-masked]> on behalf of Christer Holmberg
<[email-masked]>
Date: Monday, 13 July 2015 8:25 am
To: Paul Kyzivat <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [straw] FW: New Version Notification for
draft-ram-straw-b2bua-feature-tag-00.txt

>Also, keep in mind that there might be multiple Contact modifying B2BUAs
>in the path, which means that any media feature tag(s) inserted by B2BUA
>#1 may be overwritten by B2BUA #2.

Agree.

>
>So, one question is: what information do you want to provide? If you want
>a list of *ALL* B2BUA types in the siganlling path then I think you would
>need another mechanism, e.g. a feature capability indicator (fci).

The idea is for the UA to know the types of B2BUA in the path between
itself and the destination. For e.g each B2BUA in the path would attach a
fci 

>
>Another question is: do you want the information bound to the domain
>name/IP address of the B2BUA? If so, keep in mind that fcis by default do
>not indicate which entity the fci is associated with - only that there is
>*A* entity that that feature.

I think the need for domain / IP may not be needed. All we need to know is
the type of B2BUA in the path.

>
>So, I think it would be good to write down what the requirements are.
>Perhaps they can be parsed from the text, but it would be good to have
>them explicitly stated in a separate section.

Sure. Will revise the draft and add a requirement section.

Ram

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 20 Jul 2015 11:52:42 +0000

Hi Paul,

Sorry for delay. See inline

-----Original Message-----
From: straw <[email-masked]> on behalf of Paul Kyzivat
<[email-masked]>
Date: Monday, 6 July 2015 6:47 pm
To: "[email-masked]" <[email-masked]>
Subject: Re: [straw] FW: New Version Notification for
draft-ram-straw-b2bua-feature-tag-00.txt

>be viewed as endpoints or intermediaries.

These devices are primarily intermediary devices [ B2BUAs of types in RFC
7092].

> For the properties being

Agree. Initially I had looked at RFC 3840 capabilities (some of them like
isFocus which is a special case of middle box terminating sessions) and
thought 3840 would fit in to indicate the B2BUA capabilities. After
reading RFC 6809 I think that is more relevant and each B2BUA in the path
can add a fci header with its type and so when the UA receives the INVITE
it will see the list of fci headers with the top most being the closest to
UA receiving the message.

The goal of this draft is for a UA to know the different types of B2BUA [
with in the scope of RFC 7092 types] between itself and the destination.
What the UA does by looking at the type of B2BUA is not in scope here.

Ram
>><[email-masked]>,

---

From: [email-masked]
Date: Fri, 31 Jul 2015 10:16:43 -0500

Hi Ram

I agree that B2BUA can multiple roles for different scenarios - but it 
could also play multiple roles for a particular scenario - like for a 
particular session, it could play the role of both signaling and media 
relay. Then both need to be indicated. So then the syntax could be

Contact: <sip:[email-masked]>;audio;video;
          methods="INVITE,BYE,OPTIONS,ACK,CANCEL";
          +sip.isSignalingB2BUA, +sip.isMediaAwareRelayB2BUA

This means that the B2BUA can act as both signaling and media relay for 
this scenario and also shows its capabilities to act as both.

Regards
Ranjit

On 2015-07-20 6:52 am, Ram Mohan R (rmohanr) wrote:
>>>> to

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 1 Aug 2015 06:28:43 +0000

Hi Ranjit,

Agree. There can be multiple roles for B2BUA and hence different
capabilities.

Ram

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Friday, 31 July 2015 8:46 pm
To: Cisco Employee <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [straw] FW: New Version Notification for

>>>>>https://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-feature-tag
>>>>>-0
>>>>> 0.
>>>>> txt
>>>>> Status: