On Mon, 2009-04-27 at 14:58 +0530, friend friend wrote: > Dear Folks, > I have doubt in the following scenario. > > Caller's sdp : > > v=0 > o=- 1234 1 IN IP4 10.10.20.35 > s=- > c=IN IP4 10.10.20.35 > t=0 0 > m=audio 12000 RTP/AVP 102 0 8 106 > a=rtpmap:102 iLBC/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=rtpmap:106 telephone-event/8000 > > > Callee's negotiated sdp : > > v=0 > o=- 3449811996 3449811996 IN IP4 10.10.20.4 > s=SJphone > c=IN IP4 10.10.20.4 > t=0 0 > m=audio 49164 RTP/AVP 97 101 > c=IN IP4 10.10.20.4 > a=rtpmap:97 iLBC/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=setup:active > a=sendrecv > > In this case,Is callee's negotiation method is wrong? > > Callee should send like m=audio 49164 RTP/AVP 102 106 rite? > > In this case, after call establishment, > from caller sending RTP using 102 (UnKnown) > from callee sending RTP using 97 (iLBC) > > So caller hearing callee's audio but callee not able to hear caller's audio.
Although it is "not recommended", the answerer is allowed to choose different codec number for a codec than the offerer used. See section 6 of RFC 3264 for the details. In any case, an SDP offer or answer describes how the UA that generated it is willing to *receive* media: 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. In your case, the caller must send media to the callee at address 10.10.20.4, port 49164, using number 97 for iLBC and number 101 for telephone-event -- that's what the answer specifies. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
