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

[Craig Southeren <craigs postincrement com>]

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).

> 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.

> 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.

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.

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.

> 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