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
