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

["Ram Mohan R (rmohanr)" <[e-mail]>]

See inline

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

>Hi Ram,
>
>Please read inline.
>
>Thanks
>Partha
>
>> -----Original Message-----
>> From: Ram Mohan R (rmohanr) [mailto:[e-mail]]
>> Sent: Thursday, July 24, 2014 8:04 PM
>> To: Parthasarathi R; [e-mail]
>> Subject: Re: [straw] FW: New Version Notification for draft-ram-straw-
>> b2bua-stun-00.txt
>> 
>> Please see inline
>> 
>> -----Original Message-----
>> From: Parthasarathi R <[e-mail]>
>> Date: Tuesday, 22 July 2014 11:40 pm
>> To: Ram Mohan Ravindranath <[e-mail]>, "[e-mail]"
>> <[e-mail]>
>> Subject: RE: [straw] FW: New Version Notification for
>> draft-ram-straw-b2bua-stun-00.txt
>> 
>> >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.
>> 
>> 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.
><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>

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 ?

>
>> 
>>
>> >
>> >
>> >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?
>> 
>> 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.
>> 
><Partha> The callflow about this behavior will help as ICE-Lite is not
>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
>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>


> 
>
>> Regards,
>> Ram
>> 
>> >
>> >Thanks
>> >Partha
>> >
>> >> -----Original Message-----
>> >> From: Ram Mohan R (rmohanr) [mailto:[e-mail]]
>> >> Sent: Tuesday, July 22, 2014 8:25 AM
>> >> To: Parthasarathi R; [e-mail]
>> >> Subject: Re: [straw] FW: New Version Notification for draft-ram-
>> straw-
>> >> b2bua-stun-00.txt
>> >>
>> >> Please see inline
>> >>
>> >> -----Original Message-----
>> >> From: Parthasarathi R <[e-mail]>
>> >> Date: Friday, 18 July 2014 6:55 am
>> >> To: Ram Mohan Ravindranath <[e-mail]>, "[e-mail]"
>> >> <[e-mail]>
>> >> Subject: RE: [straw] FW: New Version Notification
>> >> for	draft-ram-straw-b2bua-stun-00.txt
>> >>
>> >> >Hi Ram,
>> >> >
>> >> >The draft approach looks good. The following aspect has to be
>> >> considered
>> >> >
>> >> >1) ICE-TCP handling in STUN traversal
>> >>
>> >> Will add some text for this in the next revision.
>> >>
>> >> >2) In case B2BUA is ICE-lite, the impact of STUN traversal w.r.t
>> ICE
>> >> >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
>> >>
>> >> >
>> >> >Thanks
>> >> >Partha
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: straw [mailto:[e-mail]] On Behalf Of Ram
>> Mohan R
>> >> >> (rmohanr)
>> >> >> Sent: Friday, July 04, 2014 8:13 PM
>> >> >> To: [e-mail]
>> >> >> Subject: [straw] FW: New Version Notification for draft-ram-
>> straw-
>> >> >> b2bua-stun-00.txt
>> >> >>
>> >> >> 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: "[e-mail]" <[e-mail]>
>> >> >> Date: Friday, 4 July 2014 8:08 pm
>> >> >> To: Ram Mohan Ravindranath <[e-mail]>, "Tirumaleswar
>> Reddy
>> >> >> (tireddy)" <[e-mail]>, "Gonzalo Salgueiro (gsalguei)"
>> >> >> <[e-mail]>, "Gonzalo Salgueiro (gsalguei)"
>> >> >> <[e-mail]>,
>> >> >> "Tirumaleswar Reddy (tireddy)" <[e-mail]>, Ram Mohan
>> >> >> Ravindranath
>> >> >> <[e-mail]>
>> >> >> 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
>> >> >> >
>> >> >>
>> >> >> _______________________________________________
>> >> >> straw mailing list
>> >> >> [e-mail]
>> >> >> https://www.ietf.org/mailman/listinfo/straw
>> >> >
>> >
>