Re: [Sipping] About offeranswer draft:

[Eric wang <eric.wangxr@xxxxxxxxx>]

在 2010年4月15日 下午1:29，Eric wang <eric.wangxr@xxxxxxxxx>写道：

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 <pkyzivat@xxxxxxxxx>写道：

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 <shinji.okumura@xxxxxxxxxxxx

> <mailto:shinji.okumura@xxxxxxxxxxxx>>

>
>     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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP