Subject: Re: [Asap] ASAP DRAFT

From: "Kaustubh Inamdar (kinamdar)" <[email-masked]>
Date: Sun, 29 Nov 2020 12:39:28 +0000

Hi Christer,

Thank you for the very detailed review. I’m very sorry I couldn’t get back to you on this sooner. I was ill for a few days. I think almost all of your recommendations/observations ought to be incorporated in the draft as they either provide better context or tie up loose ends. With regards to the questions you had, please find my responses below:

“The daft talks about one enterprise network, connected to a service provider network. What if there are transit networks in between?”

Kaustubh: This was a point brought up some time back on Dispatch; in such situations the best approach would be for the terminating carrier to advertise a parameter set that is in line with the requirements/capabilities of the intermediary carrier. What capabilities are supported by the intermediary carrier could be known as a result of inter-carrier agreements. Or perhaps something similar to this framework could be used for such discovery. I think a small note in the draft on how this framework works in cases where there is an intermediary carrier ought to be helpful?

“I don’t understand this. Assuming you already support SIP, you have to add support for the new SIP extension. But, that is normal, isn’t it? Also with HTTP you will have to add support for the mechanism.”

Kaustubh: Agreed, it is absolutely normal for vendors to continue to enhance software to on-board new features. However, our guiding motivation for adding that in was to contrast the amount of work that would have to be undertaken by equipment manufacturers in fleshing out support for a new SIP event package as opposed to leveraging HTTP, which is present today on most edge devices such as SBCs. Even from the perspective of the service provider, all that is required of them is to deploy a standard HTTPS server.

“But, what happens once the edge node receives the response with the capabilities? How are they delivered to the endpoints etc?”

Kaustubh: Ideally, the edge element, such an SBC, interprets the response and based on the capabilities provided by the ITSP, can be configured accordingly to ensure successful peering. This is a reasonable assumption as SBCs typically serve as transit points for VoIP traffic entering and leaving the enterprise network - they can engineer traffic according to the capabilities advertised by the service provider. Additionally, they have the ability to interwork mismatches in the signaling and/or media plane between the enterprise and service provider networks.

However, if there arises a situation wherein configuration on several devices needs to be modified to ensure successful ITSP peering, there are several alternatives by which this could be done. For example, an administrator can simply read through the HTTPS response from the ITSP and configure various devices in the enterprise network accordingly. Alternatively, the edge element can disseminate this information to downstream devices such as application or/and call control servers via some interface. Given the variability on whether this information actually needs to be distributed to various devices and how it can be done so, we have left out specifics from the draft.

Not sure if the larger group thinks clarification on this aspect is needed on the draft.

“The capability model defined in Section 9 is quite limited. For example, it only contains audio formats, but not video formats. I assume there is some reason for the chosen subset, so that would be good to explain.”

Kaustubh: ITSPs, as of today don’t support video when providing SIP trunking to enterprise networks. This was the reason video capabilities were left out. I will defer to the group on whether we need to add some text around this aspect.

“Does this refer to RTP-based DTMF, SIP INFO based DTMF, or both?”

Kaustubh: ITSPs today  support only two types of DTMF as far as I know. RTP NTE and raw in-band DTMF. Raw in-band DTMF is encoded in the RTP payload as raw tones instead of using any specialised RTP formatting as RTPNTE does. Given that raw inland DTMF is quite rare and the fact that I haven’t come across any ITSP using Out of Band, SIP-based DTMF the DTMF section of this draft is restricted to RTP NTE.

Thanks,
Kaustubh

From: Christer Holmberg <[email-masked]>
Date: Monday, 23 November 2020 at 19:06
To: Kaustubh Inamdar <[email-masked]>
Cc: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Subject: RE: ASAP DRAFT

Hi Kaustubh,

Sorry for the late response. Due to some other high-priority work, I have not had time to do much IETF work lately. I normally tell people if I don’t have time to perform a request, but it seems like I forgot in your case. Sorry for that.

That is also the reason I haven’t subscribed to the ASAP list, because I knew I wasn’t going to have time to follow the discussions.

However, I have had a look at the draft, and below are some comments:

GENERAL:
========

Q1:

Please add the appropriate references to SIP Connect, HTTP, etc.

Q2:

The draft mixes between “HTTP” and “HTTPS”, even within the same paragraph. Please try to align.

Q3:

I think it should be more clear on exactly what types of capabilities you are aiming. For example, in Section 7 you assume that the capabilities are static, but there are many types of capabilities (especially lower-layer ones, including radio capacity etc) that are not. In Section 8 you say that the capabilities consist of information needed in order to communicate with the service provider network. But, again, there are low-layer capabilities that I assume are not within the scope of the draft. So, if the capabilities are related to SIP features, media features etc, I think it should be clarified. You DO get an idea by looking at the tree in Section 9, but that is not normative scope text.

Q4:

The capability model defined in Section 9 is quite limited. For example, it only contains audio formats, but not video formats. I assume there is some reason for the chosen subset, so that would be good to explain.

Q5:

The daft talks about one enterprise network, connected to a service provider network. What if there are transit networks in between?

SECTION 1:
=========

Q6:

In the Introduction, I don’t agree with (and I think it gives a bad picture to the readers of the draft) the text saying the service providers and equipment vendors don’t always implement requirements. They implement whatever they are required to :)

So, you probably want to say that they have not always adopted the enterprise specifications.

Q7:

At the end of the Introduction section, please put the text starting with “This draft introduces….” in a separate paragraph. It makes it easier to find, and before publication to verify whether it is actually accurate with what is to be published.

Q8:

Before the work started, I asked why existing mechanisms cannot be used to fetch the capabilities, and I got some explanations. I think it would be good to have a paragraph at the end of the section to say a few words about that.

I DO know you have text about that in Section 4, and I will provide comments on the content further down. But, I think it would be good to have text already in the Introduction.

SECTION 3:
=========

Q9:

In the reference architecture, is the explicit mentioning of SRTP important? I guess there are also other media options, e.g., WebRTC data channels, MSRP, BFCP etc. Perhaps you could say “SRTP etc”, “e.g., SRTP”, or something….

Q10:

In the definition of “Capability Set”, you don’t need the “This specification uses the term…” part. You have previously already stated that these are terms used by the draft :)

SECTION 4:
=========

Q11:

Are the bullets in the beginning of the section requirements? If so, perhaps there should be a separate section for that.

Q12:

The text talks about the issues with using existing SIP mechanisms for providing the capabilities, and that is also something I raised when the work was proposed.

“For example, not only would this workflow require enterprise and service provider equipment
manufacturers to upgrade their software stacks,”

I don’t understand this. Assuming you already support SIP, you have to add support for the new SIP extension. But, that is normal, isn’t it? Also with HTTP you will have to add support for the mechanism.

“but it would also create a significant amount of ambiguity in terms of which device in
the service provider network handles subscriptions and generates notifications.”

I don’t understand this. The operator will implement the handling somewhere, and normal SIP routing mechanisms will make sure the subscriptions reach there. It’s not something the enterprise network need to care about, is it?

I thought one of the main reasons for a new mechanism was that it would allow to fetch the capabilities prior to SIP registration, and prior to SIP session establishment.

“Yet another example of an alternative mechanism would
be for service providers and enterprise equipment manufacturers to
agree on YANG models [RFC 6020 [3]] that enable configuration to be
pushed over NETCONF [RFC 6241 [4]] to enterprise networks from a
centralised source hosted in service provider networks.”

SECTION 5:
=========

Q13:

The section gives and overview why it makes sense for the edge node to send the HTTP GET, etc.

But, what happens once the edge node receives the response with the capabilities? How are they delivered to the endpoints etc?

SECTION 9:
=========

Q14:

I am not an expert on YANG, so I will only comment on the content.

dtmf: Does this refer to RTP-based DTMF, SIP INFO based DTMF, or both?

signalingForking: Just before there is forking it doesn’t necessarily mean there will be multiple early-media flows. It is probably good to say that multiple early-media flows MAY occur.

Regards,

Christer

From: Kaustubh Inamdar (kinamdar) <[email-masked]>
Sent: perjantai 6. marraskuuta 2020 11.11
To: Christer Holmberg <[email-masked]>
Cc: Gonzalo Salgueiro (gsalguei) <[email-masked]>
Subject: ASAP DRAFT

Hi Christer,
Trust you are well. I'm reaching out to you to let you know that there is a new version of the ASAP draft, that may be found here:(https://tools.ietf.org/html/draft-kinamdar-dispatch-sip-auto-peer-04). Sorry if this is redundant information, I wasn't sure if you were aware as I noticed that you haven't subscribed to asap mailer yet. The co-authors would be really appreciative and grateful to hear your thoughts on the finer aspects of the draft - we are confident that your observations & suggestions would go a long way in improving the draft. Looking forward to hearing back from you!

Regards,
Kaustubh