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

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 4 Jul 2014 14:43:01 +0000

We have submitted a draft that describes the behavior B2BUAs should
follow when acting on a media plane that receives STUN messages as part of
ICE processing.

http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-stun-00.txt

Comments and suggestions on how to make the draft better are welcome.

Regards,
Authors.

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Friday, 4 July 2014 8:08 pm
To: Ram Mohan Ravindranath <[email-masked]>, "Tirumaleswar Reddy
(tireddy)" <[email-masked]>, "Gonzalo Salgueiro (gsalguei)"
<[email-masked]>, "Gonzalo Salgueiro (gsalguei)" <[email-masked]>,
"Tirumaleswar Reddy (tireddy)" <[email-masked]>, Ram Mohan Ravindranath
<[email-masked]>
Subject: New Version Notification for draft-ram-straw-b2bua-stun-00.txt

>
>A new version of I-D, draft-ram-straw-b2bua-stun-00.txt
>has been successfully submitted by Ram Mohan Ravindranath and posted to
>the
>IETF repository.
>
>Name:		draft-ram-straw-b2bua-stun
>Revision:	00
>Title:		Session Traversal Utilities for NAT (STUN) Message Handling for
>Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
>Document date:	2014-07-04
>Group:		Individual Submission
>Pages:		14
>URL:            
>http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-stun-00.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-ram-straw-b2bua-stun/
>Htmlized:       http://tools.ietf.org/html/draft-ram-straw-b2bua-stun-00
>
>
>Abstract:
>   Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
>   are often designed to be on the media path, rather than just
>   intercepting signaling.  This means that B2BUAs often act on the
>   media path leading to separate media legs that the B2BUA correlates
>   and bridges together.  When acting on the media path, B2BUAs are
>   likely to receive Session Traversal Utilities for NAT (STUN) packets
>   as part of Interactive Connectivity Establishment (ICE) processing.
>   It is critical that B2BUAs handle these STUN messages properly.
>
>   This document defines behavior for a B2BUA performing ICE processing.
>
>                  
>        
>
>
>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: Christer Holmberg <[email-masked]>
Date: Fri, 4 Jul 2014 15:56:59 +0000

(As co-chair)

Hi,

Thanks for submitting the draft!

Currently this is the only input draft we have for the following delivery:

A document defining the requirements for B2BUAs to support STUN message transactions end-to-end submitted to the IESG as PS

We ask people to take a look at it, to see whether there are some issues that need to be dealt with before we ask for WG adoption of the draft.

Also, if someone intends to submit an alternative draft for the delivery, let the community know.

Thanks!

Regards,

Christer

________________________________________
From: straw [[email-masked]] on behalf of Ram Mohan R (rmohanr) [[email-masked]]
Sent: Friday, 04 July 2014 5:43 PM
To: [email-masked]
Subject: [straw] FW: New Version Notification for       draft-ram-straw-b2bua-stun-00.txt

Regards,
Authors.

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Friday, 4 July 2014 8:08 pm
To: Ram Mohan Ravindranath <[email-masked]>, "Tirumaleswar Reddy

>until the htmlized version and diff are available at tools.ietf.org.

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

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 18 Jul 2014 06:55:15 +0530

Hi Ram,

The draft approach looks good. The following aspect has to be considered

1) ICE-TCP handling in STUN traversal
2) In case B2BUA is ICE-lite, the impact of STUN traversal w.r.t ICE
termination and ICE passthrough mode in B2BUA.

Thanks
Partha

> From: straw [mailto:[email-masked]] On Behalf Of Ram Mohan R
> (rmohanr)
> Sent: Friday, July 04, 2014 8:13 PM
> To: [email-masked]

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 22 Jul 2014 02:55:15 +0000

Please see inline

-----Original Message-----
From: Parthasarathi R <[email-masked]>
Date: Friday, 18 July 2014 6:55 am
To: Ram Mohan Ravindranath <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: RE: [straw] FW: New Version Notification
for	draft-ram-straw-b2bua-stun-00.txt

>1) ICE-TCP handling in STUN traversal

Will add some text for this in the next revision.

>termination and ICE passthrough mode in B2BUA.

Is there any thing that you would like to see explicitly added for ICE
lite ? All the procedures of ICE termination/ICE passthrough are equally
applicable for Ice lite mode as well.

Regards,
Ram

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 22 Jul 2014 23:40:37 +0530

Hi Ram,

In case of ICE termination of B2BUA with ICE-lite, ICE connectivity check
starts from both UA side and the text has to be added to mention any initial
media clipping will happen because of B2BUA with ICE-lite and the
recommendation to avoid this situation in B2BUA implementation. 

In case of ICE pass through of B2BUA with ICE-lite, whether it is allowed to
pass ICE connectivity check end-to-end through B2BUA and any side effects
because of the same?

Thanks
Partha

> From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
> Sent: Tuesday, July 22, 2014 8:25 AM
> To: Parthasarathi R; [email-masked]
> Subject: Re: [straw] FW: New Version Notification for draft-ram-straw-
> b2bua-stun-00.txt
> 
> Please see inline
> 
> >> follow when acting on a media plane that receives STUN messages as
> part
> >> of
> >> ICE processing.
> >>
> >> >has been successfully submitted by Ram Mohan Ravindranath and
> posted
> >> to
> >> >the
> >> >IETF repository.
> >> >
> >> >Htmlized:       http://tools.ietf.org/html/draft-ram-straw-b2bua-
> stun-
> >> 00
> >> >
> >> >
> >> >Abstract:

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 24 Jul 2014 14:34:09 +0000

Please see inline

-----Original Message-----
From: Parthasarathi R <[email-masked]>
Date: Tuesday, 22 July 2014 11:40 pm
To: Ram Mohan Ravindranath <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: RE: [straw] FW: New Version Notification for
draft-ram-straw-b2bua-stun-00.txt

>recommendation to avoid this situation in B2BUA implementation.

Irrespective of whether ICE-lite or full ICE, media clip is possible when
ICE is terminated at B2BUA as there are two independent ICE contexts on
each side of B2BUA.
There is already some text in section 3.2.

"Since there are two independent ICE contexts on either side of the
   B2BUA it is possible that ICE checks will conclude on one side before
   concluding on the other side.  This could result in an ongoing media
   session for one end, while the other is still being set up.  Any such
   media received by the B2BUA would continue to be sent to the other
   side on the default candidate address (that was sent in c= line).²

Let me know if this is not sufficient.

>pass ICE connectivity check end-to-end through B2BUA and any side effects

What side-effects do you for-see ? If the B2BUA is in ICE passthrough it
will pass the ICE messages end to end by changing the UDP/IP header.

Regards,
Ram

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 25 Jul 2014 03:18:57 +0530

Hi Ram,

Please read inline.

Thanks
Partha

> Sent: Thursday, July 24, 2014 8:04 PM
<Partha>  In case of Full ICE, it is possible for media clip whereas in
ICE-lite, the media clipping occurs in all the scenario. It is better to
highlight this difference as it is the good information for the
implementation. </Partha>  

> 
>
> >
> >
> >In case of ICE pass through of B2BUA with ICE-lite, whether it is
> allowed
> >to
<Partha> The callflow about this behavior will help as ICE-Lite is not
initiating any response for connectivity check but the connectivity check
will be completed. It is not trivial to explain to any implementers as the
connectivity check is actually expected between UA & B2BUA whereas here, it
occurs end-to-end but looks hop-by-hop in terms of ICE. </Partha> 

> >> >> Subject: [straw] FW: New Version Notification for draft-ram-
> straw-
> >> >> b2bua-stun-00.txt
> >> >>
> >> >> >Title:		Session Traversal Utilities for NAT (STUN)
> Message
> >> >> Handling for

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 25 Jul 2014 02:58:53 +0000

See inline

-----Original Message-----
From: Parthasarathi R <[email-masked]>
Date: Friday, 25 July 2014 3:18 am
To: Ram Mohan Ravindranath <[email-masked]>, "[email-masked]"
<[email-masked]>

>implementation. </Partha>

Media clip is possible for full ICE as well. When B2BUA is terminating ICE
on each side, there will be two ICE sessions. The ICE conclusion on each
side can happen at different times. This is irrespective of whether B2BUA
is in full ICE or Ice-lite. Am I missing some thing here ?

>initiating any response for connectivity check

 The ICE lite endpoint will still respond to connectivity checks but does
not generate connectivity requests.

Regards,
Ram

>but the connectivity check