On 8/2/16 4:04 PM, Pavan Pandey wrote:
Hi All,
In the below mentioned scenario, UA supports advanced Video, AVPF and SAVPF
features.
UAC1 initiates an audio call with UA and subsequently sends reINVITE without
sdp.
As per RFC 6337 section 5.1 understanding, UA should make an offer with all the
media capabilities.
In step 4, we could potentially see one heavy offer from UA to UAC1 in reINVITE
200 OK. If UA supports text, image etc, it would get even bulkier.
UAC1----------------------------------------------------------------------------------------------------------------------------------UA
1)---------------------INVITE (audio
AVP)-------------------------------------------------------------------------------------------->
2)<---------------------200-OK(audio
AVP)---------------------------------------------------------------------------------------------
3)-------------------------------ACK----------------------------------------------------------------------------------------------------
4)<---------------------reINVITE
(withoutsdp)--------------------------------------------------------------------------------------------
5)---------------------200-OK(audio AVP + audio AVPF + video AVP + video AVPF +
audio SAVP + video SAVP + audio SAVPF + video SAVPF)--->
6)<---------------------------ACK
()---------------------------------------------------------------------------------------------------
Is it okay to just send all the media capabilities of just the negotiated media
stream in step 5? Just offer all the media capabilities for the negotiated
media stream(s).
I wrote that section of 6337.
You *may* do anything you want. But keep in mind the consequences of
doing so.
In this case, in (1) UAC1 only offered audio, but you say it is capable
of much more. Why didn't it offer more then? If the reasons for limiting
to audio remain, then go ahead and only offer audio in (5).
A good rule of thumb is to offer the same as you would if you were
sending a new INVITE at this time. The key is not to limit what you
offer based on assumptions about what you think the other party might
want. The evidence you have from the prior O/A is incomplete, and there
is no assurance that you are still talking to the same device. The
reINVITE might be part of a 3pcc transfer to an entirely new device with
different capabilities.
For instance, suppose in (1) you had offered codecs A and B, and the
answer had selected only A. Then you get the offerless reinvite, and it
is a result of a 3pcc transfer to a device that only supports codec B.
If you only offer codec A, then you won't be able to connect to the new
device, even though you could have. This sort of case can happen when
calling a PBX with an automatic answering service.
Thanks,
Paul
5)---------------------200-OK(audio AVP with all the media formats and the
capabilities)--->
5.1<https://tools.ietf.org/html/rfc6337#section-5.1>. General Principle for
Constructing Offers and Answers
A UA should send an offer that indicates what it, and its user, are
interested in using/doing at that time, without regard for what the
other party in the call may have indicated previously. This is the
case even when the offer is sent in response to an INVITE or re-
INVITE that contains no offer. (However, in the case of re-INVITE,
the constraints of [RFC3261<https://tools.ietf.org/html/rfc3261>] and
[RFC3264<https://tools.ietf.org/html/rfc3264>] must be observed.)
A UA should send an answer that includes as close an approximation to
what the UA and its user are interested in doing at that time, while
remaining consistent with the offer/answer rules of
[RFC3264<https://tools.ietf.org/html/rfc3264>] and
other RFCs.
NOTE: "at that time" is important. The device may permit the user
to configure which supported media are to be used by default.
In some cases, a UA may not have direct knowledge of what it is
interested in doing at a particular time. If it is an intermediary,
it may be able to delegate the decision. In the worst case, it may
apply a default, such as assuming it wants to use all of its
capabilities.
Thanks and Regards,
Pavan
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
