Hello All, thank you for valuable responses.
According to Paul, Proxies MUST NOT modify SDP in INVITE, but SBC CAN do it, It depends on implementation. So, in SBC case with NAT traversal feature, if 2 c= lines exist in SDP, 1 at session level and 1 at media level, what is the correct behaviour for SDP handling? igonore c line at session level or ignore c line at media level before sending 200 OK to ingress side? RFC 4566 says that media level c line has presedence over session level c line. Regards, On Wed, Jan 7, 2009 at 9:28 PM, Serbang, Nabam (Nabam) <nserb...@avaya.com>wrote: > > Hi All, > > First of all, I would like to extend my best new year 2009 wishes to you > all. > > There has been lots of very interesting discussion going on in this > topic. Thanks to all of you. > > To solve the issue with minimal effort and resource, I agree with Paul > group. From the standard perspective, I agree with Michael group (lets > not start a war :-) ) . > My take on this is following the standard is a good idea, at least for > uniformity. As standard can be changed, change for good, why not choose > the best method to address the issue and make it standard in next > release of the standard if not already addressed in existing standard. > I guess through discussion, one like this, we could suggest > standarization body to address the issue and tell them the best possible > solution ( Many man, many mind?). I'm not saying there are no standard > alread. I mean they can be refined if possible. > > > Thanks and regards > Nabam Serbang > > > > > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > Scott Lawrence > Sent: Wednesday, January 07, 2009 9:47 PM > To: Paul Kyzivat > Cc: Sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] How to determine where to send RTPpacket > in multi-proxy SIP network > > > On Wed, 2009-01-07 at 11:02 -0500, Paul Kyzivat wrote: > > > What Scott says seems reasonable. In his case, if the feature is > > turned off it really is a proxy. If the option is turned on, and SDP > > is updated, then the best you can say is that it is a proxy with > > non-compliant behavior. > > ... and I'm tarnishing my reputation as a Purist by releasing it :-) > > But the Real World is like that... the feature is needed, even if it > doesn't fit into the nice categories. > > Incidentally, using that NAT traversal feature unavoidably creates > problems for some things like redundant proxies that would theoretically > be possible without NATs, but our experience so far has been that: > > * Most deployments have to deal with NATs somewhere. We chose to > do as much compensation for this as we could by modifying SDP in > the "proxy" rather than a full B2BUA (the distinction being that > there is not a new set of dialog identifiers - both sides are > using the same call-id and tags). > > * In interop testing (some time ago - this may be improving), > we've found that many phones don't do the right thing with an > SRV name in a Route, so at present the Record-Route inserted by > the proxy is always an IP address, which makes the theoretical > redundancy for onging calls moot anyway. > > There are similar annoying issues with registrations, etc that have had > lots of discussion... > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > -- Erol Turaç _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
