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
