Harsha. R wrote:
> ... they just refer to the fact that Tables 1 and 2 in rfc3262 extend
> tables 2 and 3 in rfc3261 and the Contact is marked as optional in 1xx
> responses. If 3262 clearly stated that reliable provisional responses
> MUST have Contact - we would not have this issue
>
> Its not clear to me as to why the 18X is expecting a Contact. The purpose of
> Contact is to do a target refresh.
> 18X missing a Contact header means a target refresh has not happened. In
> this case, address the PRACK to
> the original remote target( mostly the one used for INVITE).
We have had to incorporate this behavior into some of our products in
order to get them to interoperate with some broken implementations. But
as Iñaki has already stated, this has many issues and is not conforming
behavior.
Once the dialog has been established, with a target URI from a Contact,
then you may omit the contact from future 1xxs if you wish.
Too much is being made of the tables. Several of the people who
initially put those tables in now wish they had not. The tables are
insufficient to cover all the nuances. You *must* read the text to get
the details. Iñaki has already cited the various sections which, taken
together, mean that you MUST include a Contact to establish a dialog.
Paul
> If all goes well, PRACK reaches the intended UAS and call goes through;
> if not, UAS will retransmit 18X (missing contact header) and your UAC will
> keep sending
> PRACK to the latest remote target(mostly the one used in INVITE).
> After some time, UAS will take down the call on an implementation defined
> timer expiry for 18x
>
> Regards
> Harsha
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
