Christer,
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.
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
