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

[Craig Southeren]

On Mon, 27 Nov 2006 00:21:46 +0800
"Joegen E. Baclor" <joegen at pldtweroam.com> wrote:

..deleted

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

We disagree on the interpretation of "prepared".

"Prepared" in this context means that once an offer has been sent, it
must be prepared to honor that offer.

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

This means that once the reply has been received, it can free resources
that may have been allocated as a result of the original offer.

For example, an endpoint that offers both audio and video, and then
receives a reply with only audio, can stop listening for video.
 
> It is MUST and also clearly implied that the offerer should be prepared 
> to accept ANY payload it sent with the offer.

There is no MUST in the para above.

..deleted

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

The payload types can and do change - Asterisk is a good example of this.
The fact that most endpoints don't do this is irrelevant.

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

I'm not sure why you think this. H.323 is the same as SIP in this regard
- the called party determines whether the same or different payload
types are used.

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

I disagree.

You are proposing a system whereby there are potentially three different
codec changes during call startup - first RTP payload detected, 183
Session Progress, and 200 OK. 

..deleted

Here are two references that show that RTP (even one way audio) is not
established in a SIP session until the receipt of a 183 Session Progress
or 200 OK. In fact, the 183 message was added specifically to allow the
establishement of early media for PSTN progress tones

I'm sure there are others

   Craig

draft-ietf-music-183-00.txt
-----------------------------
This was original source of the 183 message. There is an excellent
explantion of the problem, along with very clear call flow diagrams
showing the timing of RTP startup w.r.t to other SIP messages

http://www3.ietf.org/proceedings/99jul/slides/mmusic-sip183-99jul/sld008.htm


RFC 3666 - SIP Public Switched Telephone Network (PSTN) Call Flows
------------------------------------------------------------------
See call flow in section 2.3

-----------------------------------------------------------------------
 Craig Southeren          Post Increment – VoIP Consulting and Software
 craigs at postincrement.com.au                   www.postincrement.com.au

 Phone:  +61 243654666      ICQ: #86852844
 Fax:    +61 243656905      MSN: craig_southeren at hotmail.com
 Mobile: +61 417231046      Jabber: craigs at jabber.org

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting