Here are my comments: I think that, strictly speaking, the answerer does not conform to RFC3264.
Firstly (though I can't find the section that bans this) the answerer includes media formats that weren't in the offer. The offerer clearly can't do pcmu or pcma, so why include them in the answer. Secondly, in the answer, one should only list multiple formats if you can support dynamic switching between them. I get this from top of page 22 RFC3264. > Bob can support dynamic switching between PCMU and G.723. So, he > sends the following answer: Can the X-PRO really support dynamic switching between all its listed media formats? Thirdly, the different codec in both directions might be eliminated if this paragraph in RFC3264 was adhered to: Although the answerer MAY list the formats in their desired order of preference, it is RECOMMENDED that unless there is a specific reason, the answerer list formats in the same relative order they were present in the offer. In other words, if a stream in the offer lists audio codecs 8, 22 and 48, in that order, and the answerer only supports codecs 8 and 48, it is RECOMMENDED that, if the answerer has no reason to change it, the ordering of codecs in the answer be 8, 48, and not 48, 8. This helps assure that the same codec is used in both directions. Regards, Attila > -----Original Message----- > From: Franz Edler [mailto:[EMAIL PROTECTED] > Sent: 10 September 2003 14:20 > To: [EMAIL PROTECTED] > Subject: [Sip-implementors] Question on codec selection > > > Hello, > > I am analyzing the trace of an unsuccessful SIP conversation > to find the > possible problem. The SIP message flow was ok (INVITE/200/ACK), media > streams flowed in both directions, but I could not hear my partner. > > During analysis two questions come up: > > 1. I recognized (from RTP stream analysis), that both parties use a > different codec to send. > My user agent (MS Messenger 5.0) sends with PT=3 (GSM/8000) > and the other > user agent (X-PRO) sends with PT=97 (speex/8000). Both > payload types are > valid, because both are included in offer and answer SDP. > But isn't it a bit strange, that the answerer does not use the first > (common) media stream of the answer, which would have been PT=3? > The offerer follows the recommendation of RFC 3264 ( ... it > SHOULD use the > first media format listed in the answer when it does send). > > Below are the the offer ans answer details. I have marked the sent and > received streams with s-> and r->. > > The SDP in the offer (Messenger 5.0): > v=0 > o=- 0 0 IN IP4 212.152.200.96 > s=session > c=IN IP4 212.152.200.96 > b=CT:44 > t=0 0 > m=audio 28376 RTP/AVP 97 111 112 4 3 101 > k=base64:A4wdo2GTiv2T8pRGMqQgG3+3UZD1UodEC4weTCZrRs0 > r->a=rtpmap:97 red/8000 > a=rtpmap:111 SIREN/16000 > a=fmtp:111 bitrate=16000 > a=rtpmap:112 G7221/16000 > a=fmtp:112 bitrate=24000 > a=rtpmap:4 G723/8000 > s->a=rtpmap:3 GSM/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=encryption:optional > > > The SDP in the answer (X-PRO): > v=0 > o=X 41745451 41745451 IN IP4 65.39.205.114 > s=X-PRO > c=IN IP4 65.39.205.114 > t=0 0 > m=audio 10916 RTP/AVP 0 8 3 4 98 97 101 > a=rtpmap:0 pcmu/8000 > a=rtpmap:8 pcma/8000 > r->a=rtpmap:3 gsm/8000 > a=rtpmap:98 iLBC/8000 > s->a=rtpmap:97 speex/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > > > 2. The dynamic payload type 97 has a different description on both > SDP-parts. > - Messenger 5.0 description is "a=rtpmap: 97 red/8000" > - X-PRO description is "a=rtpmap: 97 speex/8000" > If X-PRO sends with "speex"-codec and Messenger receives as > "red" it might > not be decodeable, as I suggest, because these are different > codecs. Maybe > this is the cause auf the unsuccessful call. > > > Any comments highly appreciated. > > > Franz > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
