HIi All, I understand that any rfc or draft doesnt quote to restrict the "mline" but as far as i know it also doesn't says that it is mandatory to pass it out.
Now whats happening that whenever call is coming to my first SBC then getting complete list, but whenever my first SBC is passing the call to second SBC its stripping 2 codec from the "mline" as i mentioned earlier too. The below quote from RFC 3261 says that proxy must not modify or remove the message body. The proxy starts with a copy of the received request. The copy MUST initially contain all of the header fields from the received request. Fields not detailed in the processing described below MUST NOT be removed. The copy SHOULD maintain the ordering of the header fields as in the received request. The proxy MUST NOT reorder field values with a common field name (See Section 7.3.1). The proxy MUST NOT add to, modify, or remove the message body. So could anyone please give some light on this and help me to understand this whether it is wrong to remove the codec from mline or not. Thanks, Nitin Kapoor On 2 September 2010 14:28, Worley, Dale R (Dale) <[email protected]> wrote: > ________________________________________ > From: [email protected] [[email protected]] On Behalf Of Nitin > Kapoor [[email protected]] > > I am facing the problem where one of source is sending bunch of RTP payload > in "mline", and because of that my MSX is stripping 2 codec from that line, > when its forwarding that OFFER to termination end. > > This is the "mline" which i am getting from source: > > 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 13 120 > > This is what my MSX is sending to termination after stripping the payload > from "mline" > > 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 > > Now i checked some documents but unable to find anything which says its > correct or not. > ________________________________________ > > The input SDP is correct, of course. If the MSX's purpose is to limit the > number of codecs that the session may use, or to eliminate the use of the > codecs identified by 13 and 120, then it has succeeded. If its purpose is > to be transparent for SIP usage, its behavior is erroneous. > > Dale > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
