I think the framentaion/de-fragmentation is for the SDP content which
can not be handled by the transport layer but the applcation layer. The
TCP actually has no any knowledge on the application layer content.
Alex Zhang
ESN: 6-554-8782
-Original Message-
From: [EMAIL PROTECTED]
[mai
You could be more forgiving for UDP content greater than Content-Length:
if the actual length is greater than the number
specified in Content-Length then it does no harm to try to
parse n bytes of the content (where n equals Content-Length)
- if the content is sensible, then you can still use it
I have one question on the same topic.
If transport is TCP, Why application layer needs to support message
fragmentation and de-fragmentation with SIP header "Content Length:".
Why not Transport layer will re-assemble all the fragmented packets and send
it to higher layer ?
Thanks,
Dinesh
---
Thanks jacob.
--- Regards Arun S
- Original Message -
From: "Benjamin Jacob" <[EMAIL PROTECTED]>
To:
Cc: "Arun" <[EMAIL PROTECTED]>
Sent: Tuesday, July 01, 2008 11:57 AM
Subject: Re: [Sip-implementors] SDP Content length
To rephrase a confused line :
1. If UDP, if incorrect SDP leng
To rephrase a confused line :
1. If UDP, if incorrect SDP length received(greater or less
than advertised in the Content length) or invalid Content length, respond with
an error.
- Original Message
From: Benjamin Jacob <[EMAIL PROTECTED]>
To: sip-implementors@lists.cs.columbia.edu
Cc: A
>From the various torture tests drafts/ RFCs:
1. If UDP, if incorrect/invalid(-ve for e.g.) length (greater or less than
advertised in the Content length) , respond with an error.
2. If TCP :
a. If Content length is greater than the actual packet received, you have
to wait, as the rest of th
Hi all,
I have a problem here with the SDP content length.
Wat if the content length is less than or greater than the actual sdp
packet.
Should that packet be processed properly or it is to be discarded.
Is it a malformed packet if content length is greater or less than the
length of the SDP
El Monday 30 June 2008 11:14:22 emanuele bottegoni escribió:
> Hello,
>
> sniffing at PBX side I obtain also the following lines:
> what's the meaning ???
>
> "
> Ignoring this INVITE request
>
>
>
> <--- Transmitting (no NAT) to 0.0.0.0:5060 --->
>
> SIP/2.
Vivek,
I think the issue you talked about is how to identify which REGISTER the
200(register) responds to,
I think RFC3261 sec 17.1.3 Matching Responses to Client Transactions has
already given the solution.
Another question is if you give REGISTRA the internal ip addr, how would
you expect the
Hello,
sniffing at PBX side I obtain also the following lines:
what's the meaning ???
"
Ignoring this INVITE request
<--- Transmitting (no NAT) to 0.0.0.0:5060 --->
SIP/2.0 100 Trying
"
Thanks
___
10 matches
Mail list logo
