This is the reason we do clarifications - different people read the same
normative text and come to different conclusions about what the required
behavior is.
Paul
Valentin Nechayev wrote:
>>>>>> I??aki Baz Castillo <[EMAIL PROTECTED]> wrote:
>
>>> I propose another interpretation. As soon as Contact is supposed
>>> to change remote target of message receiver, and as soon as there
>>> is some initially assigned remote target when INVITE is set
>> Could you explain what you mean with "and as soon as there is some
>> initially assigned remote target when INVITE is set"?
>> How can be the remote target assigned just when sending the INVITE???
>
> Dialog data in UA contains remote target. (See section 12 for details.)
> RFC3261 doesn't declare (AFAIK) its initial value, but it declares
> - remote target shall be set to contact value of response
> - remote target shall be used for RURI of next requests within
> dialog (except case of strict routing - but this is corner case)
> It doesn't limit implementation, but the only implementation which
> conforms common sense is that when UA (as UAC) sends initial
> INVITE, remote target in the UA state is already assigned to the
> value sent in RURI. Having the remote target unassigned until
> first response with contact is IMO senseless - particularly,
> because there is no strong rule to carry contact in each response.
>
>>> For finishing of early dialog, I suppose you should extract contact if it is
>>> sent in response, and avoid to change remote target otherwise.
>> I really can't understand it. The "remote" target is the received
>> "Contact", so if there is not received "Contact" during 1XX responses,
>> then there is no remote target and in-dialog requests are not possible
>> from UAC to UAS. Am I wrong?
>
> See above. To clarify: this is kind of proof "by the rule of
> contraries": supposing that the remote target is initially
> unassigned you fall in contradiction with section 20.
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
