Subject: Re: [MMUSIC] Why must PT be the same in send and receive directio n ?

From: Flemming Andreasen <[email-masked]>
Date: Fri, 04 Jan 2002 12:37:32 -0500

Jonathan Rosenberg wrote:

> In the interests of cooperation and forward progress, here is a proposal.
>
> The spec states that the answerer MUST use the same PT in forward and
> reverse directions, but that in some interworking cases when the
> answerer is a gateway, it is not possible to meet this. Therefore, the
> offerer SHOULD be prepared to see different dynamic PT in the answer.
>

Sounds good.

>
> I will note that proposals like this (sender MUST NOT do something, but
> receiver MUST be prepared to handle it anyway) have led to
> interoperability issues in the past.

Be conservative in what you send and liberal in what you receive.

> Thus, if we take this route, we
> must do so cautiously, providing sufficient motivation for people to
> understand why this was done.
>
> I'd like to see some inputs from implementors on the burden of
> supporting different PT in forward and reverse directions....

I've checked with some of our implementers, and they don't see a problem at
least (anybody supporting H.323 should not have a problem in this area)

-- Flemming

>
>
> -Jonathan R.
>
> Paul E. Jones wrote:
>
> > Flemming and Jonathan,
> >
> > I think the reason that the symmetry of PTs has not been an issue up to
> > this
> > point are two-fold:
> >   1) Interworking between H.245 and SDP-based systems has had less focus
> >   2) There have previously been few dynamic PTs used within H.245
> >      for which people have tried to interwork with SDP-based
> >      (Of course, they are used, but few people have cared about whether
> >       those PTs being used worked with SDP-based systems or not.  I
> > believe
> >       the first problem encounter that is of concern is the interworking
> >       of RFC 2833.)
> >
> > As we look at new codec types and the exchange of other signaling that
> > rely
> > on dynamic payload types, the H.323/SDP interworking problems in this
> > area
> > are forcing us to take note of the issues here.
> >
> > Within H.323, it is possible to exchange PTs in two ways:
> >   1) In the Setup message, and endpoint may propose "forward"
> >      and "reverse" audio/video/data channels and include the
> >      dynamic payload types
> >   2) The PTs might be conveyed through H.245 capabilities exchange
> >      (which is asymmetrical by nature)
> >
> > In either case, it is possible to have asymmetric usage of payload
> > types.  I
> > would suspect that in most cases, endpoint vendors who use (1) will
> > specify
> > the same PT for the "forward" and the "reverse" audio channel, though
> > that
> > is not required.For channels opened with knowledge learned through
> > (2),
> > there is certainly no guarantee of symmetric payload types.
> > Additionally,
> > there has not been a sense that such a restrictive requirement is
> > necessary.
> >
> > Media clipping is not an issue in (1) any more so than when using
> > SDP-based
> > protocols.  However, the use of (2) alone certainly might increase the
> > chances of clipping media, as the PTs may not be known at the calling
> > endpoint before media is received.  Hence, method (1) is strongly
> > encouraged, with method (2) used to provide information about
> > capabilities
> > that may be utilized during or after call setup that less time
> > sensitive,
> > such as T.120 multipoint data conferencing.  (2) is also used in order
> > to
> > establish A/V communication wherein the proposals from (1) are not
> > acceptable to the called party.
> >
> > In any case, interoperability between the two systems when using dynamic
> > payload types is a real issue that we need to tackle.
> >
> > Paul
> >
> > ----- Original Message -----
> > From: "Flemming Andreasen" <[email-masked]>
> > To: "Jonathan Rosenberg" <[email-masked]>
> > Cc: "MMUSIC" <[email-masked]>; <[email-masked]>; "Paul E Jones"
> > <[email-masked]>
> > Sent: Thursday, December 20, 2001 1:36 PM
> > Subject: Re: [MMUSIC] Why must PT be the same in send and receive
> > direction
> > ?
> >
> >
> >
> >>
> >>Jonathan Rosenberg wrote:
> >>
> >>
> >>>Flemming Andreasen wrote:
> >>>
> >>>
> >>>>The offer/answer model is quite explicit in stating that the
> >>>>
> > payload
> >
> >>>>type for a given codec MUST be the same in the send and receive
> >>>>direction and hence the payload type mapping for codec X in MUST
> >>>>
> > be
> > the
> >
> >>>>same in the offer and answer. However, this can cause a great deal
> >>>>
> > of
> >
> >>>>grief when interworking with H.323 based systems, since they can't
> >>>>necessarily guarantee this property.
> >>>>
> >>>>Now I can't think of a lot of reasons for the above offer/answer
> >>>>restriction, except that it guarantees a proper interpretation of
> >>>>
> > a
> >
> >>>>given payload type prior to receiving the actual answer to the
> >>>>
> > offer.
> >
> >>>Well, thats a good one. You are guaranteed to have media clipping
> >>>without this feature.
> >>>
> >>>
> >>Not quite: you are not guaranteed to not have media clipping without
> >>this
> >>feature.
> >>
> >>
> >>>It also makes it easy for the offerer to determine, from the answer,
> >>>
> > the
> >
> >>>matching of codecs in the offer to the answer. Its a simple numeric
> >>>comparison.
> >>>
> >>True
> >>
> >>
> >>>Without the same PT numbers, you need to do a
> >>>canonicalization based on the actual codec and parameters. Even
> >>>
> > minor
> >
> >>>inconsistencies in the construction of the rtpmaps in the answer can
> >>>cause confusion about which codec is which.
> >>>
> >>Not sure I see that. The only rule we have right now is that the
> >>
> > payload
> >
> >>type
> >>mapping must be the same in both directions, hence the only difference
> >>is
> >>whether you follow a dynamic payload type mapping to its canonical
> >>
> > name
> >
> >>or
> >>not.
> >>
> >>
> >>
> >>>Its also consistent with multicast operation.
> >>>
> >>>Overall, I think its just simpler.
> >>>
> >>I agree with that, but I don't see a huge difference.
> >>
> >>
> >>
> >>>>Unless there is another good reason for the restriction, I would
> >>>>
> > like
> > to
> >
> >>>>propose, that we allow it to be relaxed, i.e. turn it into a
> >>>>
> > SHOULD
> > and
> >
> >>>>put in a proper note explaining what might happen if you don't
> >>>>
> > follow
> >
> >>>>it.
> >>>>
> >>>Well, this turns into an interop nightmare for sip. We will have a
> >>>complete interop failure if a new UA generates an answer with
> >>>
> > different
> >
> >>>payload types.
> >>>
> >>>This text has also been in there for a very long time.
> >>>
> >>I know and that's a big concern to me too (if we were to make any
> >>changes).
> >>
> >>
> >>
> >>>How come no one
> >>>complained about this H.323 issue before? Its the first I've heard
> >>>
> > of
> > it.
> >
> >>Don't know, but it's apparently been around for a while. My H.323
> >>expertise is
> >>admittedly a little rusty (cc'ing more knowledgeable people here), but
> >>
> > I
> >
> >>believe the problem is that the H.245 OpenLogicaChannel request can be
> >>used to
> >>open a uni-directional or bi-directional stream, however in either
> >>
> > case,
> >
> >>it is
> >>possible that the sender and receiver end up specifying different
> >>payload type
> >>mappings for a given codec. This is particular troublesome in the case
> >>where
> >>the two sides open a uni-directional stream to the other side in
> >>parallel.
> >>
> >>Given the long-standing existing SDP/offer/answer baggage we have
> >>
> > here,
> >
> >>I
> >>believe you need to go for the lowest common denominator when mapping
> >>between
> >>SIP/SDP and H.323, and hence H.323 should have procedures in place to
> >>resolve
> >>asymmetric payload type mappings in cases where you need symmetry, but
> >>
> > I
> >
> >>wanted to raise the issue here to see what people think.
> >>
> >>Thanks
> >>
> >>        Flemming
> >>
> >>
> >>>-Jonathan R.
> >>>
> >>>--
> >>>Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> >>>Chief Scientist                         First Floor
> >>>dynamicsoft                             East Hanover, NJ 07936
> >>>[email-masked]                 FAX: (973) 952-5050
> >>>http://www.jdrosen.net                  PH:  (973) 952-5000
> >>>http://www.dynamicsoft.com
> >>>
> >>>_______________________________________________
> >>>mmusic mailing list
> >>>[email-masked]
> >>>https://www1.ietf.org/mailman/listinfo/mmusic
> >>>
> >>--
> >>Flemming Andreasen
> >>Cisco Systems
> >>
> >>
> >
>
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

--
Flemming Andreasen
Cisco Systems

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