Re: About offeranswer draft:

Eric - inline

Eric wang wrote:
> HI,
>     inlines.
> 
> BR.
> 2010/4/15 <[email protected] <mailto:[email protected]>>
> 
> 
>     Paul Kyzivat <[email protected] <mailto:[email protected]>> 写于
>     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?

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*.

When there are multiple early dialogs, it is indeed a challenge for the 
UAC to figure out what to do. And one of the things it might choose is 
to listen to one input stream and ignore the others. Unfortunately, 
there is universal and certain way to associate the incoming media 
streams you are receiving with the answers you have received in the 
signaling. You can do so in certain cases that may apply to you, such as 
when symmetric RTP is used (address/port of sender is same as 
address/port that is listened on.)

	Thanks,
	Paul


>        UAC                   UAS
>         | F1  INVITE (SDP1)   |  <-- offer
>         |-------------------->|
>         | F2     1xx (SDP2)   |
>         |<--------------------|
>         | F3     1xx (SDP3)   |
>         |<--------------------|
>         | F4     1xx (SDP4)   | 
>         |<--------------------|
>         | F5 1xx-rel (SDP5)   |<-- answer
>         |<--------------------|
>  
>  
> 
>      >
>      > > In your chart SDP4 is a reliable answer. Therefore SDP5 might be
>      > > interpreted as a new offer, hence UAC could send an answer in
>     PRACK.
>      > > Quite similarly to 3PCC cases, where 200 contains the offer and
>     ACK the
>      > > answer.
>      >
>      > That has been investigated. Its not allowed. (Unfortunately I cannot
>      > recall the chain of reasoning that derived its illegality - it wasn't
>      > obvious but it was sound. It was worked out a *long* time ago.)
>      >
>      >    Thanks,
>      >    Paul
> 
>     --------------------------------------------------------
>     ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
>     This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
>     This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
> 
> 
>     _______________________________________________
>     Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
>     This list is for NEW development of the application of SIP
>     Use [email protected]
>     <mailto:[email protected]> for questions on current sip
>     Use [email protected] <mailto:[email protected]> for new developments of core SIP
> 
> 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP