Hello All, Thanks for the reply.
Here is another problem i observed into the "m" line, but not sure whether this is the issue or not. I noticed the wild space after "101" into the m line. m=audio 6300 RTP/AVP 18 0 8 35 36 2 38 39 40 41 42 43 44 45 46 47 4 80 3 56 118 *101 * Could anyone please let me know whether this correct or not to have the wild space. Thanks, Nitin Kapoor On 2 August 2010 19:40, WORLEY, Dale R (Dale) <[email protected]> wrote: > ________________________________________ > From: [email protected] [ > [email protected]] On Behalf Of Nitin Kapoor > [[email protected]] > > I am facing the issue with my SBC, where my source is sending me the > complete list of RTP payload and my SBC is returning back 488 Not > Acceptable > here. > > v=0 > o=BroadWorks 148094714 1 IN IP4 209.58.101.249 > s=- > c=IN IP4 195.189.150.38 > t=0 0 > m=audio 6300 RTP/AVP 18 0 8 35 36 2 38 39 40 41 42 43 44 45 46 47 4 80 3 56 > 118 101 > a=rtpmap:118 G729B/8000/1 > a=fmtp:118 annexb=yes > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=rtpmap:120 no-op/8000 > > Now when i checked the IANA RTP payload list, and observed that most of > them > are still unassigned. Could anyone please check the above SDP and > payload...and please help me whether it is correct to send 488 to > source...or not. > > And also if anything wrong in above, so please pinpoint it. I also feel > that > because of this CODEC packet size is increasing and causing the issue. > _______________________________________________ > > In principle, the other UA can respond 488 for any reason. Ideally, there > should be a Warning header describing what it does not like about the SDP. > > Only a small number of RTP payload type numbers have static assignments (0, > 3 through 18), so all others that are named in the m= line should have > a=rtpmap. In this case, 35 36 38 39 40 41 42 43 44 45 46 47 80 56 should > either be removed or have a=rtpmap lines provided. It is possible that > these ill-described payload type numbers are causing the problem, but the > other UA should ignore them. > > It is unlikely that the problem is the size of the SDP description. > > In any case, you should inquire of your SBC documentation or technical > support what the problem is. > > Dale > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
