Hi Jonathan,
yes, before sending INVITE user can decide about TCP or UDP but it
only reduces the probability.Presently SIP does not specify any formal
mechanism in this situation .There are other problems as well:
1. MTU itself can change when INVITE routes through different network here
MTU value can be smaller
2. One via entry is somewhere around 30-50 bytes .It means for 10 entries
there will be increase of 300-500 bytes (!!!) .
Possible solutions are :
1. Proxy can become controlling entity .It should be allowed to switch
transport.
It should forward SIP message and propagate this informational response
code to
UAC ,like "transport mechanism changed ".
Proxies may cache previous INVITE requests for particular destinations
.This will provide them prior info about which transport mechanism to use .
2. SIP protocol should support application level fragmentation mechanism
,similar to application level response codes(2xx,3xx etc )
3.Only Compressed format should be used so that number of bytes in SIP
message can be reduced .
For ex. instead of "From:", "To:" we should always use "f:","t:" etc .
parametres should also be compressed for ex : instead of "transport=" use
"tp=" etc.
Advantages are less processing power required at the time of parsing ,
reduced risk of exceeding MTU
It requires support for compressed format at all SIP entities
regards, vishal
Vishal ,
Knowledge Systems Pvt Ltd ,INDIA
470, East End Main Road
9th Block Jayanagar ,
Bangalore 560 069
Telephone: +91-80-6545252
----- Original Message -----
From: Jonathan Rosenberg <[EMAIL PROTECTED]>
To: vishal <[EMAIL PROTECTED]>
Cc: Bobby Sardana <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, May 02, 2002 5:20 AM
Subject: Re: [Sip] request/response over different transport
> We thought about this problem a great deal for bis. The conclusion was
> that sending the response over a different transport was too complex and
> broke too many sip assumptions that exist throughout the spec.
>
> Instead, the spec mandates the use of TCP when you are within a few
> hundred bytes of the MTU. The few hundred byte headroom exists to handle
> the majority of the cases Record-Route will cause an increase in the
> response size. This doesn't guarantee that you won't get a response that
> exceeds the MTU, but it reduces its probability.
>
> more below.
>
> vishal wrote:
> >
> > Hi Bobby,
> > you are correct if message size is less than MTU size then
> > response must be over UDP .....
> >
> > some other problems are :
> >
> > when proxy forwards INVITE requests .It adds "Via:" field into it along
> > with appropriate parametres ....if message is forwarded by many proxies
> > then this message may become greater than MTU size in particular network
> > ....how this case should be handled ?
> > should next proxy establish TCP connection and then forward it OR
> > reject this message?
>
> Establish a TCP connection. This is discussed in Section 18 of bis.
>
> >
> > If proxy forwards this message using TCP and UAS receives INVITE over
> > TCP then UAS response will be sent over TCP and UAC should be prepared
> > to receive response over TCP or UDP for its previous INVITE over UDP
> > request.
>
> UDP. There is a proxy that straddles UDP/TCP. It will receive the
> resposne over TCP, and forward it towards the UAC over UDP.
>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue
> Chief Scientist First Floor
> dynamicsoft East Hanover, NJ 07936
> [EMAIL PROTECTED] FAX: (973) 952-5050
> http://www.jdrosen.net PH: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [EMAIL PROTECTED] for questions on current sip
> Use [EMAIL PROTECTED] for new developments on the application of sip
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
