Subject: [Ecrit] Phonebcp issues

From: Gunnar Hellström <[email-masked]>
Date: Fri, 09 Mar 2012 12:26:13 +0100

The final publication of draft-ietf-ecrit-phonebcp has now been hanging 
waiting 7 months for draft-ietf-mmusic-media-loopback to be finalized 
because it is referenced in the test section.
The status of the media-loopback draft is that it seems to be less ready 
now than 7 months ago.

This makes in fact even RFC 6443 impossible to implement, because RFC 
6443 refers to phonebcp for specification of the testing procedure

I wonder if it is time to pull phonebcp loose from the dependency of the 
media-loopback draft and specify a simple test method of its own 
instead. I do not think that the current specification in phonebcp is 
very realistic, with just a loopback. I think the test server could just 
as well generate some own initial test media and then possibly also 
mirror some packets when received. The current behavior of the 
media-loopback to wait for incoming media before it generates any 
outgoing media is not similar to what will be the scenario in real 
calls. Both sides in real calls normally take initiative to media 
transmission after the session is established. The resulting problems 
for NAT traversal of the current media-loopback draft is one of the 
issues that has caused its delay.

Another small issue: RFC 6443 recommends SRTP to be used for media 
security, but phonebcp does not mention media security.
phonebcp is approved, so I do not think it is appropriate to open it for 
such additions. Can this gap be covered in some additional draft, or can 
we rely on implementors to apply both phonebcp and RFC 6443?

Gunnar

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 9 Mar 2012 14:29:13 +0200

Hi Gunnar, 
Hi all, 

I agree with you regarding the dependency to the media loopback document. 
The required functionality for PhoneBCP is actually pretty simple. 

I would be in favor of untangling the dependency to draft-ietf-mmusic-media-loopback. 

For the SRTP media security I would suggest to go for MUST implement SDES and SHOULD implement DTLS-SRTP. 

Ciao
Hannes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Gunnar Hellström
> Sent: Friday, March 09, 2012 1:26 PM
> To: Ecrit
> Subject: [Ecrit] Phonebcp issues
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Brian Rosen <[email-masked]>
Date: Fri, 9 Mar 2012 11:19:13 -0500

To do this, we would have to take the document back into the working group, make changes, and run through the approval process.

I think this is something we should consult with ADs before we do anything.

I don't have a problem with making the changes.  I'm just looking for the path of least resistance.

Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 11 Mar 2012 17:13:51 +0200

Going back to the working group is indeed a difficult issue. I have experienced that already within the GEOPRIV working group and it stalled the work for years. I do, however, wonder whether this is entirely necessary. Isn't there a shorter route where the working group needs to approve the change of the issue. I would even be OK with saying that this entire media loopback functionality is optional and to turn it into an informative reference. 

Another option is to "motivate" the authors of draft-ietf-mmusic-media-loopback to get their work done. There are unfortunately 6 authors on that document and without knowing the history I could imagine that nobody feels responsible for pushing it forward. 

In any case, we need to do something. Just waiting isn't an option.

---

From: Brian Rosen <[email-masked]>
Date: Sun, 11 Mar 2012 14:23:48 -0400

It's a pretty key capability, given NATs and other middle boxes, to make sure the media path will work.  It's optional, but it's very useful.

I don't see how you could make any kind of normative change without WG consensus to the change, and that would need a review cycle,

I sent a query into Hadriel Kaplan, who was appointed by the WG  chairs to get the document out the door.

I'll let you know what I find out.

Brian

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 11 Mar 2012 20:07:32 +0100

I have an initial text proposal for phonebcp, to use to release the 
media-loopback dependency.
I made the media transfer much longer that the three packets originally 
indicated in the current draft. I think that is needed to make the test 
usaful, but the use and effect of that may be discussed.

Current wording:
--------------------------

    ED-80 A PSAP accepting a test call SHOULD accept a media loopback
    test [I-D.ietf-mmusic-media-loopback  <imap://[email-masked]:143/fetch%3EUID%3E.Sent%3E11262#ref-I-D.ietf-mmusic-media-loopback>] and SHOULD support the "rtp-
    pkt-loopback" and "rtp-start-loopback" options.  The user agent would
    specify a loopback attribute of "loopback-source", the PSAP being the
    mirror.  User Agents should expect the PSAP to loop back no more than
    3 packets of each media type accepted (which limits the duration of
    the test), after which the PSAP would normally send BYE.

-----------------------------------------

Change proposal
_______________________.

ED-80 A PSAP accepting a test call SHOULD accept all media in the offer 
for which it has coresponding codecs. Both the PSAP and the User Agent 
SHOULD send media contents until 500 ms after the session establishment 
was completed. From the moment when the PSAP receives media contents 
from the User Agent, the received media contents shall be looped back to 
the User Agent. RTCP reports shall be sent before the PSAP ends the test 
call by sending BYE. If the User Agent does not receive a BYE within 35 
seconds after it sent its ACK, then the User Agent SHALL end the call by 
sending BYE.

/Gunnar

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 11 Mar 2012 15:46:52 -0500

IMO removing a normative dependency from a draft 
will force going through the WG and IESG again...

James
(a coauthor of phonebcp)

At 02:07 PM 3/11/2012, Gunnar Hellström wrote:
>I have an initial text proposal for phonebcp, to 
>use to release the media-loopback dependency.
>I made the media transfer much longer that the 
>three packets originally indicated in the 
>current draft. I think that is needed to make 
>the test usaful, but the use and effect of that may be discussed.
>
>Current wording:
>    test 
> [I-D.ietf-mmusic-media-loopback 
> <imap://[email-masked]:143/fetch%3EUID%3E.Sent%3E11262#ref-I-D.ietf-mmusic-media-loopback>] 
> and SHOULD support the "rtp-
>ED-80 A PSAP accepting a test call SHOULD accept 
>all media in the offer for which it has 
>coresponding codecs. Both the PSAP and the User 
>Agent SHOULD send media contents until 500 ms 
>after the session establishment was completed. 
> From the moment when the PSAP receives media 
>contents from the User Agent, the received media 
>contents shall be looped back to the User Agent. 
>RTCP reports shall be sent before the PSAP ends 
>the test call by sending BYE. If the User Agent 
>does not receive a BYE within 35 seconds after 
>it sent its ACK, then the User Agent SHALL end the call by sending BYE.
>
>
>/Gunnar
>
>
>>It's a pretty key capability, given NATs and 
>>other middle boxes, to make sure the media path 
>>will work.  It's optional, but it's very useful.
>>
>>I don't see how you could make any kind of 
>>normative change without WG consensus to the 
>>change, and that would need a review cycle,
>>
>>I sent a query into Hadriel Kaplan, who was 
>>appointed by the WG  chairs to get the document out the door.
>>
>>>Going back to the working group is indeed a 
>>>difficult issue. I have experienced that 
>>>already within the GEOPRIV working group and 
>>>it stalled the work for years. I do, however, 
>>>wonder whether this is entirely necessary. 
>>>Isn't there a shorter route where the working 
>>>group needs to approve the change of the 
>>>issue. I would even be OK with saying that 
>>>this entire media loopback functionality is 
>>>optional and to turn it into an informative reference.
>>>
>>>Another option is to "motivate" the authors of 
>>>draft-ietf-mmusic-media-loopback to get their 
>>>work done. There are unfortunately 6 authors 
>>>on that document and without knowing the 
>>>history I could imagine that nobody feels responsible for pushing it forward.
>>>
>>>>To do this, we would have to take the 
>>>>document back into the working group, make 
>>>>changes, and run through the approval process.
>>>>
>>>>I don't have a problem with making the 
>>>>changes.  I'm just looking for the path of least resistance.
>>>>
>>>>Brian
>>>>
>>>>>I would be in favor of untangling the 
>>>>>dependency to draft-ietf-mmusic-media-loopback.
>>>>>
>>>>>For the SRTP media security I would suggest 
>>>>>to go for MUST implement SDES and SHOULD implement DTLS-SRTP.
>>>>>
>>>>>Ciao
>>>>>Hannes
>>>>>
>>>>>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 12 Mar 2012 12:13:03 -0400

Hadriel says there will be a new version of media-loopback today.

Brian

---

From: Randall Gellens <[email-masked]>
Date: Sat, 24 Mar 2012 12:32:30 -0700

Hi Gunnar,

At 8:07 PM +0100 3/11/12, Gunnar Hellström wrote:

>  I have an initial text proposal for phonebcp, 
> to use to release the media-loopback dependency.
>     test [I-D.ietf-mmusic-media-loopback 
>  ED-80 A PSAP accepting a test call SHOULD 
> accept all media in the offer for which it has 
> contents from the User Agent, the received 
> media contents shall be looped back to the User 
> Agent. RTCP reports shall be sent before the 
> PSAP ends the test call by sending BYE. If the 
> User Agent does not receive a BYE within 35 
> seconds after it sent its ACK, then the User 
> Agent SHALL end the call by sending BYE.

This seems like a good approach.  Your earlier 
message noted that a loopback test wasn't 
realistic, that it would be better for the PSAP 
to have some test media it sends, to better 
simulate a real call:

At 12:26 PM +0100 3/9/12, Gunnar Hellström wrote:
>  I do not think that the current specification 
> in phonebcp is very realistic, with just a 
> loopback. I think the test server could just as 
> well generate some own initial test media and 
> then possibly also mirror some packets when 
> received. The current behavior of the 
> media-loopback to wait for incoming media 
> before it generates any outgoing media is not 
> similar to what will be the scenario in real 
> calls. Both sides in real calls normally take 
> initiative to media transmission after the 
> session is established. The resulting problems 
> for NAT traversal of the current media-loopback 
> draft is one of the issues that has caused its 
> delay.

So, maybe you can incorporate this into the 
suggested text, or perhaps this is implied by 
"Both the PSAP and the User Agent SHOULD send 
media contents," in which case maybe it can be 
made more explicit.

Also, just wondering if "A PSAP accepting a test 
call SHOULD accept all media in the offer for 
which it has coresponding codecs" should maybe be 
worded "all media in the offer which it would 
accept had the call been a non-test emergency 
call."  Maybe there's no difference, in which 
case no change is needed; I am just wondering if 
there might be situations in which a PSAP has 
codecs but wouldn't accept the media in a 
non-test emergency call, perhaps because it's 
video and the sign language interpreter is not 
available, or whatever?  (I didn't see any 
requirement in phonebcp when I looked now about 
accepting all media for which it has codecs.)

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Quick!!  Act as if nothing has happened!

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 24 Mar 2012 23:46:37 +0100

Hi Randall,

I got the impression that a new version of mmusic-media-loopback was on 
its way, and that we could hope that phonebcp therefore has an 
opportunity to move on quite soon without modification.

The test procedures can of course be discussed anyway.

  I have accepted bothy your proposals for improvements in the adjusted 
text below.
----------------------------------------------------
ED-80 Test equipment in a PSAP accepting a test call SHOULD accept all 
media and codecs in the offer which it would accept if the call had been 
a non-test emergency call. Both the PSAP and the User Agent SHOULD 
create and send media contents until 500 ms after the session 
establishment was completed. From the moment when the PSAP receives 
media contents from the User Agent, the received media contents shall be 
looped back to the User Agent. RTCP reports shall be sent before the 
PSAP ends the test call by sending BYE. If the User Agent does not 
receive a BYE within 35 seconds after it sent its ACK, then the User 
Agent SHALL end the call by sending BYE.

----------------------------------------------------

A thought about load:

Phonebcp recommends a 30 day interval of tests.
Users generate real calls with about 40 months intervals.

So, there will be 40 times more test calls than real calls.
They will be short, however. Usually just a second, while the real calls 
last a couple of minutes.

Summary: SIP transaction load of tests are 40 times the real number of 
calls, while the sum time of test calls will be only half of the sum of 
the time for real calls.
It sounds heavy but manageable.

Gunnar

___________________________________________________
Gunnar Hellström
Omnitor
[email-masked]
+46708204288

Randall Gellens skrev 2012-03-24 20:32:
>>  I made the media transfer much longer that the three packets 
>> originally indicated in the current draft. I think that is needed to 
>> make the test usaful, but the use and effect of that may be discussed.
>>
>>  Current wording:
>>  ED-80 A PSAP accepting a test call SHOULD accept all media in the 
>> offer for which it has coresponding codecs. Both the PSAP and the 
>> User Agent SHOULD send media contents until 500 ms after the session 
>> establishment was completed. From the moment when the PSAP receives 
>> media contents from the User Agent, the received media contents shall 
>> be looped back to the User Agent. RTCP reports shall be sent before 
>> the PSAP ends the test call by sending BYE. If the User Agent does 
>> not receive a BYE within 35 seconds after it sent its ACK, then the 
>> User Agent SHALL end the call by sending BYE.
>
> This seems like a good approach.  Your earlier message noted that a 
> loopback test wasn't realistic, that it would be better for the PSAP 
> to have some test media it sends, to better simulate a real call:
>
>>  I do not think that the current specification in phonebcp is very 
>> realistic, with just a loopback. I think the test server could just 
> So, maybe you can incorporate this into the suggested text, or perhaps 
> this is implied by "Both the PSAP and the User Agent SHOULD send media 
> contents," in which case maybe it can be made more explicit.
>
> Also, just wondering if "A PSAP accepting a test call SHOULD accept 
> all media in the offer for which it has coresponding codecs" should 
> maybe be worded "all media in the offer which it would accept had the 
> call been a non-test emergency call."  Maybe there's no difference, in 
> which case no change is needed; I am just wondering if there might be 
> situations in which a PSAP has codecs but wouldn't accept the media in 
> a non-test emergency call, perhaps because it's video and the sign 
> language interpreter is not available, or whatever?  (I didn't see any 
> requirement in phonebcp when I looked now about accepting all media 
> for which it has codecs.)
>

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 25 Mar 2012 06:35:05 +0200

A few more thoughts about testing:

I hope that the wording of ED-80 is sufficient for understanding that 
all media mentioned in the media chapter of Phonebcp may be tested by 
the ua and SHOULD be supported by the test station in the PSAP, 
including video, real-time-text, audio, MSRP-based text messages and SIP 
Message based text messages.

The wording suits fine for video, real-time text and audio, and the 
mmusic-media-loopback will work for them if it is decided to leave the 
wording as it is today in the approved phonebcp draft.

But I doubt that mmusic-media-loopback works for MSRP messaging, and it 
does not work for SIP Message. One reason why it does not work for SIP 
Message is that SIP Message has no SDP negotiation where media-loopback 
could be negotiated.

So, I guess that the conclusion is that separate additional work is 
needed to describe testing of MSRP and SIP Message.

Is it needed to add the straightforward media types in ED-80, like this:

ED-80 Test equipment in a PSAP accepting a test call SHOULD accept all 
media and select codecs in the offer which it would accept if the call 
had been a non-test emergency call. This is valid for video, real-time 
text and audio. Both the PSAP and the User Agent SHOULD create and send 
media contents until 500 ms after the session establishment was 
completed. From the moment when the PSAP receives media contents from 
the User Agent, the received media contents shall be looped back to the 
User Agent. RTCP reports shall be sent before the PSAP ends the test 
call by sending BYE. If the User Agent does not receive a BYE within 35 
seconds after it sent its ACK, then the User Agent SHALL end the call by 
sending BYE.

Gunnar

Gunnar Hellström skrev 2012-03-24 23:46:
> Hi Randall,
>
> I got the impression that a new version of mmusic-media-loopback was 
> on its way, and that we could hope that phonebcp therefore has an 
> media and codecs in the offer which it would accept if the call had 
> been a non-test emergency call. Both the PSAP and the User Agent 
> SHOULD create and send media contents until 500 ms after the session 
> the PSAP ends the test call by sending BYE. If the User Agent does not 
> They will be short, however. Usually just a second, while the real 
> calls last a couple of minutes.
>
> calls, while the sum time of test calls will be only half of the sum 
> of the time for real calls.
>>> media contents from the User Agent, the received media contents 
>>> shall be looped back to the User Agent. RTCP reports shall be sent 
>>> before the PSAP ends the test call by sending BYE. If the User Agent 
>>> does not receive a BYE within 35 seconds after it sent its ACK, then 
>>> the User Agent SHALL end the call by sending BYE.
>>
>>> transmission after the session is established. The resulting 
>>> problems for NAT traversal of the current media-loopback draft is 
>>> one of the issues that has caused its delay.
>>
>> So, maybe you can incorporate this into the suggested text, or 
>> perhaps this is implied by "Both the PSAP and the User Agent SHOULD 
>> send media contents," in which case maybe it can be made more explicit.
>>
>> call been a non-test emergency call."  Maybe there's no difference, 
>> in which case no change is needed; I am just wondering if there might 
>> be situations in which a PSAP has codecs but wouldn't accept the 
>> media in a non-test emergency call, perhaps because it's video and 
>> the sign language interpreter is not available, or whatever?  (I 
>> didn't see any requirement in phonebcp when I looked now about

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 25 Mar 2012 07:26:18 +0000

Howdy,
I was appointed editor of the media-loopback draft at the last IETF meeting.

Draft-17 was posted a couple weeks ago, resolving the 34 editorial comments from WGLC.

There's also going to be another rev submitted today, Draft-18, as soon as the submission tool opens again.  Draft-18 resolves 35 of the 37 technical comments from WGLC.  The remaining two were not doc change requests, but more procedural (like posting it to [email-masked]).  Draft-18 was actually complete a couple weeks ago as well, but I missed the submission deadline due to my own stupidity.  I did email draft-18 a couple weeks ago to the people who had submitted the WGLC comments, off-list, to see if they were ok with the changes, and have not gotten any negative feedback so far; so I'm hopeful it'll be final.

I believe this resolves all outstanding WGLC comments, but it's a lot of changes so it may well hit a snag in the next WGLC.

-hadriel