[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] The need for Offer/Answer sections in RTP payload forma t specifications
Hi Thomas,
see comments inline:
Belling Thomas wrote:
Thus in this scenario the GSM GW has put a requirement on the IP
terminal sending to only change modes every two frames.
[Thomas] Exactly. My point is that I suspect that many IP terminals
> will not be capable to fulfill this requirement. A call failure
> would result.
I can't do much against implementations not supporting the flag. The
only thing possible is to clarify the requirement on understanding and
support this functionality.
[Thomas] Forget about everything but mcp 1 and 2. The problem is
> GSM specific, where a mcp 2 applies both for sending and receiving
> because the modes indicated with every frame at the radio interface
> refer to uplink and downlink in an alternating manner. In am not
> are of any other scenarios where anything but mcp1 would be
encountered for sending and receiving, except when interworking to
> GSM is involved.
Okay.
Specifying a symmetric negotiation instead of declaration will not help
the situation at all, it will only force the parties to reject a call
when it doesn't match. If one uses declaration style each of the
end-point can make a decision between the cases.
1. Determine that it will work fine and match the super period between
both end systems limitations.
2. Try to fulfil them after best possibilities and if it fails let the
receiver discard the frames.
3. Try to restrain it self from switching.
4. Determine that the setup will not work, and then reject the call.
[Thomas] I was not suggesting a symmetric negotiation either:
My idea is: the offerer expresses what he wants to receive, and
> is also capable of sending(e.g. mcp 2 for GSM). If the answerer is
> capable to support this value for sending and receiving, it shall
> apply this value and otherwise reply with a mcp it is capable of
> supporting (e.g. mcp 1 for my simple IP terminal).
When receiving an answer with an other mcp than in the offer,
> the offerer has the choice to transcode or to abort the call
> (e.g. in my scenario: the interworking node transcodes in this
> situation)
So what you are proposing is that we create one more parameter that
declares what MCP an entity is capable of sending. This is possible,
however one will need to consider backwards compatibility.
So the gain by this, is that both parties will know what MCP that is
desired, and what what each is capable of sending. However an answerer
detecting a mismatch will not reject the session, only declare it to the
offerer as a mismatch. If that offerer is not capable of understanding
this, the session will go one and the error will occur when the answerer
tries to transmit to the offerer.
If the offerer understands the mismatch it has the choice of invoking
local capabilities to handle this. To my understanding it will not the
be receiver that invokes a transcoder, because if that is available,
there is no reason for the receiver to declare MCP at all. Or is this a
wrong assumption from my side? In that case I don't see that the
capabilities declaration gives you any advantage.
Also if you are a receiver capable of handling transcoding, then you can
use two payload types to declare a more desirable payload type with MCP
and a less without MCP. If one also does this with a 1 out of N
selection, then the offerer can eliminate the payload type if not
necessary.
Also not being up to speed on the SIP transcoder invocation work, I have
no idea how this interacts with that work. My main concern is how you
detect that you need a transcoder.
So I am still a bit uncertain of the necessity of this. My conclusion is
that your proposed mechanism will only help if the transcoding operation
is on the receiver side. Further it is only advantage if one are not
interested in declaring it as a capability at the time of doing the
Offer/Answer exchange, but rather something that is invoked as a last
effort to make things work. As it also results in a backwards
compatibility error case I am doubtful to the solution.
Please comment
Magnus
--
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt