Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt

From: Andrew Molitor <[email-masked]>
Date: Fri, 22 Jun 2001 21:16:02 -0500 (CDT)

On Fri, 22 Jun 2001, Christian Huitema wrote:

> Uh, which RTP media flow are unidirectional? AFAIK, SIP does not have
> any provision for unidirectional flows.

	It turns out that, in practice, your average SIP phone
simply sends UDP packets to the Other Phone at whatever port that
phone said to use. Of course the same thing happens the other way
around at the same time, but this is (in general) two unidirectional
flows, not one bidirectional one.

	It happens that this example is the only example I have of
useful indirectional traffic, but it's near and dear to my heart.

	Rosenberg et al are currently working on support for
truly bidirectional RTP media (that is, where the audio I send
your phone, and the audio you send my phone, make up between
them a bidirectional flow), but it's not here yet. Also, it
turns out that 'many devices' tend to send from the same port
they receive on, so if you get two such devices (in the absence
of middlebox-NATs) it comes out looking like a single bidirectional
flow.

	This behavior is not (yet) guaranteed, and I think the
'two unidirectional flows' will always be permitted in SIP
voice usage.

		Andrew

P.S. There is a hypothesis around my workplace that ALL SIP deployment
problems manifest as a 'one-way-media problem' in which one end can hear
the other, but not vice-versa. This is an expression of the fact that it's
startlingly easy to get your network set up, especially with a NAT
middlebox, so that one of the two unidirectional audio streams flows
and the other one does not.

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

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 22 Jun 2001 18:55:37 -0700

> -----Original Message-----
> From: Andrew Molitor [mailto:[email-masked]]
> Sent: Friday, June 22, 2001 6:29 PM
> To: [email-masked]
> Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt
> 
> 
> > Similarly, the paragraph that states that "The Middlebox must
support
> > the explicit forwarding of application control session information"
> > should be removed, as well as the whole of section 7.
> 
> 	I seem to recall that:
> 
> 	- OOP as a concept was voted down, or at any rate demoted to
> 	  a passing mention in the framework
> 	- a couple of people (my included) suggested that it should
> 	  be resurrected as a requirement for a packet diversion
> 	  function on par with Pinholes and NAT.
> 
> 	If there was any substantial discussion on the latter, I missed
> it.
> 
> > Section 5.1 has a paragraph about direction, essentially stating
that
> > flows should be directional. I don't think that we have any
consensus on
> > this. Indeed, if you look at the scenario documents, there is not a
> > single example in which directional flows could be useful. Do we
really
> > want to enable communication one way without enabling it the other
way?
> > I think that this paragraph should be removed from the requirements.
> > Similarly, flow direction should be removed from the pin-hole
> > requirements in section 5.2.
> 
> 	RTP media flows are in practice often unidirectional.
> Yes, it is useful and desirable to allow one-way flows. The scenario
> documents should be updated to reflect this, if they do not.
> 
> 
> 		Andrew
> 
>