Subject: [Sipping] help

From: "Mike Robinson" <[email-masked]>
Date: Thu, 22 Mar 2007 08:52:26 -0700

help 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 22, 2007 3:29 AM
To: [email-masked]
Subject: Sipping Digest, Vol 35, Issue 79

Send Sipping mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/sipping
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Sipping digest..."

Today's Topics:

   1. Re: SIP IPv6 Transition: ICE or ANAT (Flemming Andreasen)
   2. RE: SIP IPv6 Transition: ICE or ANAT (Francois Audet)
   3. Status of IPv6 implementations in the SIP world (Iliff, Tina)
   4. RE: [MMUSIC] Re: [Sipping] SIP IPv6 Transition: ICE or ANAT
      (Hadriel Kaplan)
   5. RE: SIP IPv6 Transition: ICE or ANAT (Kai Vehmanen)
   6. Re: [MMUSIC] Re: [Sipping] SIP IPv6 Transition: ICE or ANAT
      (Colin Perkins)
   7. Re: [MMUSIC] RE: [Sipping] SIP IPv6 Transition: ICE or ANAT
      (Colin Perkins)

----------------------------------------------------------------------

Message: 1
Date: Thu, 22 Mar 2007 06:18:35 -0400
From: Flemming Andreasen <[email-masked]>
Subject: Re: [Sipping] SIP IPv6 Transition: ICE or ANAT
To: Francois Audet <[email-masked]>
Cc: Karim El Malki <[email-masked]>, "Mahendran, AC"
	<[email-masked]>,	Gonzalo Camarillo
	<[email-masked]>,	Brian Stucker
<[email-masked]>,
	"Vijay K. Gurbani" <[email-masked]>,	Mary Barnes
	<[email-masked]>, sipping <[email-masked]>,	mmusic
	<[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Francois Audet wrote:
> If we use that logic then we would deprecate using candidates in ICE, 
> no?
>   
Not at all - they are doing two different things albeit with some
overlap. ICE candidate attributes indicate a possible IP-address to use
(as well as whether you use UDP or TCP) - this part overlaps with
capability negotiation. They also indicate certain properties of those
addresses as well as a desire/request to run a connectivity check
algorithm using STUN and based on the outcome of that check, then
deciding whether to use it or not - this part is clearly above and
beyond capability negotiation. In a perfect world, we'd eliminate that
overlap, but I'm not arguing for that. Also note, that you can in fact
include candidate attributes as capabilities and use them as part of the
capability negotiation framework if you want to - in order for that to
work, you'll of course have to ensure that the other supports both
capability negotiation and ICE. In any case, we seem to be departing
from the original issue at hand here.

-- Flemming

------------------------------

Message: 2
Date: Thu, 22 Mar 2007 05:25:58 -0500
From: "Francois Audet" <[email-masked]>
Subject: RE: [Sipping] SIP IPv6 Transition: ICE or ANAT
To: "Kai Vehmanen" <[email-masked]>,	"Brian Stucker"
	<[email-masked]>,	"Mahendran, AC" <[email-masked]>,
	"Gonzalo Camarillo" <[email-masked]>,
"sipping"
	<[email-masked]>
Cc: "Vijay K. Gurbani" <[email-masked]>, Mary Barnes
	<[email-masked]>,	Karim El Malki
<[email-masked]>
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

Yes, perhaps that could be a compromise.

Anybody can think of reasons why it wouldn't work?

> -----Original Message-----
> From: Kai Vehmanen [mailto:[email-masked]]
> Sent: Thursday, March 22, 2007 02:50
> To: Stucker, Brian (RICH1:AR00); Mahendran, AC; Gonzalo Camarillo; 
> sipping
> Cc: Vijay K. Gurbani; Barnes, Mary (RICH2:AR00); Karim El Malki
> Subject: RE: [Sipping] SIP IPv6 Transition: ICE or ANAT
> 
> Hello,
> 
> On 22 March 2007,  Brian Stucker wrote:
> >A possible (?) alternative might be to have an option in ICE
> where the
> >candidate addresses are used, but no connectivity checks are
> performed
> >by either end. Essentially this would
> [...]
> >It'd be a step towards ICE without disrupting what is
> available through
> >ANAT alone. I guess it'd be a diet ICE-lite.
> 
> I'd say just do ICE-lite then. It doesn't have the architectural 
> implications of a full ICE implementation, and is _really_ quick to 
> implement (have been following one -13/lite effort). Specifically,
> 
>  - very little extra state
>  - no need to modify interfaces between the signaling and media stack
> 
> I encourage everyone to think for a moment about the level of effort 
> needed to add at least ice-lite support. If there's something in the 
> spec that still causes (architectural) issues to existing SIP 
> implementations, this would be a good time to get that feedback.
> The biggest complaint I've got from implementors is the change to the 
> signaling<->media-stack interface (which is painful but hard to 
> avoid), but ice-lite "fixes" this.
> 
> --
> [email-masked] (Kai Vehmanen)
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments of core SIP
> 

------------------------------

Message: 3
Date: Wed, 21 Mar 2007 18:35:32 +0000
From: "Iliff, Tina" <[email-masked]>
Subject: [Sipping] Status of IPv6 implementations in the SIP world
To: [email-masked]
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="us-ascii"

I would like to get a feel for the status of IPv6 and/or dual-stack
transitions/implementations in the SIP world.  Are there any examples
and interoperability results?  Also, any known issues being worked?

Thanks,

Tina Iliff

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www1.ietf.org/pipermail/sipping/attachments/20070321/8daecb3f/att
achment.html

------------------------------

Message: 4
Date: Wed, 21 Mar 2007 15:47:59 -0400
From: "Hadriel Kaplan" <[email-masked]>
Subject: RE: [MMUSIC] Re: [Sipping] SIP IPv6 Transition: ICE or ANAT
To: "'Jonathan Rosenberg'" <[email-masked]>,	"'Brian Stucker'"
	<[email-masked]>
Cc: [email-masked], [email-masked],	'Gonzalo Camarillo'
	<[email-masked]>,	"'Vijay K. Gurbani'"
	<[email-masked]>,	'Aki Niemi' <[email-masked]>,
'sipping'
	<[email-masked]>,	'Mary Barnes' <[email-masked]>,
'Karim El
	Malki' <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

Hi Jonathan,
I know there's a humm coming up on this - can you email out what an SDP
offer would look like using ICE, offering v4+v6 candidates, instead of
ANAT?
I looked through the draft and I don't see one, and the wording in
section 13's not helping.  
I am curious how the resultant SDP would look reaching an endpoint not
supporting ICE.
Thanks!

-hadriel

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2007 2:03 PM
> To: Brian Stucker
> Cc: Karim El Malki; [email-masked]; Gonzalo Camarillo; Vijay K.
> Gurbani; Aki Niemi; [email-masked]; sipping; Mary Barnes
> Subject: [MMUSIC] Re: [Sipping] SIP IPv6 Transition: ICE or ANAT
> 
> inline.
> 
> Brian Stucker wrote:
> 
> > Aki,
> >
> > Definitely agree with you. People should be encouraged to look at 
> > everything that goes with having multiple paths over which to 
> > communicate. ANAT isn't designed to solve all of these issues.
> >
> > However, there are networks being specified that do have a policy of

> > preferring IPv6 over IPv4 because they have IPv4 only as a fall-back

> > position for IP version interworking. In this case, only one address

> > space is supported by one of the endpoints, so there's really not a 
> > choice even though the SDP offer makes it appear that there is one. 
> > This would be a scenario in which ANAT is acceptable for the 
> > IPv6/IPv4 interworking.
> 
> 
> Your point, I think, is that there exist cases where the v6 network 
> will always be connected, and will always be better than v4, and will 
> not have firewalls and nats. And that, I'll have lots of calls from 
> users in those networks to users in the same network. Consequently, in

> this constrained environment, a simpler solution would work.
> 
> Sure.
> 
> Aki and I are pointing out that this is just one use case, and that 
> the reality is that networks will often be heterogeneous with multiple

> networks involved in a call. Its better to have one solution that 
> solves all cases than two solutions, one for a very simple case, and 
> another that overlaps with the first which then needs to be added 
> later on when your assumptions prove wrong.
> 
> At a higher level, the real issue in front of us is this. ICE is 
> focused on nat traversal, true, but it makes this fundamental design 
> decision that *the choice of transport addresses must always be done 
> dynamically*. That design choice, and I believe it to be a good one. 
> The design decision I am advocating is to apply this same kernel of 
> truth - that transport address selection is always done better 
> dynamically - to multihoming even when there is no NAT. This would 
> include v4/v6, but also interesting cases like a laptop with VPN and 
> wireless and a wired interface all up and running. Why IP address 
> should I use for a particular call, even when there is no NAT? ANAT 
> *cannot* be used there, since ANAT is about the multihoming selection 
> problem just for the v4/v6 case. ICE covers them all.
> 
> 
> Thanks,
> -Jonathan R.
> 
> 
> 
> --
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ
07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

------------------------------

Message: 5
Date: Thu, 22 Mar 2007 05:23:01 +0200
From: "Kai Vehmanen" <[email-masked]>
Subject: RE: [Sipping] SIP IPv6 Transition: ICE or ANAT
To: "'ext Karim El Malki'" <[email-masked]>,	"Jonathan Rosenberg"
	<[email-masked]>
Cc: [email-masked], [email-masked],	Gonzalo Camarillo
	<[email-masked]>,	Brian Stucker
<[email-masked]>,
	"Vijay K. Gurbani" <[email-masked]>,	"Niemi Aki
	\(Nokia-TP-MSW/Helsinki\)" <[email-masked]>,	sipping
	<[email-masked]>, Mary Barnes <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

Hello all,

On 21 March 2007,  Karim El Malki wrote:
>Reading this thread I'm starting to realise that using ICE could 
>actually make the transition from IPv6 to IPv4 harder and less 
>attractive. If you are still forced to run STUN when you have global 
>ipv6 addresses (i.e. where you don't need it) then this makes 
>transitioning your SIP service less attractive right? I think this is a

>very important issue that needs to be

isn't it just the opposite (assuming you meant v4-to-v6 above)?

Let's take the SIP client developer point of view. If you use ANAT by
default, you are betting on IPv6 to always work (for e.g. media
sessions) if an address is available. Now it's easy to see that this
will not _always_ hold, and especially at the beginning of transition
(as people have less experience in deploying and operating IPv6 than
IPv4 -- there will be temporary glitches, configuration errors, and also
more permanent issues familiar from IPv4 networks like firewalls
blocking all UDP except DNS, etc, etc).

Now how likely the above scenarios are, I don't know, but I've seen
these happen many times, and have heard similar stories from others. Now
as a SIP client developer, you want to be on the safe side and maybe
leave ANAT disabled in the default configuration (a reasonable
compromise). And this means that the client won't take advantage of IPv6
even if it is there and works, unless it is specifically configured to
do so.

With ICE, the client developer can safely enable IPv6 support by
default, without risking bad user experience and hard to debug problems
(for example firewall blocking RTP on IPv6 network, but not on IPv4). If
you can get rid of these corner cases on IPv4 networks (with ICE),
surely you don't want them back when moving to IPv6? And if you can't,
why would you then use IPv6?

So basicly both sides win -- developer can enable IPv6 support
immediately and as a default client setting, while operators can
incrementally enable IPv6 in their networks and have clients utilizing
IPv6 without any changes to client configuration.

It's also good to note that the problem looks very different from a
client developer (who needs to work with all kinds of access networks
and SIP services), and a "system developer" (who knows what assumptions
on access network and the services can be made).

I'm making these comments with my independent SIP client developer hat
on. I don't have a strong opinion on what the sipping transition
documents should say about ANAT. If your access network is configured
correctly, I see no problem using ANAT, but I also don't see (m)any
benefits to using ANAT if you do have ICE implemented, and I can't see
myself relying on ANAT if I don't have detailed information about the
access network. So I really only care about not having any MUSTs in the
documents that would prevent me from using ICE-no-ANAT-with-IPv4/6 in my
client.

Oh well, but to the original question: no, ICE does not make transition
to IPv6 any less attractive, on the contrary, it makes it easier.

--
[email-masked] (Kai Vehmanen)

------------------------------

Message: 6
Date: Thu, 22 Mar 2007 08:36:08 +0100
From: Colin Perkins <[email-masked]>
Subject: Re: [MMUSIC] Re: [Sipping] SIP IPv6 Transition: ICE or ANAT
To: Jonathan Rosenberg <[email-masked]>
Cc: Karim El Malki <[email-masked]>, [email-masked],	Gonzalo
	Camarillo <[email-masked]>,	Brian Stucker
	<[email-masked]>, "Vijay K. Gurbani" <[email-masked]>,
Aki Niemi
	<[email-masked]>, sipping <[email-masked]>,	Mary
Barnes
	<[email-masked]>, [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On 21 Mar 2007, at 19:02, Jonathan Rosenberg wrote:
...
> Its better to have one solution that solves all cases than two  
> solutions, one for a very simple case, and another that overlaps  
> with the first which then needs to be added later on when your  
> assumptions prove wrong.

...which, of course, is also the argument for capability negotiation,  
compared to best effort SRTP.

Colin

------------------------------

Message: 7
Date: Thu, 22 Mar 2007 08:40:13 +0100
From: Colin Perkins <[email-masked]>
Subject: Re: [MMUSIC] RE: [Sipping] SIP IPv6 Transition: ICE or ANAT
To: Brian Stucker <[email-masked]>
Cc: Karim El Malki <[email-masked]>, [email-masked],	Gonzalo
	Camarillo <[email-masked]>,	"Vijay K.
Gurbani"
	<[email-masked]>,	Aki Niemi <[email-masked]>, sipping
	<[email-masked]>,	Mary Barnes <[email-masked]>,
	[email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On 21 Mar 2007, at 21:02, Brian Stucker wrote:
...
> I made a proposal that instead of flatly doing away with ANAT, that a
> document be drawn up that clearly shows when you can/should use  
> what. As
> people move from one environment to the next, or while defining a
> particular environment, they can clearly see what they're getting for
> their dollar. I think it's a pretty reasonable suggestion to at least
> write it all down so those out there who aren't as intricately  
> involved
> with the various WG discussions can understand what the issues are. I
> think ICE will come out looking very favorable in such a document,
> without having to force a decision on the community.

Any proposal to deprecate ANAT -- whether part of ICE, or a separate  
document -- would, I think, have to include such an explanation.

-- 
Colin Perkins
http://csperkins.org/

------------------------------

Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

End of Sipping Digest, Vol 35, Issue 79
***************************************

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP