Rakesh,
See comments below.
On 9/7/17 11:43 AM, Rakesh wrote:
*Hi ,*
*Can any one tell me what will be the codec can be sent on 200OK in below ?*
*Is this the one that support by UE or the Supported codec by Proxy ?*
*UA Proxy
*>>* ----------------------------------------->
*>>* (INVITE SDP: codecs 0 18 101)
*>>>>* <------------------------------------------
*>>* (200 OK SDP: codecs 0 101)
*>>>>* -------------------------------------------->
*>>* ACK (no SDP)
*>>>>>>* <-------------------------------------------
*>>* (re-INVITE no SDP)
*>>>>* ---------------------------------------------->
*>>
* (200 OK SDP: codecs ?????)*
*As per RFC,**RFC 6337 section 5.2.5:
*>>* "When the new offer is sent in response to an offerless (re-)INVITE, it
*>* should be constructed according to the General Principle for Constructing
*>* Offers and Answers (Section 5.1 ): all codecs the UA is currently willing
*>* and able to use should be included, not just the ones that were negotiated
*>* by previous offer/answer exchanges. The same is true for media types --
*>* so if UA A initially offered audio and video to UA B, and they end up with
*>* only audio, and UA B sends an offerless (re-)INVITE to UA A, A's resulting
*>* offer should most likely re-attempt video, by reusing the zeroed "m=" line
*>
* used previously."*
*SO I didn't able to understand this "*
*all codecs the UA is currently willing
and able to use should be included, not just the ones that were negotiated
by previous offer/answer exchanges."*
What don't you understand?
In the above scenario from 6337, the most likely behavior would be for B
to include whatever it would normally include in an initial offer in a
new call. But this has to be tempered a bit by the constraints that
apply to subsequent offers in a dialog.
The verbiage about "currently willing and able to use" is to acknowledge
ability and willingness to use particular media may vary with time and
be based on interaction with the user of the device. When responding to
an initial invite the UAS can delay generating the offer or answer while
alerting, and the UI might give the user ability to indicate if he wants
to use video, etc. But in the offerless reinvite case there isn't any
opportunity to do that, so the UAS must decide what to include based on
policy. In the case of a video phone with a dedicated display and camera
it may be safe to always include video. But if the UAS is a computer
with a camera that is shared by many applications, if the camera isn't
already assigned to the phone app then video probably can't be used in
the offer.
In your initial example, the callee (B) initially accepted the codecs
associated with PTs 0 and 101, so I would expect that at a minimum those
would be included. Presumably B doesn't support codec 18, so that
wouldn't be included in the new offer. If there are any *other* codecs
that it does support it could include them in the new offer too. (B
*could* have also included those in its initial answer, but that doesn't
seem to be a common behavior.)
I assume your example is only audio. If B also supports video, and is
willing to start using it mid-call it could also include that in the new
offer.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
