Subject: [MMUSIC] draft-ietf-mmusic-media-loopback-13 questions

From: "Kumar, Satish" <[email-masked]>
Date: Thu, 29 Apr 2010 07:06:12 -0500

Hi All,

This draft (draft-ietf-mmusic-media-loopback-13)is used in several VoIP deployments partially. Some deployments mandate this draft fully. I have couple of questions.

1. Loopback will be good to ensure the path is still valid and every one is alive. You can use the direct loopback to get that information. It is still not clear how the RTP encapsulation mode will be used. Is there some benefit in encapsulation or is this something that was put into a draft because it sounds like a good thing to do?

2. Does these loopback apply to RTCP as well?

Appreciate your reply.

-Satish

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Apr 2010 11:52:42 -0400

Satish,

> 1. Loopback will be good to ensure the path is still valid and every
> one is alive. You can use the direct loopback to get that information.
> It is still not clear how the RTP encapsulation mode will be used. Is
> there some benefit in encapsulation or is this something that was put
> into a draft because it sounds like a good thing to do?

I don't know who asked for encapsulation or why it was introduced later, but
I had no objection to it.  It seems somewhat useful when one really just
wants to mirror the contents of what is received back to the sender.  The
outermost RTP header serves to get the packets end-to-end while the inner
layer is a preservation of what was originally transmitted.

One issue I see, though, is that we have four modes of operation:

Direct/loopback-type-pkt 
Direct/loopback-type-media
Encapsulated/loopback-type-pkt 
Encapsulated/loopback-type-media

This seems a bit much, in my opinion.  But, over 6 years this kind of
feature creep occurs.  I'd be content to reduce this set :-)

> 2. Does these loopback apply to RTCP as well?

No.

Paul

---

From: "Kumar, Satish" <[email-masked]>
Date: Thu, 29 Apr 2010 14:20:02 -0500

Thanks Paul, While reviewing draft I found one example SDP just above sec-5.4. I have pasted here.

Example:       m=audio 41352 RTP/AVP 112
               a=loopback:rtp-pkt-loopback
               a=loopback-source:0 8
               a=rtpmap:112 encaprtp/8000
 
Example:       m=audio 41352 RTP/AVP 112
               a=loopback:rtp-pkt-loopback
               a=loopback-source:0 8
               a=rtpmap:112 rtploopback/8000
                      ^^^^^^^
First example here makes sense, since it is demands RTP encapsulation with payload type 112 be sent from device. 

Second example does not make sense. For RTP loop back why is PT 112 is specified? As per draft explanation, in loop back; device just reflects the packet back with same PT. Is my understanding correct?

-Satish

-----Original Message-----
From: Paul E. Jones [mailto:[email-masked]] 
Sent: Thursday, April 29, 2010 9:53 AM
To: Kumar, Satish; [email-masked]
Cc: [email-masked]
Subject: RE: draft-ietf-mmusic-media-loopback-13 questions

Satish,

Direct/loopback-type-pkt 

No.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Apr 2010 19:37:14 -0400

Satish,

> First example here makes sense, since it is demands RTP encapsulation
> with payload type 112 be sent from device.
> 
> Second example does not make sense. For RTP loop back why is PT 112 is
> specified? As per draft explanation, in loop back; device just reflects
> the packet back with same PT. Is my understanding correct?

That's spelled out in the paragraph above those examples.  112 is what the
offerer expects to receive, but that does not indicate what codec is to be
sent.  So, it just says "whatever media you send to me, use PT 112."

The loopback-source line indicates what it can send.

I would expect the answer to contain either 0 or 8 on the m= line.  The
offerer would then transmit media using PT 0, for example, and it would be
looped back with PT 112.

But, that seems to be at odds with the offer/answer model.  But, do we care?
Or perhaps I'm wrong.

In any case, the procedures do seem a bit unusual.  Why would the offerer
not just offer 0 or 8 on the m= line, indicate it's a loopback with the a=
line, and the answer reply indicating it acknowledged the loopback (with a
similar set of m= and a= lines)?  I don't know.  That's what we had in the
original draft 6 years ago... but things appear to have gotten a bit
complicated.

I think only Kaynam can enlighten us as to why things have changed as they
have, but likely it's a long story.

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Apr 2010 20:17:31 -0400

I'm trying to understand what is the o/a incompatibility you are 
struggling with.

Is it that 3264 requires the offer and the answer to have at least once 
format in common, while with your pkt loopback the formats are quite 
distinct in the two directions???

This is a limitation in the o/a model.

Once the o/a exchange is complete, if more than one format was 
negotiated there is no issue with *using* one of those in one direction 
and a different one in the other direction. So maybe the answer here is 
to always include both the "real" formats *and* the encapulated formats 
in both the offer and the answer, while using the loopback-source and 
loopback-mirror to determine who uses what.

	Thanks,
	Paul K

Paul E. Jones wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Apr 2010 21:37:09 -0400

This:

   For streams marked as sendrecv in the answer,
   the "m=" line MUST contain at least one codec the answerer is willing
   to both send and receive, from amongst those listed in the offer.

This stream is implicitly sendrecv.  The offer contains 112.  What does the
answer contain?

The draft says:
    However, the answer might indicate a different payload type number
    for the same codec.  In that case, the offerer MUST send the
    payload type received in the answer.

Thus, my concern.  Perhaps I'm misreading this... it's been a long week.

Paul

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, April 29, 2010 8:18 PM
> To: Paul E. Jones
> Cc: 'Kumar, Satish'; [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-13 questions
> 
> >> Thanks Paul, While reviewing draft I found one example SDP just
> above
> >> sec-5.4. I have pasted here.
> >>

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 30 Apr 2010 17:14:10 +0530

Paul,

|So maybe the answer here is to always include both the "real" formats 
|*and* the encapulated formats in both the offer and the answer, while 
|using the loopback-source and loopback-mirror to determine who uses
what.

Are you proposing something like this?

Offer:
    m=audio 49170 RTP/AVP 0 112
    a=loopback:rtp-pkt-loopback
    a=loopback-source
    a=rtpmap:0 pcum/8000
    a=rtpmap:112 encaprtp/8000

Answer:
    m=audio 49170 RTP/AVP 0 112
    a=loopback:rtp-pkt-loopback
    a=loopback-mirror
    a=rtpmap:0 pcum/8000
    a=rtpmap:112 encaprtp/8000

This looks good, except that I am wondering what will happen if the
answerer doesn't support media loopback and hence doesn't understand the
"encaprtp" encoding name. What will be the behavior if such an answerer
is:
1) UA
2) SBC

thanks,
Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of
|Paul Kyzivat (pkyzivat)
|Sent: Friday, April 30, 2010 5:48 AM
|To: Paul E. Jones
|Cc: [email-masked]; [email-masked]
|Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-13 questions
|
|I'm trying to understand what is the o/a incompatibility you are
|struggling with.
|
|Is it that 3264 requires the offer and the answer to have at least once
|format in common, while with your pkt loopback the formats are quite
|distinct in the two directions???
|
|This is a limitation in the o/a model.
|
|Once the o/a exchange is complete, if more than one format was
|negotiated there is no issue with *using* one of those in one direction
|and a different one in the other direction. So maybe the answer here is
|to always include both the "real" formats *and* the encapulated formats
|in both the offer and the answer, while using the loopback-source and
|loopback-mirror to determine who uses what.
|
|	Thanks,
|	Paul K

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Apr 2010 10:21:00 -0400

> Thus, my concern.  Perhaps I'm misreading this... it's been a long week.

To comply with the above, the answer needs to have a codec in common 
with the offer. The format number designating the codec can change, but 
the codec must be in common. For instance

Offer:
   m=audio 41352 RTP/AVP 112
   a=rtpmap:112 rtploopback/8000

Answer:
   m=audio 54321 RTP/AVP 115
   a=rtpmap:115 rtploopback/8000

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Apr 2010 10:27:15 -0400

> "encaprtp" encoding name. What will be the behavior if such an answerer

While putting both in "works" techically, it requires the mirror to lie 
by claiming it is willing to receive the encapsulated format when it is 
really only willing to send it.

A more o/a friendly way of doing this would be:

Offer:
   m=audio 41352 RTP/AVP 0 8
   a=loopback:source-out x
   m=audio 41354 RTP/AVP 112
   a=loopback:source-in x
   a=rtpmap:112 rtploopback/8000

Answer:
   m=audio 54312 RTP/AVP 8
   a=loopback:mirror-in x
   m=audio 54320 RTP/AVP 112
   a=loopback:mirror-out x
   a=rtpmap:112 rtploopback/8000

Above is just a thought off the top of my head, and carefully 
considered. There are many changes implied in the above compared to the 
current draft:

- a stream to be looped can be represented by two m-lines,
   one for the input side and one for the output side.

- there is no loopback-source/loopback-mirror

- a=loopback indicates:
   - the role of the message sender (source or mirror)
   - the direction of the stream (in/out)
   - an identifier used to pair the two streams

- There is no *explicit* distinction between packet and media
   loopback. Its implicit in the pairing of two streams and
   the formats that they contain. This pairing could also
   be used to request transcoding between regular formats.
   (Packet loopback can be viewed as just a special kind
   of transcoder.)

In the case of media loopback without transcoding, you typically won't 
need two m-lines. So in that case it gets simpler:

Offer:
   m=audio 41352 RTP/AVP 0 8
   a=loopback:source

Answer:
   m=audio 54312 RTP/AVP 8
   a=loopback:mirror

In above, lack of in/out means both. And then the identifier to match 
streams isn't needed.

Another variant can handle case where choice of who to mirror is negotiated:

Offer:
   m=audio 41352 RTP/AVP 0 8
   a=loopback:source/mirror

Answer:
   m=audio 54312 RTP/AVP 8
   a=loopback:mirror

Alternative Answer:
   m=audio 54312 RTP/AVP 8
   a=loopback:source

If two streams are desired but mirroring is to be negotiated, then there 
is need to select what formats are to be transcoded to what:

Offer:
   m=audio 41352 RTP/AVP 0 8
   a=loopback:from x
   m=audio 41354 RTP/AVP 112
   a=loopback:to x
   a=rtpmap:112 rtploopback/8000

Answer:
   m=audio 54312 RTP/AVP 8
   a=loopback:mirror-in x
   m=audio 54320 RTP/AVP 112
   a=loopback:mirror-out x
   a=rtpmap:112 rtploopback/8000

Alternate Answer:
   m=audio 54312 RTP/AVP 8
   a=loopback:source-out x
   m=audio 54320 RTP/AVP 112
   a=loopback:source-in x
   a=rtpmap:112 rtploopback/8000

Here is a more comprehensive example:

Offer:
   m=audio 41352 RTP/AVP 0 8
   a=loopback:source-out x
   a=sendonly
   m=audio 41354 RTP/AVP 112
   a=loopback:source-in x
   a=rtpmap:112 rtploopback/8000
   a=recvonly
   m=video 41362 RTP/AVP 116
   a=loopback:from y
   a=rtpmap:116 videostuff...
   a=sendrecv
   m=video 41364 RTP/AVP 118
   a=loopback:to y
   a=rtpmap:112 rtploopback/8000
   a=sendrecv

Answer:
   m=audio 54312 RTP/AVP 8
   a=loopback:mirror-in x
   a=recvonly
   m=audio 54320 RTP/AVP 112
   a=loopback:mirror-out x
   a=rtpmap:112 rtploopback/8000
   a=sendonly
   m=video 54382 RTP/AVP 120
   a=loopback:mirror-in y
   a=rtpmap:120 videostuff...
   a=recvonly
   m=video 54384 RTP/AVP 118
   a=loopback:mirror-out y
   a=rtpmap:112 rtploopback/8000
   a=sendonly