inline, with some trimming Eric wang wrote: > Hi Paul, > inlines. > > > On Thu, Apr 15, 2010 at 10:42 PM, Paul Kyzivat <pkyzivat@xxxxxxxxx > <mailto:pkyzivat@xxxxxxxxx>> wrote: > > Eric - inline > > Eric wang wrote: > > HI, > inlines. > > BR. > 2010/4/15 <gao.yang2@xxxxxxxxxx <mailto:gao.yang2@xxxxxxxxxx> > <mailto:gao.yang2@xxxxxxxxxx <mailto:gao.yang2@xxxxxxxxxx>>> > > > Paul Kyzivat <pkyzivat@xxxxxxxxx <mailto:pkyzivat@xxxxxxxxx> > <mailto:pkyzivat@xxxxxxxxx <mailto:pkyzivat@xxxxxxxxx>>> 写于 > > 2010-04-14 22:12:48: > > > > > > > > Somogyi, Gabor (NSN - HU/Budapest) wrote: > > > Hi, > > > > > RFC3261: "...MUST ignore any session > descriptions in subsequent > > > responses..." > > > I think that the common industry understanding of RFC3261 is > that 1 > > > offer has 1 answer, even though that 1 answer may be > transmitted several > > > times. > > > > Yes. Well, actually one answer per dialog. (With forking, > an offer in > > the initial invite will get a separate answer > per-forked-dialog.) > > > > > And the 1st transmission is used (treated as THE > answer). While > > > you are speaking about several answers with 1 matching > offer. > That is a > > > fundamental difference. > > > > This of course only makes sense if the sdp in all unreliable > responses > > is the same as the sdp in the first reliable response. > That is so > > because any/all of the unreliable responses may be lost. > You cannot > > count on the UAC using the SDP from the first transmission. > > > > And because of that, a valid implementation could drop all > the SDP > > received unreliably and only process the one received > reliably. > > > Supporting of this. > My point here is that making UAC's using of the SDP in first > reliable response normatively, no matter how many SDP it received > before the *real* answer. And how UAC handle SDP(from UAS) before > the real answer is another issue, it can be BCP issue. > Eric: I think, the UAC should listen the SDP sending > packets,and choose another to listen according to rfc3264. > Reuse Shinji 's chart, if SDP2 sends packets while SDP3/SDP4 don't, > the UAC should listen SDP2 and SDP5. > > > Eric, > > I think you may be talking about cases where the call has been > forked to different destinations, and the distinct answers are > coming from them. Is that right? > > No. I meant there may be several non-reliable responses in a *single* > dialog. > There maybe several servers that want to send non-reliable response with > SDP(neither offer nor answer) to the caller.I accept it as non-reliable > responses with SDP can also establish early dialog for tone/announcement > and do nothing with offer/answer negotiation between the caller and the > called. > I know it violate rfc3261, but it's useful and simple. Well, if you agree it violates 3261 then lets stop talking. You can do lots of non-conforming things that are simple and useful. But doing them results in interoperability problems. And I will assert that you can achieve what you wish in a conforming way simply by having those separate servers use a distinct to-tag for their response, thus creating distinct early dialogs. The UAC will then understand them for what they are - responses from different entities - and can decide how to render them with that understanding. > Because in that case the responses should have different to-tags, > thus becoming distinct (early) dialogs. The discussion we are having > is about what happens in a *single* dialog. And in a single dialog > the behavior you describe is *wrong*. > > But I cannot accept that several reliable responses with SDP appear in a > single dialog, and it seems be allowed in Shinji's chart. Shinji was using that as an example of *invalid* usage, for the purpose of discussing how the UAC might react to such invalid usage. Thanks, Paul _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
