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

["Dan Wing" <[e-mail]>]

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:[e-mail]] 
> Sent: Thursday, March 02, 2006 4:53 PM
> To: [e-mail]
> 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.
> 
>  - 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>
>    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-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, 
> 	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 
> <http://www.ietf.org/shadow.html>  or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
> <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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP