SHIV SINGH wrote:
> Hi All,
> Now I am clear about the handling of ACK.
> Mime-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain; charset=us-ascii
>
> Please can you put some light on the issue of 200OK:
> Should I stop the re-transmission of 200OK after getting Wrong ACK or
Hi All,
I have a question on SIP MIBs described in RFC 4780.
sipCommonStatusCodeTable has sipCommonStatusCodeMethod as an object
with uniquely identifies
a conceptual row. But the definitions of rest of the MIB objects in
the table does not specify any relation
with sipCommonStatusCodeMethod. For
Hi All,
Now I am clear about the handling of ACK.
Please can you put some light on the issue of 200OK:
Should I stop the re-transmission of 200OK after getting Wrong ACK or I need to
continue?
Because after getting ACK even with wrong content-length, state of call is
getting changed from complet
From: SHIV SINGH <[EMAIL PROTECTED]>
If UAS is getting the ACK with content-length more than the actual
body length and all the headers are correct?
(I assume you mean "all the *other* headers are correct", as you're
assuming that Content-Length is incorrect.)
As others have noted, RFC
El Miércoles, 18 de Junio de 2008, Attila Sipos escribió:
> I can't answer why Nortel hasn't used "sip:[EMAIL PROTECTED]"
> but I can say that a most vendors have some non-RFC'd behaviour.
>
>
> This happens because:
> 1. sometimes things are made-up before a standard has been fixed
> 2. then the s
In section 5.7 we have:
5.7. Connection Data ("c=")
c=
each of the components between the brackets is mandatory
"c=IN IP4 " is not allowed but "c=IN IP4 0.0.0.0" would be ok.
Regards,
Attila
From: Vishwas Bharadwaj [mailto:[EMAIL PROTECTED]
Thanks attila, Where can i find more specifics of it being an error
mentioned.. i mean is it in any of the RFC.
RFC 4566(SDP) mentions
*"In general, the "o=" field serves as a globally unique identifier for
this version of this session description, and the subfields excepting
the version ta
it's an error. (it is not valid SDP)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Vishwas Bharadwaj
Sent: 18 June 2008 14:50
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] SIP message with SDP content with
differentscenarios
I can't answer why Nortel hasn't used "sip:[EMAIL PROTECTED]"
but I can say that a most vendors have some non-RFC'd behaviour.
This happens because:
1. sometimes things are made-up before a standard has been fixed
2. then the standard is published but non-standard behaviour
doesn't always get
Hi all,
Can a SDP content have a Connection field without an IP address to be
more precise...
Case 1: "c=IN IP4 192.168.1.2 " (Normal scenarion)
Case 2: "c=IN IP4 " (No I P address is mentioned)
Shud an SDP Parser Raise an Error on Case 2 or shud it parse the Message and
pass on to stack as
El Wednesday 18 June 2008 14:27:26 Paul Kyzivat escribió:
> I agree with Attila. I have no idea why it is being done this way. But
> since there is also a Privacy header perhaps it is assumed that you
> won't be displaying this anyway, so what it says is immaterial.
Yes, in fact when I receive and
El Wednesday 18 June 2008 09:42:57 Ranjith Reddy V escribió:
> Hi ALL,
>
> What should be the behavior of UAC, if UAS sends response in different
> transport than the request?
>
> For example UAC has sent INVITE on TCP and received 200 OK for that on UDP.
> The INVITE via header starts with SIP/2.0
> While you could simply ingore the ACK, that
> probably isn't helpful in getting things working.
I don't disagree; however my understanding is that it has the same
benefit/curse of discarding responses. Did rfc3261's recommendation
concerning discarding responses have anything to do with UDP de
I agree with Attila. I have no idea why it is being done this way. But
since there is also a Privacy header perhaps it is assumed that you
won't be displaying this anyway, so what it says is immaterial.
Paul
Attila Sipos wrote:
>>> Is it valid?
>
> it's valid in that it's parseable but
> What should be the behavior of UAC, if UAS sends
> response in different transport than the request?
It is an abnormal situation; handle however you wish. However you
likely would want to factor potential security exposures within your
consideration.
__
While you could simply ingore the ACK, that probably isn't helpful in
getting things working.
I'd be inclined to just pad out the message to the specified length.
That then may result in a body that is incorrectly formatted. But for
ACK that will only be the case if there is an ansswer in the A
> Please can you tell me the behavior of UAS in
> the following case:
> If UAS is getting the ACK with content-length more
> than the actual body length and all the headers
> are correct?
See rfc3261 section 18.3. However since there is no response for ACK,
the "SHOULD generate a 400" does no
El Wednesday 18 June 2008 13:31:41 Attila Sipos escribió:
> >>Is it valid?
>
> it's valid in that it's parseable but obviously it's not standard.
> And since it's different from "sip:[EMAIL PROTECTED]",
> it's unlikely it will have the desired effect.
>
> >>does each SIP implementation choose its o
>>Is it valid?
it's valid in that it's parseable but obviously it's not standard.
And since it's different from "sip:[EMAIL PROTECTED]",
it's unlikely it will have the desired effect.
>>does each SIP implementation choose its own hidden URI?
All should use "sip:[EMAIL PROTECTED]" but
it wouldn't
Hi, RFC 3261 says that a UAC wanting to hide its identity should use a From
like this:
sip:[EMAIL PROTECTED]
Is it the unique correct way to do it? For example, when I receive a call from
my carrier gateway (Nortel CS2K) with "Privacy: id" the From is:
sip:[EMAIL PROTECTED]
Is it valid? d
Yeah , its correct for ACK there is no response bit if we face similar
problem for any request UAS can send 400 error response.
Thanks & Regards,
Srinivas CH,
Huawei Technologis India Pvt Ltd,
7th Floor Leela Palace,
Airport Road, Bangalore-8,
Contact: (Off) 080-41117676 ext: 7023
According to RFC:
In the case of message-oriented transports (such as UDP), if the
message has a Content-Length header field, the message body is
assumed to contain that many bytes. If there are additional bytes
in
the transport packet beyond the end of the body, t
Please note that ACK no response associated with it and hence a response
cannot be sent.
On Wed, Jun 18, 2008 at 3:51 PM, srinivas <[EMAIL PROTECTED]> wrote:
> Hi,
> It's wrong according to RFC 3261: UAS supposed to send 400 (Bad Request)
> response. Check the 18.3 Framing section
> If the tran
Hi,
It's wrong according to RFC 3261: UAS supposed to send 400 (Bad Request)
response. Check the 18.3 Framing section
If the transport packet ends before the end of the message body, this is
considered an error. If the message is a response, it MUST be discarded.
If the message is a request, th
Hi All,
Please can you tell me the behavior of UAS in the following case:
If UAS is getting the ACK with content-length more than the actual body length
and all the headers are correct?
As per present behavior of our UATK we are processing the ACK(and returning
decode failure) and changing the
oh no. I've been using the "reply" technique myself (even for this mail).
Sorry.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iñaki Baz
Castillo
Sent: 18 June 2008 09:28
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Tr
El Wednesday 18 June 2008 09:42:57 Ranjith Reddy V escribió:
> Hi ALL,
Please, don't break mail threads. If you want to send a new message open a new
thread by creating a NEW mail instead of pressing "Reply" in any other non
related mail.
You pressed "Reply" over my previous mail so your mail i
Hi ALL,
What should be the behavior of UAC, if UAS sends response in different
transport than the request?
For example UAC has sent INVITE on TCP and received 200 OK for that on UDP.
The INVITE via header starts with SIP/2.0/TCP and for 200 OK SIP/2.0/UDP.
Regards
Ranjith. V
_
28 matches
Mail list logo
