[ previous ] [ next ] [ threads ]
 To :  <Yate@v...>
 From :  "Andrew McDonald" <andrew.mcdonald@n...>
 Subject :  [yate] RFC3264 conformance ?
 Date :  Mon, 21 Aug 2006 12:12:25 +0800

I was making an echo test call to YATE (v1.0), via a recent version of Asterisk, when I discovered that there was no return RTP stream being sent.

Asterisk generates an invite with the following offer:
m=audio 10044 RTP/AVP 8 0 97 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

YATE responds with the following answer, note it accepts both alaw and mulaw (we do not have any other codecs active):
m=audio 27788 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000

The rtp that Asterisk actually chooses to send is _mulaw_. Note this is despite the fact that alaw was listed as a higher preference by both parties. This is unusual however it is allowed under RFC3264. 

More specifically given a subset of agreed codecs (in this case alaw,mulaw) both the offerer and answerer should be prepared to received media in any of the agreed formats, indeed either end may switch codecs on the fly within the set of agreed codecs, _without_ renegotiation.

I added references from the relevant sections of RFCs 2327 and 3264 at the end of the email.

Examination of the YATE logs with message sniffing turned on shows that YATE correctly detects the subset of codecs it supports from the offer, as it generates a call.execute method with
  param['formats'] = 'alaw,mulaw'
Further on it generates a chan.rtp message in the YSIP endpoint with
  param['format'] = 'alaw'

The chan.rtp message was presumably sent from;
// Dispatches a RTP message for a media, optionally start RTP and pick parameters
bool YateSIPConnection::dispatchRtp(RtpMedia* media, const char* addr, bool start, bool pick)
which sets the format parameter as follows;
The format() member of RtpMedia specifically returns the first format. In this case alaw.

This message is processed by the rpt module which configures itself to handle alaw as follows:
 YRTPWrapper::startRTP("",10044) [00DC2958]
 RTP format 'alaw' payload 8
>>> DataTranslator::detachChain(00DC4318,00A342A8)
<<< DataTranslator::detachChain
 Created DataTranslator 003F68B8 for 'alaw' -> 'slin' by factory 1007C0A4 (

I presume that this means the actual mulaw rtp that is sent is never decoded and thus no audio is echoed back.

I hope my interpretation of the RFC correct ?

Having looked at the code it is not clear to me whether it was ever intended to handle more than the single (highest preference) codec, despite generating answers that accept multiple codecs, and I am a little unsure as to whether or    not the code can be changed easily to conform. 

YRTPWrapper::startRTP is certainly written to handle a single format. I could obviously rewrite YateSIPConnection::dispatchRtp to dispatch multiple chan.rtp messages (one for each format) but I am not sure whether they would simply end up replacing one another (I have more code reading to do). I will probably try this change shortly just to see the result.

I was wondering if someone could advise me as to whether they feel a change is required and if so, an indication of the most appropriate way in terms of adhering to current YATE design philosophy ?

Obviously this does not affect cases where YATE is not in the media path e.g. use as a call signalling gateway (SIP/H323 etc). This was also only revealed in this case by a remote offerer that did not choose the highest preference codec, which we might expect to be comparatively rare. Thus this is not necessarily an interoperability issue that will show up too often, although it is possibly SIP Application Servers that are most likely to need to play these kind of media "games" ;), and demand a higher level of conformance. 

In our case, luckily for us all endpoints and codecs are under our control so we have simply reconfigured YATE to only support a single codec which eliminates the issue for the time being.

Out of interest we will also probably investigate why Asterisk does not choose the highest preference codec, although this is not a non-conformance.

RFC 2327 SDP: Session Description Protocol

6.  SDP Specification
Media Announcements
[Page 20]
When a list of payload formats is given, this implies that all of
     these formats may be used in the session, but the first of these
     formats is the default format for the session.

RFC 3264  An Offer/Answer Model Session Description Protocol

5 Generating the Initial Offer
5.1 Unicast Streams
[Page 5]
If multiple formats are listed, it
means that the offerer is capable of making use of any of those
formats during the session.  In other words, the answerer MAY change
formats in the middle of the session, making use of any of the
formats listed, without sending a new offer. 

[Page 6]
In all cases, the formats in the "m=" line MUST be listed in order of
preference, with the first format listed being preferred.  In this
case, preferred means that the recipient of the offer SHOULD use the
format with the highest preference that is acceptable to it.

6 Generating the Answer
6.1 Unicast Streams
[Page 9]
The media formats in the "m=" line MUST be listed in order of preference,
with the first format listed being preferred.  In this case,
preferred means that the offerer SHOULD use the format with the
highest preference from the answer.

[Page 10]
Once the answerer has sent the answer, it MUST be prepared to receive
media for any recvonly streams described by that answer.  It MUST be
prepared to send and receive media for any sendrecv streams in the
answer, and it MAY send media immediately.  The answerer MUST be
prepared to receive media for recvonly or sendrecv streams using any
media formats listed for those streams in the answer,

The answerer MUST send using a media format in the offer
that is also listed in the answer, and SHOULD send using the most
preferred media format in the offer that is also listed in the
answer.  In the case of RTP, it MUST use the payload type numbers
from the offer, even if they differ from those in the answer.

7 Offerer Processing of the Answer

When the offerer receives the answer, it MAY send media on the
accepted stream(s) (assuming it is listed as sendrecv or recvonly in
the answer).  It MUST send using a media format listed in the answer,
and it SHOULD use the first media format listed in the answer when it
does send.

The reason this is a SHOULD, and not a MUST (its also a SHOULD,
and not a MUST, for the answerer), is because there will
oftentimes be a need to change codecs on the fly. 




Andrew McDonald
System Architect

Norwood Systems Australia Pty Ltd
71 Troy Terrace
PO Box 1281
Subiaco, WA 6904

Tel	+61 8 9380 7766		
Fax	+61 8 9380 7733  		
The information in this email, and any attachments, may contain confidential information and is intended solely for the attention and use of the named addressee (s). It must not be disclosed to any person(s) without authorization. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorized to, and must not, disclose, copy, distribute, or retain this message or any part of it. If you have received this communication in error, please notify the sender immediately.