Hi,
On P , 2015-05-11 at 12:09 +0200, Harald Radke wrote:
> given a UA receives an SDP offer in a resonse (e.g. the 200 OK of its
> previous INVITE), and realizes it has no means of dealing with the
> offered media (e.g. one medai entry with a single codec description
> which is not compatible with the one of the receiving UA). RFC 6337
> state that:
>
> "When a UA receives a response with an offer that it cannot accept,
> the UA does not have a way to reject it explicitly. Therefore, a UA
> should respond to the offer with the correct session description and
> rearrange the session parameters by initiating a new offer/answer
> exchange, or alternatively terminate the session"
>
> What does "correct" session description mean in this context?
>
> 1- the SDP the UA would be able to accept (basically like sending an
> offer?
> 2- an answer according to RFC3264, where the media entry has a RTP
> port of 0 indicating that the media is not accepted?
RFC 3264 requires the port to be set to 0 if the media cannot be
accepted, which corresponds to the second option.
However, SDP does not allow the format list to be empty (which would be
the best option e.g. if the media type itself is not recognized), and
RFC 3264 is not very clear on what it's contents should be if the media
is rejected. It states that the media line "MUST contain at least one
codec the answerer is willing to send / receive, from amongst those
listed in the offer," but that is obviously impossible when there are no
common codecs. On the other hand, it allows the answerer to include
additional formats it is willing to send and / or receive.
Given that, I would set the port to 0 as required, but construct the
format list as if sending an offer. IMHO it carries the intended
meaning ("no common codecs") better than just setting the port to 0,
which could be interpreted as "I support the offered codecs but do not
wish to communicate using this media type."
Of course, if the media type is not supported at all, the only option is
to just set the port to 0.
Best,
Jānis
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
