Re: About offeranswer draft:

在 2010年4月15日 下午1:29，Eric wang <[email protected]>写道：

> Hi Paul,
>    I have been in the world for many years =_=!!!!
>    We shouldn't make complicated rules because the system has already  been
> complicated.
>
>   In my opinion, the offer/answer model works well if responses are
> reliable.
>   If we allow several reliable 18x with SDP, what happen if 18x is after
> UPDATEs.There must be some rules saying "NO".I prefer several reliable 18xs
> with SDP appear only in fork.
>
>  BR
>  Eric
>
>
>
> 在 2010年4月14日 下午10:02，Paul Kyzivat <[email protected]>写道：
>
>
>>
>> Eric wang wrote:
>> > Hi all,
>> >
>> >     I believe that SDP in non-reliable response is useful. eg, if the
>> > UAS wants to send a tone to UAC while the UAC doesn't support 100rel,
>> > the UAS can use a non-reliable response with the tone SDP.
>> > So I believe different SDPs(compare with the answer) can exist in
>> > non-reliable response and final 2xx response.
>>
>> IMO this makes no sense. For one thing, the UAC is instructed to accept
>> the first and ignore the rest, so sending differing values will have no
>> utility. For another, this only affects where the UAS will receive media
>> - it can have no effect on where the UAC receives media. Generally the
>> UAC isn't transmitting until the call is established, so what is the
>> point.
>>
>> >    But, when I saw the chart below, the only words in my mind is ,"OMG,
>> > the SIP is never SI(m)P(le) again!"
>>
>> Where have you been? SIP hasn't been simple since early in the century.
>>
>>        Thanks,
>>        Paul
>>
>>
>> > 2010/4/14 OKUMURA Shinji <[email protected]
>> > <mailto:[email protected]>>
>>  >
>> >     Hi Gao,
>> >
>> >     In the following case,
>> >
>> >          UAC                   UAS
>> >           | F1  INVITE (SDP1)   |  <-- offer
>> >           |-------------------->|
>> >           | F2     1xx (SDP2)   |
>> >           |<--------------------|
>> >           | F3     1xx (SDP3)   |
>> >           |<--------------------|
>> >           | F4 1xx-rel (SDP4)   |  <-- answer
>> >           |<--------------------|
>> >           | F5 1xx-rel (SDP5)   |
>> >           |<--------------------|
>> >           | F6    1xxl (SDP6)   |
>> >           |<--------------------|
>> >           | F7  2xx INV(SDP7)   |
>> >           |<--------------------|
>> >           | F8     ACK          |
>> >           |-------------------->|
>> >        (PRACK transactions are not shown)
>> >
>> >     I tried to arrange the rules.
>> >     (small letters mean informational)
>> >
>> >     UAC,
>> >     (Rc1)   MUST treat SDP2 as the answer.
>> >     (Rc2)   MUST ignore SDP5, SDP6 and SDP7.
>> >     (Rc3)   may treat SDP3 as the answer.
>> >     (Rc4)   should treat SDP4 as the answer and confirm the current O/A
>> >     status by sending new offer.
>> >
>> >     UAS,
>> >     (Rs1)   should not send SDP5, SDP6 and SDP7.
>> >     (Rs2)   must not send SDP2 and SDP3 if these are not the same as
>> SDP4.
>> >
>> >     Rc3 and Rc4 are new added descriptions.
>> >     Rs1 and Rs2 are current descriptions in this draft.
>> >
>> >     I think "MUST NOT" is suitable for (Rs1).
>> >     Because RFC3261 says
>> >            Once the UAS has sent or received an answer to the initial
>> >            offer, it MUST NOT generate subsequent offers in any
>> responses
>> >            to the initial INVITE.  This means that a UAS based on this
>> >            specification alone can never generate subsequent offers
>> until
>> >            completion of the initial transaction.
>> >
>> >     SDP5 and SDP7 are regarded as "subsequent offers".
>> >
>> >     What do you think of these?
>> >
>> >     Regards,
>> >     Shinji
>> >
>>
>

_______________________________________________
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