Michael Hirschbichler wrote:
> Thx, I got it :)
>
> 2nd question in this context: If in an INVITE-request an "Allow: PRACK,
> ..."-Header is set, am I correct in the assumption, that there must be a
> "supported: 100rel"-Header too?
Logically they are distinct. So "in principle" you could support PRACK
and not 100rel or visa versa. But it would be silly to do so because one
is not usable without the other.
And then there is UPDATE, which is also distinct. In principle you can
support 100rel and PRACK, but not UPDATE. But in practice both are used
for early o/a support. Often (though not always) those using 100rel will
expect to do multiple o/a before the INVITE completes. And its likely
that UPDATE will be required for that.
So 100rel, PRACK, and UPDATE are really a package that ought to be
implemented as a group.
Thanks,
Paul
> br
> Michael
>
> Am 06.05.2010 15:45, schrieb Paul Kyzivat:
>>
>> Michael Hirschbichler wrote:
>>> Hi all,
>>>
>>> we are currently discussing if it is possible (and - esp. - allowed)
>>> to set both, a "Require:"- and a "Supported:"-Header with the
>>> "100rel"-option in the same INVITE-Request. In my opinion, if 100rel
>>> is set in the "Require:"-header, it is implicitely also supported and
>>> should not explicitely set in the "Supported:"-header.
>>> Is this assumption correct? How should a UAS react, if this option is
>>> set twice (*Supported:* and *Required*)?
>> Supported says what *you* support.
>> Require says what you expect the *other guy* to support.
>> One does not imply the other.
>>
>> In the case of 100rel, matching behavior is required on both sides.
>> If you send a Require:100rel in an INVITE, the UAS will probably
>> eventually send a reliable provisional, and it will contain
>> Require:100rel. So it would be unwise of you to send Require:100rel if
>> you don't also support it. You aren't strictly required to send
>> Supported:100rel, but if you include a Supported header and it doesn't
>> include 100rel, then the other guy is likely to conclude that you don't
>> support it.
>>
>> Thanks,
>> Paul
>
> _______________________________________________
> 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
