Re: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00: comments and question

["amar deep" <[e-mail]>]

Hi ,

Following is the answer on the comment asked.

1) and 2) – I suggest author to update in their next version of the draft.

3) How would this draft interact with RFC 4028 from refresh -versus- deactivation perspective?

[Amardeep-Reply] rfc4028 talks about session refresher. With respect to Rfc402, its concept still 
persist with the implementation of the proposed draft-"draft-sunil-sankar-dispatch-sip-incr". Once 
session is established either party UAC or UAS is agreed to send re-invite periodically. While 
implementing the draft proposal “draft-sunil-sankar-dispatch-sip-incr” re-invite will be still sent 
following rfc4028, but size of the message reduced, in this case Re-invite message size will be 
reduced. For example - avoiding sending P-headers, etc. Also since no new call setup will happen, no 
new call routing decision to be made, hence multiple other headers should not be sent to network.

4)  How would this draft interact with draft-ietf-insipid-session-id since the presence of the Session-
ID is to help debug the call flow?

[Amardeep-Reply] W.r.t to "draft-ietf-insipid-session-id" which talks about have end-to-end session 
identifier. This concept still persists with the implementation of the proposed draft-"draft-sunil-
sankar-dispatch-sip-incr". For example, after session is established, and calling user try to put call 
on hold with UUID {A,B}, this parameter will be send even when the proposed draft "draft-sunil-sankar-
dispatch-sip-incr" is implemented as {A,B} identifier will be traced down required as which user have 
initiated the hold event.

5) You should clarify that transaction specific headers such as Supported, Require, Proxy-Require, and 
Content-Length need to be included again

[Amardeep-Reply] Content-Length:, should be sent all the time as it’s an indicator of  size, I 
guess authors agree to this. Supported, Require, Proxy-Require these are scenario specific header must 
be send if event trigger, like Re-invite, Hold, etc requires else they must be filtered out .

Thanks,
Amardeep Sinha

On Thu, 30 Jun 2016 11:11:02 +0530 sunil sinha  wrote
>Hi, I don't think at this point Cisco or anyone else plan to implement this draft in their product.

Thanks & Regardssunil
On Tue, Jun 28, 2016 at 7:32 PM, Cullen Jennings (fluffy)  wrote:


Does Cisco or anyone else plan to implement this draft in their products? I’m skeptical this would 
improve performance over cached parsing approaches.







> On Jun 13, 2016, at 9:51 PM, Brett Tate  wrote:

>

> Hi,

>

> The following are a few comments concerning

> draft-sunil-sankar-dispatch-sip-incr-00.

>

> Thanks,

> Brett

>

> ------

>

> 1) The draft should clarify the relation to SHOULD and MUST within other

> RFCs concerning header inclusion.  Section 6.1 appears to indicate that

> you can ignore MUST statements within other RFCs concerning the need to

> include a specific a header.  However, I'm currently unsure if section 4

> next-to-last sentence supports or conflicts with that mandate.

>

> 2) You might want to reword section 4 to use normative language.

>

> 3) How would this draft interact with RFC 4028 from refresh -versus-

> deactivation perspective?

>

> 4) How would this draft interact with draft-ietf-insipid-session-id since

> the presence of the Session-ID is to help debug the call flow?

>

> 5) You should clarify that transaction specific headers such as Supported,

> Require, Proxy-Require, and Content-Length need to be included again.

>

> _______________________________________________

> dispatch mailing list

> [e-mail]

> https://www.ietf.org/mailman/listinfo/dispatch



_______________________________________________

dispatch mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/dispatch



_______________________________________________

dispatch mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/dispatch



Amar