Re: [Ekiga-list] [OpenH323]Re: Receiving SIP RTP before media description [was ekiga answers with delay ...?]

["Joegen E. Baclor" <joegen pldtweroam com>]

Craig Southeren wrote:
> On Sun, 26 Nov 2006 12:12:02 +0100
> Damien Sandras <dsandras seconix com> wrote:
>
>   
> > Le dimanche 26 novembre 2006 à 12:33 +1100, Craig Southeren a écrit :
> >
> > [...]
> >
> >     
> > > If anything, it would be a bug in OPAL, and so I have copied this email
> > > to the correct OPAL mailing list so that other people who are
> > > knowledgeable in SIP may see it.
> > >
> > >       
> > Most of the OPAL bugs are inside the Ekiga bug tracker. I have moved
> > those I don't plan to fix to the openh323 bug tracker.
> >     
>
> Understood, and thanks.
>
>   
> > However, I think the paragraph in the SIP RFC is clear, when you send an
> > offer, you must be ready to receive media for all codecs in that offer
> > before the offer has been acknowledged. I understand it sounds weird,
> > but that is one of the limitations of OPAL.
> >     
>
> I disagree. 
>
> I think that this interpretation is wrong (see my previous email for why).
>
>   
I agree with Damien, a offerer "MUST" be ready to accept any stream it 
offered even without the the answer.

Section 5.1, last paragraph

Once the offerer has sent the offer, it MUST be prepared to receive
media for any recvonly streams described by that offer. It MUST be
prepared to send and receive media for any sendrecv streams in the
offer, and send media for any sendonly streams in the offer (of
course, it cannot actually send until the peer provides an answer
with the needed address and port information).



Section 7, 3rd paragraph of RFC 3264 states:

   The offerer MAY immediately cease listening for media formats that
   were listed in the initial offer, but not present in the answer.

It is MUST and also clearly implied that the offerer should be prepared 
to accept ANY payload it sent with the offer.

> > Another limitation is that the codec to use is determined from the 200
> > OK answer in a way that is not necessarily correct.
> >
> > For example, if you send an INVITE with iLBC, PCMU and PCMA as available
> > codecs, and the answer comes with PCMU, PCMA and iLBC (in that order)
> > back, how do you determine if you have to send iLBC or PCMU? OPAL will
> > send PCMU because it is the preferred codec in the answer.
> >     
>
> The endpoint is free to chose any offered codec it wants. This may
> result in different codecs in each direction - this is OK and may be
> desirable in some cases.
>
>   

Although it is only a SHOULD in 3264, most implementations follow the 
same dynamic payload type in the answer as they were mapped in the 
offer. It is implied in the following section in 3264 ( Section 5.1 
Paragraph 4 )

For sendrecv RTP
streams, the payload type numbers indicate the value of the payload
type field the offerer expects to receive, and would prefer to send.
However, for sendonly and sendrecv streams, the answer might indicate
different payload type numbers for the same codecs, in which case,
the offerer MUST send with the payload type numbers from the answer.

Different payload type numbers may be needed in each direction
because of interoperability concerns with H.323.


> > However, the codec to use should be determined by the RTP payload. So
> > OPAL should be able to send and receive PCMU/PCMA/iLBC, and choose the
> > correct one as soon as it receives RTP from the remote peer.
> >     
>
>   

I disagree that the first RTP Packet would signify the actual codec to 
be used for the session. The final answer should still be considered. 
During instances where the initial packet received is not equal to the 
preferred codec in the answer, the offerer should honor the codec in the 
answer for its outbound stream. If the offere want synchronized codec 
for send and receive, then it should offer a reInvite with the single 
codec preference it chooses based on the codecs it got from the answer.





> No, this is not correct because the receiving endpoint can chose a
> differend payload type. For example, you can offer to do iLBC with
> payload type 108, and Speex with payload type 109. The receiver then
> decides do Speex with payload type 108 and starts sending RTP with
> payload code 108.
>   

This scenario may indeed happen for dynamic payload type. However, given 
that the offer only contains standard only payloads, being prepared to 
receive them any time still holds. I think this is the main reason why 
synchronizing payload mapping is a mere should and not a MUST. The worse 
thing that would happen is that packets would be dropped by the UAC 
until a reInvite is sent to arrive at a single and final codec.

> If the offerer starts processing media when it receives the first RTP
> packet, it will assume it is iLBC, which is wrong.
>
> There is no way to avoid this problem other than to wait for the session
> parameters. See my previous email for other reasons.
>
>   
From my understanding of RFC 3264, if the offer sent a sendrecv 
(default) using a certain payload mapping, the the offer should honor 
that mapping. The only time unsync streams can occur would be when the 
offer contains a sendonly attribute for the payload.

However, given that indeed there are implementations out there that 
would ignore such implied "MUST" in 3264, this would result to temporary 
failure in processing media correctly but would still be corrected upon 
receipt of actual answer or with a reInvite if the answer contains 
multiple payloads. It is better to start processing media and hope that 
it works than not process it at all when it is present. The only fatal 
assumption here is to assume that the first received packet will be 
considered as the final negotiated codec. This is wrong in my opinion.





> > However, that is a non trivial change to OPAL.
> >     
>
> It is extremely non-trivial. Robert and I cannot even see a way to do it
> that would not require major surgery to OPAL.
>
>   
> > What do you think?
> >     
>
> Robert and myself discussed this this topic yesterday. Our opinion is in
> my previous email
>
>    Craig
>
> -----------------------------------------------------------------------
>  Craig Southeren          Post Increment – VoIP Consulting and Software
>  craigs postincrement com au                   www.postincrement.com.au
>
>  Phone:  +61 243654666      ICQ: #86852844
>  Fax:    +61 243656905      MSN: craig_southeren hotmail com
>  Mobile: +61 417231046      Jabber: craigs jabber org
>
>  "It takes a man to suffer ignorance and smile.
>   Be yourself, no matter what they say."   Sting
>
> ------------------------------------------------------------------------
> Check the FAQ before asking! - http://www.openh323.org/~openh323/fom.cgi
> The OpenH323 Project mailing list, using Mailman. To unsubscribe or
> change your subscription options, goto
> http://www.openh323.org/mailman/listinfo/openh323
> Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
> ------------------------------------------------------------------------
>
>