Gonzalo,
comment inline.
>> If re-INVITE rejected, I think, it doesn't influence the remote
>> target.
>
>see the reference to RFC 3261 in the draft regarding atomicity.
A B
INVITE/200/ACK <----------------->
Contact: A1
reINVITE/18x <----------------->
Contact: A2
UPDATE/200 <----------------->
Contact: A3
4xx/ACK <----------------->
You say that A's Contact(local target) is rolled back to A1.
Is this right?
>> But I think that "the UAC *can* revert" need to send an
>> UPDATE request too.
>
>yes, it is probably a good idea to send an UPDATE anyway to make sure
>both ends are in synch. We may want to add that to the draft.
>
>>> No, the semantics of an m line without preconditions are clear in SDP.
>>> It means that the stream is established. This is what all UAs without
>>> support for preconditions continuously do.
>>
>> Does RFC3312 or 4566 says that ?
>> Give me the pointer of the semantics, please.
>
>Read the SDP spec and the offer/answer specs (nothing related to
>preconditions) and see what they way about m lines.
RFC3312
5.1 Generating an offer
With the transaction status table, the user agent MUST generate the
current-status and the desired status lines, following the syntax of
Section 4 and the rules described below in Section 5.1.1.
5.2 Generating an Answer
between two consecutive offer/answer exchanges. Therefore, both user
agents MUST keep their local status tables up to date, using local
information throughout the duration of the session.
Therefore, I think that "removing the precondition" is not allowed.
Is this wrong?
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
