Subject: [Sipping] Re: I-D ACTION:draft-akhtar-sipping-header-reduction-00.txt

From: "Haseeb Akhtar" <[email-masked]>
Date: Thu, 2 Mar 2006 18:53:03 -0600

Hello Jonathan,

Thanks for your response. You are right about the details of the
justification of this proposal has been left out from the draft. We can
certainly include them in the next revision. Anyway, here is why Sigcomp
can not solve this problem.

 - To reduce the call setup time in a significant manner the initial
Invite (both originating and terminating) has to have the 
   high compression rate. Sigcomp, however, is not designed to provide
maximum compression in the first set of 
   messages (only message that goes between the UA and the Proxy server
before Invite is the Register message).
   Additionally, the SIP/SDP static dictionary does not have some of the
wireless specific data elements that
   are included in the initial Invite message.

 - Owing to the above facts, an initial SIP Invite can not be reduced to
~210 bytes using Sigcomp approach. We believe
   the proposed draft along with new data elements in the static
dictionary (that are inclusive of the SIP/SDP static
   dictionary as specified by RFC 3485) will accomplish this objective. 
   Please see <draft-akhtar-sipping-3g-static-dictionary-00.txt> 
 
(http://www.ietf.org/internet-drafts/draft-akhtar-sipping-3g-static-dict
ionary-00.txt)
   for the new data elements for the proposed static dictionary.

 - Using the signaling channel of the wireless access network allows the
SIP session to be initiated simultaneously while
   the RF resources are being acquired. A feature called DoS (Data over
Signaling) in 1xEVDO (the CDMA technology
   of 3GPP2) is a case in point here. Other wireless technologies would
also allow smaller payloads (< 200 bytes) to be 
   transferred over the signaling channel.

 - Assuming very optimistic compression ratio of 50% (by using Sigcomp),
an 1000-byte SIP Invite will be reduced to
   500 bytes. An IMS based initial SIP Invite is typically in the range
of 1200 bytes.

Hope this answers your concern.

Regards,

Haseeb

============================================================

Its not clear from reading this document why everything in here cannot
be accomplished with sigcomp alone. The basic idea, if I understand
right, is that, upon registration, the proxy server stores certain
information about the UA which is not expected to change from request to
request, and it repopulates it when a UA emits a request (which won't
contain that information). That is more or less equivalent to placing
that information into a sigcomp dictionary and then using sigcomp to ask
the server to extract the information from the dictionary.

Thanks,
Jonathan R.
Internet-Drafts at ietf.org wrote:
	A New Internet-Draft is available from the on-line
Internet-Drafts directories.

	Title : New SIP Headers for Reducing SIP Message Size Author(s)
: H. Akhtar, et al.
	Filename : draft-akhtar-sipping-header-reduction-00.txt
	Pages : 18
	Date : 2006-2-28
	
	Current SIP messages are text based and inherently large,
especially
	when these messages are to be transmitted over the
bandwidth-strained
	wireless access technologies (a typical orginiating SIP Invite
is about 1200 bytes). 
	
	For most wireless technologies, transmitting the session
initiation messages (such as SIP Invite) over the signaling channel can
reduce the call setup time substantially. The size limitation of these
wireless signaling channels are typically very small (~210 bytes in the
uplink and ~110 bytes in the downlink).
	
	To address this problem, a new function called Encoding Assitant
(EA) has been introduced in the User Agent (UA) and in the SIP Proxy
server within the network. Additionally, the method provided in this
document defines new SIP option tags and headers. These new option tags
and headers allow the UA and a SIP Proxy server within the network (such
as the P-CSCF), to exchange information using the signaling channels
supported by most wireless access networks.
	
	A URL for this Internet-Draft is:
	
http://www.ietf.org/internet-drafts/draft-akhtar-sipping-header-reductio
n-00.txt

	To remove yourself from the I-D Announcement list, send a
message to i-d-announce-request at ietf.org with the word unsubscribe in
the body of the message. You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce to change your
subscription settings.

	Internet-Drafts are also available by anonymous FTP. Login with
the username
	"anonymous" and a password of your e-mail address. After logging
in,
	type "cd internet-drafts" and then
		"get draft-akhtar-sipping-header-reduction-00.txt".

	A list of Internet-Drafts directories can be found in
	http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
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: "Dan Wing" <[email-masked]>
Date: Mon, 20 Mar 2006 16:47:01 -0800

Haseeb,

I recently noticed your I-D and found this thread that
discussed several points.  I'm hoping to get clarification
on-list or in SIPPING.

Your draft is doing both compression and some 'policing' functions,
specifically it is policing the 'c=' line from the client by deleting
it if present.  This gives me some concerns especially around ICE and
especially around IPv6 migration.  While wireless devices, today, are
thought of by 3GPP as monolithic, there is a desire to have NAT
devices which integrate wireless cards for their network access link.

I am also concerned the draft seems to impose restrictions on the
From: address.  I admit to not fully grasping the reasons behind this,
but it appears to be another policing function to prevent a user from
spoofing another user.

P-Contact-List-Location seems to configure the UA.  I'm unclear how
this relates to header reduction.  Others in section 4 brought the
same question to mind (P-Encode-Security which appears to enumerate
3GPP security options, but I'm not sure if this is trying to tell the
handset which to use for this network or what).

I found it interesting that you published a sigcomp dictionary because
the other question I had as reviewing
akhtar-sipping-header-reduction-00 is that much of its compression
seems solvable by changing sigcomp.  For example, it seems valuable
for sigcomp to help compress things like "my own IP address" and "my
>From address", as they occur often in SIP and SDP, so I was surprised
you chose to create a new layer of compression between the SIP
application and SigComp rather than extending SigComp to do this
compression.

-d

> -----Original Message-----
> From: Haseeb Akhtar [mailto:[email-masked]] 
> Sent: Thursday, March 02, 2006 4:53 PM
> To: [email-masked]
> Cc: Thomas Barkel; Dave Brombal; Anthony Jones
> Subject: [Sipping] Re: I-D 
> ACTION:draft-akhtar-sipping-header-reduction-00.txt
> 
> Hello Jonathan, 
> 
> Thanks for your response. You are right about the details of 
> the justification of this proposal has been left out from the 
> draft. We can certainly include them in the next revision. 
> Anyway, here is why Sigcomp can not solve this problem.
> 
>    Invite (both originating and terminating) has to have the high
>    compression rate.  Sigcomp, however, is not designed to provide
>    maximum compression in the first set of messages (only message
>    that goes between the UA and the Proxy server before Invite is
>    the Register message).  Additionally, the SIP/SDP static
>    dictionary does not have some of the wireless specific data
>    elements that are included in the initial Invite message.
>
>  - Owing to the above facts, an initial SIP Invite can not be
>    reduced to ~210 bytes using Sigcomp approach.  We believe the
>    proposed draft along with new data elements in the static
>    dictionary (that are inclusive of the SIP/SDP static dictionary
>    as specified by RFC 3485) will accomplish this objective.  Please
>    see <draft-akhtar-sipping-3g-static-dictionary-00.txt>
>  - Using the signaling channel of the wireless access network allows
>    the SIP session to be initiated simultaneously while The RF
>    resources are being acquired.  A feature called DoS (Data over
>    Signaling) in 1xEVDO (the CDMA technology of 3GPP2) is a case in
>    point here.  Other wireless technologies would also allow smaller
>    payloads (< 200 bytes) to be Transferred over the signaling
>    channel.
>
>  - Assuming very optimistic compression ratio of 50% (by using
>    Sigcomp), an 1000-byte SIP Invite will be reduced to 500 bytes.
>    An IMS based initial SIP Invite is typically in the range of 1200
>    bytes.
>

> Its not clear from reading this document why everything in 
> here cannot be accomplished with sigcomp alone. The basic 
> idea, if I understand right, is that, upon registration, the 
> proxy server stores certain information about the UA which is 
> not expected to change from request to request, and it 
> repopulates it when a UA emits a request (which won't contain 
> that information). That is more or less equivalent to placing 
> that information into a sigcomp dictionary and then using 
> sigcomp to ask the server to extract the information from the 
> dictionary.
> 
> Thanks, 
> Jonathan R. 
> 	Title : New SIP Headers for Reducing SIP Message Size 
> Author(s) : H. Akhtar, et al.
> 	Current SIP messages are text based and inherently 
> large, especially
> 	wireless access technologies (a typical orginiating SIP 
> Invite is about 1200 bytes).
> 	
> 	For most wireless technologies, transmitting the 
> session initiation messages (such as SIP Invite) over the 
> signaling channel can reduce the call setup time 
> substantially. The size limitation of these wireless 
> signaling channels are typically very small (~210 bytes in 
> the uplink and ~110 bytes in the downlink).
> 	
> 	To address this problem, a new function called Encoding 
> Assitant (EA) has been introduced in the User Agent (UA) and 
> in the SIP Proxy server within the network. Additionally, the 
> method provided in this document defines new SIP option tags 
> and headers. These new option tags and headers allow the UA 
> and a SIP Proxy server within the network (such as the 
> P-CSCF), to exchange information using the signaling channels 
> http://www.ietf.org/internet-drafts/draft-akhtar-sipping-heade
> r-reduction-00.txt 
> <http://www.ietf.org/internet-drafts/draft-akhtar-sipping-head
> er-reduction-00.txt>  
> 	
> 	To remove yourself from the I-D Announcement list, send 
> a message to i-d-announce-request at ietf.org with the word 
> unsubscribe in the body of the message. You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> <https://www1.ietf.org/mailman/listinfo/I-D-announce>  to 
> change your subscription settings.
> 	
> 	
> 	Internet-Drafts are also available by anonymous FTP. 
> Login with the username 
> 	"anonymous" and a password of your e-mail address. 
> After logging in, 
> 	http://www.ietf.org/shadow.html 
> <http://www.ietf.org/shadow.html>  or 
> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt> 
> 	
> 
> 
>