Peter Schneider wrote:
> Hello Paul,
>
>> I guess it depends on what you mean by interoperability. None of the
>> directionality stuff was in 2543, so you can't expect something
>> operating by 2543 rules to do that.
>
> The definition of interoperability I had in mind in the context of SIP
> was just something like this:
>
> Two UAs are interoperable if they are able to operate together successfully
> in the most important scenarios, e.g. establishing a call, ending a call,
> putting an established call on hold.
Well, "putting an established call on hold" wasn't considered to be one
of the most important scenarios. I believe this was fundamentally
because changing the technique fixed problems that seemed to justify the
incompatibility.
> As far as I know, 3261 was specified in a way such that
> 3261 and 2543 UAs are interoperable, at least when only
> the basic SIP signalling scenarios are considered.
> So I expected that this would also be the case for
> the SDP and Offer/Answer related aspects.
>
>> ...
>> I don't believe a strategy for this is written anywhere.
>>
>> To make this work, UA1 needs to recognize that the absence of any
>> explicit directionality in the answer is a hint that UA2 doesn't support
>> this.
>>
>> In that case UA1 need to go the extra mile and do its hold according to
>> 2543 rules - using c=0.0.0.0 in another offer.
>
> This is what I was afraid of. So we really have to resort to
> hints or guesses and add extra complexity to a UA based on
> 3261 in order to be interoperable with a 2354 based UA?
>
> At least it seems to me as if there would have been some options
> to avoid this, e.g. by using a different version number
> or maybe just by avoiding the "since sendrecv is the default" clause
> in 3264.
Changing the default would not change anything.
Putting in options would simply provide a way to make the hold request
fail rather than succeeding without doing the hold. This would give no
advantage over what it does.
As defined, the offerer can tell that the answerer is non-compliant to
3261. This can be viewed as an error, and the call torn down, if
desired. Or it can be viewed as a hint to try the 2543 way. Or the
offerer can just go on and deal with the hold having not worked. I don't
know what else could have been done that would have produced a better
set of possible results.
> Do you know whether most 3261 based UAs really do something
> similar to what you suggested or do you rather think that most
> 3261 UAs don't try to be interoperable with 2543 UAs (at all)?
Its been a long time since 3261 came out. Its my impression that most
support at least this part of it. I don't know how many support the
fallback. Maybe somebody with experience at SIPit can comment.
Paul
> Thanks in advance for any further help!
>
> Regards,
> Peter
>
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
