Yep, thinking through this is probably the only case. I thought originally there might be some more. So I guess this is just a minor justification for repeating the answer (unchanged) in subsequent messages, including the final response. (It is also a reason against trying to implement changing it in subsequent messages, as there is no guarantee what order these will arrive in) regards Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@xxxxxxxxx] > Sent: Tuesday, April 20, 2010 3:05 PM > To: DRAGE, Keith (Keith) > Cc: Christer Holmberg; OKUMURA Shinji; sipping@xxxxxxxx > Subject: Re: [Sipping] Is SDP in an unreliable response "the > answer" ??? > > > > DRAGE, Keith (Keith) wrote: > > Do remember that there are certain cases where the UAC will > not ignore it. These are the cases where the message > containing original answer has not yet arrived or been lost, > and the protocol has not yet recovered from that. > > Hmm. Can you say more? > > Are you thinking of a case where the answer has been sent in > a reliable provisional, but the PRACK has not yet been > received? And then that > *some* SDP is included in a subsequent unreliable provisional, or 2xx? > > That is an interesting case. The one that would be least wierd is: > > UAC UAS > | INVITE (SDP1) | > |----------------->| > | 1xx REL (SDP2) | > | X--------------| > | 2xx (no SDP) | > |<-----------------| > > I think that implies a different best practice: > > If the UAS has sent an answer in a reliable provisional, if > it sends a 2xx before receiving a prack of the answer, it > should include the answer in the 2xx as well. > > (If the UAS intends to initiate another o/a it MUST await the > prack, so if the 1xx is lost it will be retransmitted.) > > Thanks, > Paul > > > > > | | > |<-----------------| > | | > | | > |----------------->| > | | > |<-----------------| > | | > | | > |----------------->| > | | > |<-----------------| > | | > | | > |----------------->| > | | > |<-----------------| > | | > | | > |----------------->| > | | > |<-----------------| > | | > > > regards > > > > Keith > > > >> -----Original Message----- > >> From: sipping-bounces@xxxxxxxx > >> [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Christer Holmberg > >> Sent: Tuesday, April 20, 2010 1:47 PM > >> To: OKUMURA Shinji; sipping@xxxxxxxx > >> Subject: Re: [Sipping] Is SDP in an unreliable response > "the answer" > >> ??? > >> > >> > >> Hi, > >> > >>>>> Before sending an answer, > >>>>> - An UAS MAY send unreliable provisional responses with a SDP. > >>>>> - And the SDP MUST be identical to an answer SDP. > >>>>> > >>>>> After sending an answer, > >>>>> - The UAS should not insert a SDP in any response. > >>>>> > >>>>> Is this OK? > >>>> That text still doesn't say what an SDP inserted after > sending the > >>>> answer means, only that it should not be sent. > >>> The SDP means nothing. it is neither an offer nor an answer. > >> Exactly. In my opinion that is what is important - not whether the > >> UAS inserts SDP or not. > >> > >>>> I still don't see why we need to make a separation about > SDP sent > >>>> before and after the answer, because in both cases the > SDP must be > >>>> identical to the answer. > >>> 1. RFC3261 says that UAS MAY send it before the answer and > >>> doesn't say nothing after the answer. > >> That is one reason why we are writing the draft - to > clarify things > >> which may not be clear in the specs. > >> > >>> 2. The SDP MUST be ignored by UAC. it is meaningless. > >> I agree, and that is what we must be clear about. Because, as we > >> know, some people want to send a NEW offer (or updated > >> answer) in a subsequent response, and that is not allowed. > >> > >> > >>> 3. if another o/a exchange is occured (using UPDATE or > >> PRACK), it is not even a confirmation. > >>> And, again, I know there are many implementations that send > >> a copy of > >>> the SDP after the SDP answer has been sent, so instead of > >> saying that > >>> it should not be done I think it is much more important to > >> say that, if > >>> it is done, it must be identical to the SDP answer. In other > >> words, to > >>> make it clear that the UAS can not send a NEW offer (or > >> updated answer) > >>> in a subsequent response after the SDP answer has been sent. > >>> > >>> Since UAC MUST ignored it, there is no problem on a interworking. > >>> Why must it be identical to the SDP answer? > >> Well, if you look at it that way, fine. But, then the > important thing > >> is that the UAC must ignore it - not that the UAS should > not send it. > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>> Hans Erik van Elburg <ietf.hanserik@xxxxxxxxx> Mon, 19 Apr 2010 > >>>> 13:55:41 +0200 > >>>>>> - An UAS MAY insert a SDP body that is identical to the > >>> SDP answer, > >>>>>> in an unreliable provisional response before the SDP > >> answer has > >>>>>> been sent. > >>>>>> > >>>>>> - The UAS MUST NOT insert a SDP body that is not > >>> identical to the > >>>>>> SDP answer, in an unreliable provisional response > >> before the SDP > >>>>>> answer has been sent. > >>>>>> > >>>>> This is terribly confusing. Very probabe that noone will > >>> get it right. > >>>>> Triple negation. And talking about sending and answer > before the > >>>>> answer has been sent. ??? > >>>>> > >>>>> > >>>>>> - The UAS MUST NOT insert a SDP body in any response > >>> after the SDP > >>>>>> answer has been sent. > >>>>>> > >>>>> This means that you can't send it again after you've send > >> it in an > >>>>> unreliable provisional response. Do you want tto say that? > >>>>> > >>>>> /Hans Erik van Elburg > >> _______________________________________________ > >> 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 > >> > > _______________________________________________ > > 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 > > > _______________________________________________ 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
