Dear Magnus, Thanks for your reply. You misunderstood my proposal, but raised a couple of very valid points and kind of involuntarily suggested alternatives worth considering. To explain my proposal once more: A single mcp parameters reflect both sending and receiving capabilities. Obviously, there are not enough values to reflect all conceivable combinations, but I hope the semantics I propoose are enough to cover the realistic scenarios. The behavior of an IP AMR device would be as follows: * When sending SDP offer, indicate fcp 2 if capable of sending (and receiving) fcp 2. * When receiving SDP offer with fcb 2, answer with fcb 2 if capable of sending (and receiving) fcp 2. * When receiving SDP offer with fcb 2, answer with fcb 1 if not capable of sending (or receiving) fcp 2. * When receiving SDP offer with fcb 1, answer with fcb 1 * Fcb 1 must be supported for sending and receiving I include callflows to show how this works in realsistic scenarios and explain my ideas further. There may be variants to this idea, e.g. assigning mcp values that directly correspond to the 3GPP codecs AMR, AMR2 and AMR FR, but I did not analyse that completly. So the details of the semantics of the MCP values and the UE behavior could slightly be changed. But from playing around with all these scenarios I got convinced that if we want to do with one mcp parameter only and get a reasonable interworking behavior, + the mcp parameter has to do something both with sending and receiving capabilities. + The SDP answerer needs to select the mcp parameter in the answer depending on what was received in the offer and its own capabilities. Pleas find answers to your proposals further down. Cheers, Thomas -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Thursday, April 29, 2004 2:14 PM To: Belling Thomas Cc: avt@ietf.org Subject: 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. [Thomas] Having separate parameters for sending and receiving capabilities would be cleanest way to express the real situation. It is certainly worth considering. I also had concerns with backward compatibility, this is why I did not propose it myself. However, accepting the fact that the mcp parameter is ill-defined in the current RFC and the reaction of a terminal receiving an SDP offer with e.g. "mcp=2" is hardly predictable, perhaps there is not so much difference. There is a fair chance that the terminal would reject the codec, no matter if mcp=2 or a new parameter is encountered in the SDP. Perhaps the best thing we can do is to get a bis draft qickly in the hope that not many unpredictable legacy devices will be deploid. 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. [Thomas] One could apply similar rules as for the codec negotiation. The answerer select from the choices given by the offerer, and list the choices from the offer that match his capabilities. This can be done by expressing all capabilities explicitley in the sending and receiving parameters (for receiving, mcp 1 implies everything is supported. For sending, you would probably require a list, perhaps in order of preference). Alternativly, you may include the same codec with different configurations several times in the codec list. 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. [Thomas] OK 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. [Thomas] Certainly worth considering. Perhaps the best backward compatibility mechanism is to add the codec without the mcp parameter as less prefered alternative. 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. [Thomas] Perfectly valid. There is no standardized solution for SIP or within the IMS to insert a transcoder. This needs to be done at the transit point between SIP and PSTN/GSM. There is a clear requirement that the solution works without transcoding for an IP to IP call with IP terminals with realistic capabilities (I assume that such terminals will support receiving any mcp, but may either be capable to send only mcp 1, or mcp 1 and 2). 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. [Thomas] Here I have problems to follow. This may be due to misunderstandings about the proposed 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
Attachment:
frame change periods.doc
Description: application/winword6