Re: Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation

I would tend to disagree that a policy of "Use UDP preferably
and switch to TCP if message is too big" is a good policy. Especially
considering that you'd have to keep the TCP connection alive anyways.

I believe that always using the TCP connection in this case would
make more sense.

But it's definitively legal.

> -----Original Message-----
> From: Lawrence, Scott (BL60:9D30) 
> Sent: Monday, August 31, 2009 09:56
> To: Vavilapalli Srikanth-A19563
> Cc: Audet, Francois (SC100:3055); [email protected]; 
> [email protected]; [email protected]
> Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 
> draft: multipleflowcreation
> 
> On Mon, 2009-08-31 at 12:31 -0400, Scott Lawrence wrote:
> > On Mon, 2009-08-31 at 22:33 +0800, Vavilapalli 
> Srikanth-A19563 wrote:
> > > True, UDP flow may not be required if TCP flow has been setup to 
> > > route incoming traffic towards UA. But Won't it be an additional 
> > > bonus if UA creates a UDP FLOW in addition to TCP FLOW, so that 
> > > network can still reach the UA over the other transport FLOW when 
> > > one FLOW is down (Unless if both FLOWs got created with same host 
> > > and all the FLOWs connected to that host is down)?
> > >  
> > > Also assume a UA has some local policy to prefer UDP 
> transport over 
> > > TCP to transmit the outgoing SIP messages of size less 
> than MTU. In 
> > > such scenarios, UA might want to establish both UDP and TCP FLOWs 
> > > with the same edge proxy and keep alive both the 
> connections and use 
> > > the corresponding FLOW based on DNS lookup preferences and User's 
> > > local policy preferences to transport outgoing messages.
> > 
> > That would not be a very sensible proxy if the phone is 
> behind a NAT 
> > and supports TCP.
> 
> s/proxy/policy/
> 
> 
> 
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip