erol turac wrote:
> 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.
It seems you have already answered your own question.
Think of the c= at session level as a *default* for a missing c= at the
media level.
Paul
> Regards,
>
> On Wed, Jan 7, 2009 at 9:28 PM, Serbang, Nabam (Nabam)
> <nserb...@avaya.com <mailto: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>
> [mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
