Re: About offeranswer draft:

Hi Paul,
inlines.


On Thu, Apr 15, 2010 at 10:42 PM, Paul Kyzivat <[email protected]> wrote:

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


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

BR
Eric



> 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