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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christer,

Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>
Wed, 21 Apr 2010 13:55:15 +0200
>Hi, 
>
>>I understand that this is a very rare case,
>> 
>>         A                                 B
>>         |                                 |
>>         |INVITE (offer)                   |
>>         |================================>|
>>         |                  1xx-rel(answer)|
>>         |<===========\  /=================|
>>         |             \/                  |
>>         |             /\ 18x-norel(answer)|
>>         |<===========/  \=================|
>>         |PRACK                            |
>>         |-------------------------------->|
>>         |                                 |
>> 
>>IIUC, if 18x-norel has a SDP(answer), UAC(A) can not insert 
>>new offer into PRACK.
>
>You now seem to be suggesting that an SDP answer can be
>transported unreliably. I strongly disagree to such statement.

NO. An SDP answer transported unreliably is only a "preview" of
the true answer.
I know it well.

>A copy of the SDP answer can be sent unreliably, and the UAC can
>use it, but the "real" SDP answer must still be sent reliably.
>
>Maybe "ignore" is the wrong wording. The UAC cannot ignore
>the fact that the reliable response contains the SDP answer,
>because THAT SDP finishes the offer/answer transaction,
>but it does not need to parse it.

That's right. "ignore" confuse me. Another clarification is
necessary.

If 18x-norel has no SDP, this confusion can not be occured.
Because offer/answer rules are complicated enough,
somening unnecessary should not exist.

It's "Best" Current Practices, I think.

Regards,
Shinji

>Regards,
>
>Christer
>
>> 
>> To avoid this situation UAS should not ...
>> 
>> Regards,
>> Shinji
>> 
>> Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> Wed, 21 
>> Apr 2010 12:23:39 +0200
>> >Hi,
>> >
>> ><Dean Willis hat on>
>> >
>> >Offer/answer is a mess. Instead, let's regard media as an 
>> application 
>> >on top of SIP, and use an Info Package for negotiating the 
>> media. There 
>> >is no connection to the SIP transactions, which means we don't need 
>> >complicated rules on when and where to insert SDP, and we 
>> don't need to 
>> >describe how offer/answer works for re-INVITEs etc.
>> >
>> ><Dean Willis hat off>
>> >
>> >I don't disagree with what people are saying, but trying to read it 
>> >from a I-am-a-new-implementor-and-I-would-like-to-
>> >get-it-right-from-the-beginning perspective I don't think 
>> anything is 
>> >clarified. Eg. talking about that an SDP sent after the 
>> answer would be 
>> >"missunderstood as a new offer"
>> >is confusing. The important thing is not whether the UAS 
>> includes the 
>> >UAS answer in subsequent responses or not, because the UAC 
>> still has to 
>> >handle such situation.
>> >What is important is that the UAS MUST NOT send a *new* offer.
>> >
>> >Regards,
>> >
>> >Christer
>> >
>> >> -----Original Message-----
>> >> From: sipping-bounces@xxxxxxxx
>> >> [mailto:sipping-bounces@xxxxxxxx] On Behalf Of OKUMURA Shinji
>> >> Sent: 21. huhtikuuta 2010 8:45
>> >> To: sipping@xxxxxxxx
>> >> Subject: Re: [Sipping] Is SDP in an unreliable response 
>> "the answer" ???
>> >> 
>> >> Hi,
>> >> 
>> >> Hans Erik van Elburg <ietf.hanserik@xxxxxxxxx> Tue, 20 Apr 2010 
>> >> 21:53:17 +0200
>> >> >On Tue, Apr 20, 2010 at 3:47 PM, Paul Kyzivat <pkyzivat@xxxxxxxxx> wrote:
>> >> >> Here is my attempt at summarizing the discussion conclusions:
>> >> >>
>> >> >> Normative things (stated or implied in existing RFCs):
>> >> >>
>> >> >> - If the UAC sent an offer in the INVITE, then after it receives 
>> >> >> SDP (the
>> >> >> answer) in a reliable response to the INVITE, any SDP in 
>> >> >> subsequent responses to the INVITE MUST be ignored.
>> >> >>
>> >> >> - Further, if SDP is received in an unreliable response to the 
>> >> >> invite prior to receiving SDP in a reliable response, then it MUST 
>> >> >> be treated as the answer for purposes of media processing, but not 
>> >> >> for purposes of determining when another offer may be sent or received.
>> >> >>
>> >> >[HE] I miss what the UAC should do in this case for subsequent 
>> >> >responses, does the following hold as well:
>> >> >"If the UAC sent an offer in the INVITE, then after it receives SDP 
>> >> >(the answer) in an unreliable response to the INVITE, any SDP in 
>> >> >subsequent responses to the INVITE MUST be ignored/granted/... ." ?
>> >> 
>> >> I agree. And it's certainly "ignored".
>> >> 
>> >> >Regardless what the correct behaviour is, it is missing in
>> >> your summary.
>> >> >
>> >> >> - if the UAS receives an offer in the INVITE, it MUST NOT include 
>> >> >> SDP in any response it sends until it has determined the intended 
>> >> >> answer SDP to the offer.
>> >> >>
>> >> >> - once the intended answer SDP is determined, it MUST be sent in a 
>> >> >> reliable response to the INVITE. It MAY be sent in one or more
>> >> >> *preceding* unreliable provisional responses.
>> >> >>
>> >> >> Non-normative, best practice suggestions:
>> >> >>
>> >> >> - if the UAS receives an offer in the invite, once it has sent the 
>> >> >> answer in a reliable response, it should not send any SDP in 
>> >> >> subsequent responses to the INVITE.
_______________________________________________
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

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux