The discussion was of the presence or absence of type and not length.
Yes, Content-Length has restrication based on transport used.
On Fri, Apr 24, 2009 at 2:08 PM, Dale Worley wrote:
> On Mon, 2009-04-20 at 16:16 -0700, Vikram Chhibber wrote:
>> For the above context, yes, we should be lenient e
On Mon, 2009-04-20 at 16:16 -0700, Vikram Chhibber wrote:
> For the above context, yes, we should be lenient enough to recieve or
> not receive the type if length is 0.
> But we can not generalize as it very much depends on the type and context.
This isn't lenience, it is mandatory. Even if the C
On Tue, 2009-04-21 at 12:57 +, SungWoo Lee wrote:
> In case of answering back with 200 OK message, the answerer can figure
> out the destination rtp port number after checking where the received
> rtp packets are coming from. No matter what rtp port is used in the
> dummy router, the answerer s
Registration for SIPit 24 closes April 30. If you are not yet
registered, but plan to attend, please register now.
SIPit 24 will be held May 18-22, 2009 in Akihabara, Tokyo, Japan
hosted by JPNIC and NICT.
Additional information is available at http://www.sipit.net and
http://www.nic.ad.jp/en/s
We also keep running into implementations that use TO for call routing instead
of R-URI. It seems to be more of a billing / implicit registration deployment
where they use the main number for registration which is the Request URI while
the real DID (DDI) is in the To header.
Am not sure if RFC
I think RFC3261 is quite clear that routing of incoming SIP calls should be
done based on the Request-URI and not on the TO field.
I.e. the Request-URI is the current called party number (CPN) and the TO should
be considered the original called number (OCN).
Yet I am running into trouble with ot
