Peter,
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.
More below
Peter Schneider wrote:
> Hello all,
>
> I have a question concerning the interoperability of
> the SDP Offer/Answer Model from RFC 3264 with
> the old SIP RFC 2543:
>
> The scenario in question is as follows:
>
> UA 1 implements RFC 3261 and 3264
> UA 2 implements the old RFC 2543
>
> 1) UA 1 and UA 2 establish a call with one
> media stream
>
> 2) UA 1 puts the media stream on hold
> by marking the stream as "sendonly".
>
> 3) UA 2 answers but the answer does not
> include any direction attribute
>
> In my understanding, according to RFC 3264,
> section 5.1, end of first paragraph:
>
> ------------------------------------------------------------------
> If the offerer wishes to both send and
> receive media with its peer, it MAY include an "a=sendrecv"
> attribute, or it MAY omit it, since sendrecv is the default.
> ------------------------------------------------------------------
>
> a missing direction attribute has to be
> interpreted as "sendrecv".
>
> However, this would mean that the answer from UA 2
> violates RFC 3264, section 6.1, second paragraph:
>
> ------------------------------------------------------------------
> If a stream is offered as sendonly, the corresponding stream MUST be
> marked as recvonly or inactive in the answer
> ------------------------------------------------------------------
>
>
> Does that mean that the new and old Offer/Answer Model
> are not interoperable with respect to putting a stream on hold?
>
> If so, what is the recommended approach to deal with this?
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.
Paul
> Or is this rather a bug in UA 2 because it should(?)
> leave all unknown SDP lines untouched?
>
> Thanks in advance!
>
> Regards,
> Peter
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
