Re: [Sipping] Is SDP in an unreliable response "the answer" ???

["DRAGE, Keith (Keith)" <keith.drage@xxxxxxxxxxxxxxxxxx>]

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