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

From: "sunil kumar sinha" <[email-masked]>
Date: 22 Mar 2017 08:33:37 -0000

Hi Ranjit,

I have tried to answer your valuable comments.
Please find response inline below.

Section 1

1. the intial SIP message e.g REGISTER or INVITE contains atleast 7 mandatory headers and not 6.  E.g  
To, From, Call-ID, CSeq, Contact, Max-Forwards and Via.  In addition there could be more headers like 
Content-Type, Content-Length, etc 

[Answer] Thanks for pointing out blunder mistake. It will be corrected in next version.

2. Instead of jointly - which actually is used for 2 headers and not for many.  so you should use the 
word - together or all of them .

[Answer] It will also consider and corrected in next version. 

3. Also I don't think the main motivation of providing more headers in a SIP message is to actually 
find a facility though the actual intent is to better describe the session or indicate support for a 
certain capability or service and mandate some feature (long list...) 

[Answer] : Ok

4. Also I do not think we can conclude whether the headers are needed or not before and after session 
is established.  every header that is part of the SIP message has certain significance and it is put if 
there is a need. so we can not generalize saying that prior to session establishment more headers are 
needed and after session less.

[Answer]: User Agent is free to add header when and wherever it is MUST in the session.

Our suggestion is that once the dialog is established, only those optional header(s) will be present in 
the subsequent request or response whose attribute is changed. It will NOT applicable to seven 
mandatory headers i.e. To, From, CSeq, Call-ID, Max-Forwards, Via and Contact. 

5. if you think it is burden on the bandwidth, the messages can be compressed.

[Answer] Correct, compression is one good options. But it will not reduce the number of options 
headers. Our idea is to keep the minimum number of header after the dialog is established. This is 
because the larger message size take significantly more CPU cycles and memory for both parsing and 
producing. Thus, reducing message size would increase through put. At the same time it will also reduce 
the network burden.

Thanks & Regards,
Sunil Sinha

On Tue, 14 Jun 2016 03:00:20 +0530 Ranjit Avasarala  wrote
>Hi Sunil
my initial comments on this draft
Section 1
1. the intial SIP message e.g REGISTER or INVITE contains atleast 7 mandatory headers and not 6.  E.g 
 To, From, Call-ID, CSeq, Contact,     Max-Forwards and Via.  In addition there could be more headers 
like Content-Type, Content-Length, etc 2. Instead of jointly - which actually is used for 2 headers and 
not for many.  so you should use the word - together or all of them .3. Also I don't think the main 
motivation of providing more headers in a SIP message is to actually find a facility though the actual 
intent is to better     describe the session or indicate support for a certain capability or service 
and mandate some feature (long list...) 4. Also I do not think we can conclude whether the headers are 
needed or not before and after session is established.  every header that is part of the    SIP message 
has certain significance and it is put if there is a need. so we can not generalize saying that prior 
to session establishment more headers    are needed and after session less.5. if you think it is burden 
on the bandwidth, the messages can be compressed.
More comments as I review
ThanksRanjit

On Mon, Jun 13, 2016 at 1: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

[email-masked]

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

_______________________________________________

dispatch mailing list

[email-masked]

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