Subject: [Sipping] comments on draft-houri-sipping-presence-scaling-requirements-00.txt

From: Qian Sun <[email-masked]>
Date: Wed, 11 Jul 2007 16:45:55 +0800

Hello,

To the service providers one of the most important concerns is the users’ satisfaction to their services. A good solution ought not to impact the user experience and usability, and it won’t be proper to force the users to learn and do too much complicated things. The approach should not restrict the users from getting their required presence information timely and unabridged. Based on this, I suggest to add some requirements like below:

3.5. Operational & Quality of Experience Requirements
   o  REQ-014: The solution MUST NOT degrade user experience.
   o  REQ-015: The solution SHOULD be transparent to users.
   ......

Cheers,
Qian

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Avshalom Houri <[email-masked]>
Date: Wed, 25 Jul 2007 00:48:06 +0300

Agree that we need to add this text or similar to emphasize user 
experience.

Thanks
--Avshalom

Qian Sun <[email-masked]> 
11/07/2007 11:45

To
Avshalom Houri/Haifa/IBM@IBMIL
cc
[email-masked]
Subject
comments on draft-houri-sipping-presence-scaling-requirements-00.txt

Hello,

To the service providers one of the most important concerns is the users’ 
satisfaction to their services. A good solution ought not to impact the 
user experience and usability, and it won’t be proper to force the users 
to learn and do too much complicated things. The approach should not 
restrict the users from getting their required presence information timely 
and unabridged. Based on this, I suggest to add some requirements like 
below:

Cheers,
Qian

---

From: <[email-masked]>
Date: Wed, 25 Jul 2007 05:14:32 +0300

Here is the issue I tried to explain at the SIPPING session about how
the config-framework deals with NAT traversal. It may be already covered
based on the current drafts, but it's not clear to me.

Although there are no explictely defined requeirements for SIP UA
configuration, it is obvious that it has to work for UAs that are behind
NATs. The sip-outbound draft explains how a SIP UA registers itself via
an outbound-capable proxy. During the registration the proxy creates a
binding between instance-id + reg-id and the transport flow over which
the REGISTER was sent, so that transport flow is used to deliver the
incoming requests to the UA. The UA keeps the NAT binding open for that
transport flow. To my understanding the establishment of the required
state is primarily described in the context of REGISTER transaction. In
sipping-config-framework, however, the first thing the UA has to issue
is a SUBSCRIBE request, and the subsequent NOTIFYs will have to be
transported over the same flow as the SUBSCRIBE was sent in order to get
through the NATs the UA is behind. (To my understanding this does not
work per normal RFC 3261 procedures without outbound support.) I suppose
this has to work somehow, but I did not find anything explaining it in
either of the two drafts. The config-framework draft tells that
+sip.instance feature tag is used in the Contact header, but I did not
find anything on how it would be related to managing the outbound flow
for the SUBSCRIBE. Similarly I did not find in sip-outbound how
"non-registration" dialog-forming requests are dealt with. Also, how the
keepalive mechanism for the flow is discovered is not clear to me, since
DNS SRV can't deliver the required URI parameters. Another confusing
thing is that in sip-outbound it is stated that outbound proxies are
discovered using e.g. config-framework, while it seems that in order for
it to work through NATs, a UA using the config-framework will need an
outbound-capable proxy to talk to. This sounds a bit like a
chicken-and-egg problem.

I think it would be valuable to explain somewhere how this works. 

Regards,
	Markus

---

From: [email-masked]
Date: Thu, 26 Jul 2007 12:37:52 -0400

Hi Markus, 
Thanks for the detailed explanation of your concerns.  Such things are 
difficult to get at on the mic, and "design at the mic" is not a good 
thing.   . 

First and foremost, I am anxious to NOT couple SIPPING Config Framework 
and Outbound any more than they already are (they have reference 
dependancies, but at this point no real concept/content dependancies).  I 
believe it is not necessary to do so, they are sufficiently orthogonal, 
and also it would risk slowing both down. 

I believe the key points to below are:

* Config Framework stages would normally happen before the Register stage, 
where Outbound becomes effective. 

* Config stages can be readily accomplished from behind NAT, as long as 
TCP/TLS is used.  For UDP, it would likely be necessary to perform NAT 
keep-alive from the endpoint, even though Outbound is not "activated" yet. 
 Since this is not specific to the Config Framework (it is a general 
issue) I do not think it should be spelled out in that document. 

* Config can (I expect usually would) provide Outbound compliant 
destinations for Registration, as well as (possibly) finer details related 
such as whether Outbound should be required. 
* Config can also supply destination of a different PDS behind the 
Outbound Proxy if necessary, and the endpoint would "rehome" its 
subscription to there.  This is an issue for profile data definitions, so 
out of scope for the framework itself. 

A few more inline [PB] comments below. 

Hopefully this helps? 

Cheers,
Peter Blatherwick (design team member BTW)

<[email-masked]>
24.07.07 22:14
 
        To:     <[email-masked]>
        cc: 
        Subject:        [Sipping] Question on sipping-config-framework and 
sip-outbound

either of the two drafts. 

[PB] See comments above at top.  I believe that pre-Outbound 
Subscribe/Notify would work just fine in TCP/TLS, but would need proactive 
keep-alive from the endpoint to keep NAT binding alive in the UDP case. 
Also, in UDP, the PDS would need to be aware it should use the same dest 
port as the Subscribe was received from for all Notifys, but that's just 
good practice at this point and not specific to Config Framework. 

... The config-framework draft tells that
+sip.instance feature tag is used in the Contact header, but I did not
find anything on how it would be related to managing the outbound flow
for the SUBSCRIBE. 

[PB] Main intent of the sip.instance tag in config framework is really to 
identify the device uniquely, not to manage flows.  It could also be there 
to help manage flows after Outbound has been initiated, so would serve 
double purpose at that point.  (This creates unfortunate document 
reference dependency, but unavoidable.)

... Similarly I did not find in sip-outbound how
"non-registration" dialog-forming requests are dealt with. 

[PB] I agree that Outbound really should discuss more about handling 
things other than Register, including Subscribe/Notify, mid-dialog flow 
failures, etc.  This would need to be addressed in Outbound of course, not 
Config Framework. 

... Also, how the

[PB] I believe this can work, as above. 

Regards,
                 Markus

---

From: <[email-masked]>
Date: Fri, 27 Jul 2007 18:42:18 +0300

Hi Peter,
 
Thanks for the reply.
 
sipping-nat-scenarios-07 states:
 
   The SIP protocol does not
   provide a mechanism that allows new requests generated in the reverse
   direction of the originating client to use the existing TCP
   connection created between the client and the server during
   registration.  This results in the registered contact address not
   being bound to the "connection" in the case of TCP.  Requests are
   then blocked at the NAT, as illustrated in Figure 2.  This problem
   also exists for unreliable transport protocols such as UDP where
   external NAT mappings need to be re-used to reach a SIP entity on the
   private side of the network.
 
So, by default the NOTIFY is not sent over the same TCP connection as
the SUBSCRIBE uses. sip-outbound solves this by defining how the
connection is maintained and shared. The problem is that it won't work
unless the UA has registered through an outbound capable proxy. I still
don't understand how this works for the initial SUBSCRIBE & NOTIFY in
config-framework, which happens prior to registration. 
 
Markus

________________________________

	From: ext [email-masked]
[mailto:[email-masked]] 
	Sent: 26 July, 2007 19:38
	To: Isomaki Markus (Nokia-SIR/Espoo)
	Cc: [email-masked]
	Subject: Re: [Sipping] Question on sipping-config-framework and
sip-outbound

	Hi Markus, 
	Thanks for the detailed explanation of your concerns.  Such
things are difficult to get at on the mic, and "design at the mic" is
not a good thing.   .   
	
	First and foremost, I am anxious to NOT couple SIPPING Config
Framework and Outbound any more than they already are (they have
reference dependancies, but at this point no real concept/content
dependancies).  I believe it is not necessary to do so, they are
sufficiently orthogonal, and also it would risk slowing both down.   

	* Config Framework stages would normally happen before the
Register stage, where Outbound becomes effective.   
	
	* Config stages can be readily accomplished from behind NAT, as
long as TCP/TLS is used.  For UDP, it would likely be necessary to
perform NAT keep-alive from the endpoint, even though Outbound is not
"activated" yet.  Since this is not specific to the Config Framework (it
is a general issue) I do not think it should be spelled out in that
document.   
	
	* Config can (I expect usually would) provide Outbound compliant
destinations for Registration, as well as (possibly) finer details
related such as whether Outbound should be required.   
	* Config can also supply destination of a different PDS behind
the Outbound Proxy if necessary, and the endpoint would "rehome" its
subscription to there.  This is an issue for profile data definitions,
so out of scope for the framework itself.   

	Hopefully this helps?   
	
	Cheers, 

24.07.07 22:14 

        To:        <[email-masked]> 
        cc:         
        Subject:        [Sipping] Question on sipping-config-framework
and sip-outbound

	Here is the issue I tried to explain at the SIPPING session
about how
	the config-framework deals with NAT traversal. It may be already
covered
	based on the current drafts, but it's not clear to me.
	
	Although there are no explictely defined requeirements for SIP
UA
	configuration, it is obvious that it has to work for UAs that
are behind
	NATs. The sip-outbound draft explains how a SIP UA registers
itself via
	an outbound-capable proxy. During the registration the proxy
creates a
	binding between instance-id + reg-id and the transport flow over
which
	the REGISTER was sent, so that transport flow is used to deliver
the
	incoming requests to the UA. The UA keeps the NAT binding open
for that
	transport flow. To my understanding the establishment of the
required
	state is primarily described in the context of REGISTER
transaction. In
	sipping-config-framework, however, the first thing the UA has to
issue
	is a SUBSCRIBE request, and the subsequent NOTIFYs will have to
be
	transported over the same flow as the SUBSCRIBE was sent in
order to get
	through the NATs the UA is behind. (To my understanding this
does not
	work per normal RFC 3261 procedures without outbound support.) I
suppose
	this has to work somehow, but I did not find anything explaining
it in
	either of the two drafts. 
	
	[PB] See comments above at top.  I believe that pre-Outbound
Subscribe/Notify would work just fine in TCP/TLS, but would need
proactive keep-alive from the endpoint to keep NAT binding alive in the
UDP case.  Also, in UDP, the PDS would need to be aware it should use
the same dest port as the Subscribe was received from for all Notifys,
but that's just good practice at this point and not specific to Config
Framework.   
	
	... The config-framework draft tells that
	+sip.instance feature tag is used in the Contact header, but I
did not
	find anything on how it would be related to managing the
outbound flow
	for the SUBSCRIBE. 
	
	[PB] Main intent of the sip.instance tag in config framework is
really to identify the device uniquely, not to manage flows.  It could
also be there to help manage flows after Outbound has been initiated, so
would serve double purpose at that point.  (This creates unfortunate
document reference dependency, but unavoidable.) 

	[PB] I agree that Outbound really should discuss more about
handling things other than Register, including Subscribe/Notify,
mid-dialog flow failures, etc.  This would need to be addressed in
Outbound of course, not Config Framework.   
	
	... Also, how the
	keepalive mechanism for the flow is discovered is not clear to
me, since
	DNS SRV can't deliver the required URI parameters. Another
confusing
	thing is that in sip-outbound it is stated that outbound proxies
are
	discovered using e.g. config-framework, while it seems that in
order for
	it to work through NATs, a UA using the config-framework will
need an
	outbound-capable proxy to talk to. This sounds a bit like a
	chicken-and-egg problem. 

	I think it would be valuable to explain somewhere how this
works. 
	
	Regards,
	                Markus   

	_______________________________________________
	Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping
	This list is for NEW development of the application of SIP
	Use [email-masked] for questions on current
sip
	Use [email-masked] for new developments of core SIP