Subject: Re: [AVT] The interworking issue for RTP Payload Format for AMR

From: Magnus Westerlund <[email-masked]>
Date: Tue, 02 Nov 2010 10:12:42 +0100

Hi,

My understanding of this is that the gateway between RTP and TRAU do
need to keep track of the phase of the TRAU frames it emits, so that it
keeps to the CMI, CMR structure correctly. When it comes to set CMR set
it to the latest received value. Thus, either when your CMR=4 arrives it
is in time for the next CMR sending turn, or if not and the next RTP
packet arrives with CMR=1, then that newer value takes precedence. So
the answer is keep track of the latest received in the GW and then send
it at the all possible opportunities on the TRAU side.

And frankly, I don't think this belongs in the AMR RTP payload spec. It
belongs in the spec that defines the AMR RTP <-> TRAU interworking. AMR
RTP payload format can't specify all possible considerations for other
formats for carryin AMR frames. AMR has taken into considerations the
issues that affects the encoding of the AMR frames, like
mode-change-period, so that interworking is possible. But the gateway is
likely to be forced to keep some state.

Cheers

Magnus

Xie Lei skrev 2010-10-26 08:04:
> Hi
> Yes, the TRAU can only take either CMR or CMI, and in GSM network, TRAU
> frame sequence must strictly be one CMR frame following with one CMI
> frame , however, RFC4867 allows take both CMR and CMI one packet and
> there is no indication to indentify the packet is CMR frame or not, that
> makes the problem.
>  
> BR
> Rock
> 
>     ----- Original Message -----
>     *From:* Roni Even <mailto:[email-masked]>
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Cc:* 'Xie Lei' <mailto:[email-masked]>
>     *Sent:* Tuesday, October 26, 2010 1:12 PM
>     *Subject:* FW: [AVT]The interworking issue for RTP Payload Format
>     for AMR
> 
>     Hi,
> 
>     I assume that the problem is because in TRAU you can send either CMR
>     or CMI while RFC4867 allows both in the same packet. Is this correct?
> 
>     Roni Even
> 
>      
> 
>     *From:*Xie Lei [mailto:[email-masked]]
>     *Sent:* Monday, October 25, 2010 9:14 AM
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Cc:* [email-masked]
>     <mailto:[email-masked]>; 'Roni Even'
>     *Subject:* [AVT]The interworking issue for RTP Payload Format for AMR
> 
>      
> 
>     Hello All
> 
>     I work on one interworking task between AMR RTP Payload and TRAU
>     frame in TDM network, and find it is very difficult to map the
>     Codec_Mode_Request(CMR) value in RTP to Requestor Indication
>     Flag(RIF) in TRAU frame which is defined in3GPP 48.060/48.061.
> 
>     As defined in RFC4867, RTP frame can take CMR and CMI(FT field) both
>     in payload and the codec mode change period could be 20ms.
>     However,TRAU speech frame can only take one of CMR or CMI, and the
>     RIF should follow rigorous mode change peroid, that means, TRAU
>     speech framecould only take CMR every 40ms and between each CMR
>     frame, the TRAU speech frame must be CMI frame.
> 
>     The issue happens when two consequent RTP payload takeing valide CMR
>     value in each payload, at this scenario, we do not know how to set
>     the RIF value. For instance, the first RTP payload takes CMR=4, and
>     we map this CMR value to RIF flag to indicate the TRAU speech
>     frameis for CMR, and the second RTP payload comes with CMR=1, then
>     we really do not know how to do now. according to the RTP payload
>     CMR valude, we should indicate RIF as CMR. However, according to the
>     TRAU frame definition, the RIF must be CMI which following with last
>     CMR frame.
> 
>     RFC4867 has some decription on reqirements for encoder in GSM.
>     However, it is not enough, i think there needs some description
>     on how to map CMR and CMI value in RTP frame to RIF defined TRAU
>     when interworking between IP and TDM network. currentlly , we can
>     not find such mapping table in any specification. We hope avt groud
>     could work on this and resolve this issue.
> 
>      
> 
>     Best Regards
> 
>     Rock
> 
>      
> 
>      
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Xie Lei <[email-masked]>
Date: Fri, 05 Nov 2010 12:06:45 +0800

Hi Magnus

Thanks very much for your letter. i have different idea with your opinion on this issue. 
In RFC4867 3.9 section, there describes an senario  "that IP/UDP/RTP is used as transport between two non-IP systems ", the following red words is for this scenario:
 
 This scenario requires the same mechanisms for preserving UED/UEP and
   CMR information as in the single gateway scenario.  In addition, the
   CMR value may be set in packets received by the gateways on the IP
   network side.  The gateway should forward to the non-IP side a CMR
   value that is the minimum of three values:

      -  the CMR value it receives on the IP side;

      -  the CMR value it calculates based on its reception quality on
         the non-IP side; and

      -  a CMR value it may choose for congestion control of
         transmission on the IP side.

Here we just want to consider more about non-ip side's phase status, such as Trau speech frame in GSM network Abis interface. Therefore, i think this problem should be considered in RFC4867.

As for the gateway keeping track of the phase of TRAU frames, i think there are still some issues:
1: The RFC4867 defines that " if a terminal has no preference in which mode to receive, it SHOULD set CMR=15 in all its outbound payloads", if the GW receives CMR=15 continually, how to fill the CMR with the latest receive CMR value from IP side, this scenario may happen when MGW has no preference on CMR codec rate and send the RTP message with CMR=15 to BSC continually.
2:Normaly, the GW  entity for tranfering RTP to TRAU is BSC, and there is no specification to define BSC on keeping track of the phase of TRAU frames.

i suggest that we could have a meeting in this IETF beijing meeting, do you have time on monday noon just before the AVT meeting?

BR
Rock

  ----- Original Message ----- 
  From: Magnus Westerlund 
  To: Xie Lei 
  Cc: Roni Even ; [email-masked] 
  Sent: Tuesday, November 02, 2010 5:12 PM
  Subject: Re: [AVT] The interworking issue for RTP Payload Format for AMR

  Hi,

  Cheers

  Magnus

  -- 

  Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Sat, 06 Nov 2010 16:35:16 +0800

Xie Lei skrev 2010-11-05 12:06:
> In RFC4867 3.9 section, there describes an senario  "that IP/UDP/RTP is
> used as transport between two non-IP systems ", the following red
> words is for this scenario:
>  
> Here we just want to consider more about non-ip side's phase status,
> such as Trau speech frame in GSM network Abis interface. Therefore, i
> think this problem should be considered in RFC4867.
>  
> 1: The RFC4867 defines that " if a terminal has no preference in which
> mode to receive, it SHOULD set CMR=15 in all its outbound payloads", if
> the GW receives CMR=15 continually, how to fill the CMR with the latest
> receive CMR value from IP side, this scenario may happen when MGW has no
> preference on CMR codec rate and send the RTP message with CMR=15 to BSC
> continually.

So are we talking in the case of A ->(IP/UDP/RTP) -> GW ->(Abis) ->
B(Mobile client)? And A sets CMR to 15. I don't know what requirements
Abis has on setting its CMR field. If it can't be using 15 in its CMR
field and the client has never set anything else, then a local decision
in the GW must be made. As this effects the voice quality and working of
the circuit switched voice it appears that this is something the 3GPP
should discuss on how to set. If you set it to 12.2 mode, or an operator
default or something else.

I don't find it reasonable that IETF should make this service dependent
choice.

> 2:Normaly, the GW  entity for tranfering RTP to TRAU is BSC, and there
> is no specification to define BSC on keeping track of the phase of TRAU
> frames.

I still think it is 3GPP problem as they have introduced service usages
that include gatewaying between circuit switched and IP based transport.
Yes, we enabled it in the AMR mode by explicitly defining certain
behaviors that needs to be kept across the IP side. But how you deal
with specific limitations of the 3GPP defined interfaces on when CMI and
CMR can be sent is not affecting the IP side, only the GW.

>  
> i suggest that we could have a meeting in this IETF beijing meeting, do
> you have time on monday noon just before the AVT meeting?

Sure, we can discuss this. Do you want to meet 15 min before the
session. Or doing lunch?

Cheers

Magnus Westerlund

---

From: XieLei 57471 <[email-masked]>
Date: Mon, 08 Nov 2010 10:07:55 +0800

hi 
I send it again in case of mailing list loseing this email.

BR
Rock

----- 原邮件 -----
发件人: XieLei 57471 <[email-masked]>
日期: 星期日, 十一月 7日, 2010 下午3:08
主题: 回复:Re: [AVT] The interworking issue for RTP  Payload Format for AMR
收件人: Magnus Westerlund <[email-masked]>
抄送: "[email-masked]" <[email-masked]>,Roni Even <[email-masked]>

> Hi Magnus
> Thanks for your quick response. I think the generic reason for this 
> issue is that AMR RTP format could include valid CMR and CMI at the 
> same time and Trau frame could only include one for speech frame 
> and should follow restrict sequence.We can not simply push it to 
> 3GPP because IETF also considered this scenario when defining the 
> AMR RTP format and this issue could be resolved  with specific CMR 
> generating rule in IP side . i hope we can di
> scuss this issue and try to resolve it in RFC4867.
> Monday lunch maybe a good time to discuss this issue, we can meet 
> at the registration desk at 11:40.
> 
> BR
> Rock
> 
*****************************************************************************************
> ----- 原邮件 -----
> 发件人: Magnus Westerlund <[email-masked]>
> 日期: 星期六, 十一月 6日, 2010 下午4:35
> 主题: Re: [AVT] The interworking issue for RTP Payload Format for AMR
> 收件人: Xie Lei <[email-masked]>
> 抄送: "[email-masked]" <[email-masked]>, Roni Even <[email-masked]>
> 
> > >    network side.  The gateway should forward to the non-IP side 
> a 
> > CMR>    value that is the minimum of three values:
> > > 
> > > Here we just want to consider more about non-ip side's phase 
> status,> > such as Trau speech frame in GSM network Abis interface. 
> > Therefore, i
> > > As for the gateway keeping track of the phase of TRAU frames, i 
> > think> there are still some issues:
> > > 1: The RFC4867 defines that " if a terminal has no preference 
> in 
> > which> mode to receive, it SHOULD set CMR=15 in all its outbound 
> > payloads", if
> > > the GW receives CMR=15 continually, how to fill the CMR with 
> the 
> > latest> receive CMR value from IP side, this scenario may happen 
> > when MGW has no
> > > preference on CMR codec rate and send the RTP message with 
> CMR=15 
> > to BSC
> > > continually.
> > 
> > B(Mobile client)? And A sets CMR to 15. I don't know what 
> requirements> Abis has on setting its CMR field. If it can't be 
> using 15 in its CMR
> > field and the client has never set anything else, then a local 
> > decisionin the GW must be made. As this effects the voice quality 
> > and working of
> > the circuit switched voice it appears that this is something the 
> 3GPP> should discuss on how to set. If you set it to 12.2 mode, or 
> an 
> > operatordefault or something else.
> > 
> > I don't find it reasonable that IETF should make this service 
> > dependentchoice.
> > 
> > > 2:Normaly, the GW  entity for tranfering RTP to TRAU is BSC, 
> and 
> > there> is no specification to define BSC on keeping track of the 
> > phase of TRAU
> > > frames.
> > 
> > I still think it is 3GPP problem as they have introduced service 
> > usagesthat include gatewaying between circuit switched and IP 
> based 
> > transport.Yes, we enabled it in the AMR mode by explicitly 
> defining 
> > certainbehaviors that needs to be kept across the IP side. But 
> how 
> > you deal
> > ------------------------------------------------------------------
> --
> > --
> > ------------------------------------------------------------------
> --
> > --
> > F?r?gatan 6                | Mobile +46 73 0949079
> > ------------------------------------------------------------------
> --
> > --
> > 
>