headers
Dutt Kalapatapu | 1 Apr 2008 08:52

Re: Session-Expires header value less than Min-SEheader value in INVITE request

You might be stretching your limits by sending 400 and here's why

1) The one sending INVITE can't figure out the actual error
2) Some UE's(Clients) may drop the message instead of retrying with a
new INVITE with modified Session-Expires
3) Some SBC's may block the user (IP) as the client is sending invalid
messages.

-Dutt

-----Original Message-----
From: sip-implementors-bounces <at> lists.cs.columbia.edu
[mailto:sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of
Jagan Mohan
Sent: Monday, March 31, 2008 11:19 AM
To: SIP Implementors
Subject: [Sip-implementors] Session-Expires header value less than
Min-SEheader value in INVITE request

Hi,

   If Session-Expires header value is less than Min-SE header value in
the
INVITE request sent, is it ok to send a "400 Response" since it's in
violation of RFC 4028?

TIA,
Jagan
_______________________________________________
Sip-implementors mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vijay.KS | 1 Apr 2008 14:35
Favicon

pres Uri

Hi,
Can a pres Uri have port information?
i.e. whether the following pres Uri is correct?

            pres:abc <at> 10.203.225.100:12345

Thanks and Regards,
Vijay K S

"DISCLAIMER: This message is proprietary to Aricent  and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should
not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in
error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you
are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no
responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
Permalink | Reply | 0 comments |
headers
Pascal Maugeri | 1 Apr 2008 15:09
Picon

Can NOTIFY replace PUBLISH ?

Hi

I've seen that my VoIP client X-Lite is sending NOTIFY request to publish
changes in its availability. I was expecting to see PUBLISH request instead
of NOTIFY ...

Is it so that one could use NOTIFY instead of PUBLISH request ?

I'm curious to know where this is defined in standard. Please tell me if
there is any RFC or reference document talking about this.

Regards,
Pascal
Permalink | Reply | 3 comments |
headers
Iñaki Baz Castillo | 1 Apr 2008 15:27
Picon

Re: Can NOTIFY replace PUBLISH ?

El Tuesday 01 April 2008 13:09:17 Pascal Maugeri escribió:
> Hi
>
> I've seen that my VoIP client X-Lite is sending NOTIFY request to publish
> changes in its availability. I was expecting to see PUBLISH request instead
> of NOTIFY ...
>
> Is it so that one could use NOTIFY instead of PUBLISH request ?

No, PUBLISH is to inform a presence server about our state.
NOTIFY is what a presence server sends to a subscriber to notify the state of 
a subscribed user.

XLite allos two way for presence:

- Client to Client: In this way (the default one !!!!) XLite is a presence 
client and PRESENCE SERVER (so it manages also NOTIFY's as presence server). 
In this way there is no need of a presence server.

- Presence Agent: This mode expects that the SIP proxy allows SUBSCRIBE and 
PUBLISH events, so the proxy is also a presence server (or teh proxy forward 
those messages to a presence server). In this way the presence server sends 
NOTIFY to the clients and receive PUBLISH and SUBSCRIBE from them.

> I'm curious to know where this is defined in standard. Please tell me if
> there is any RFC or reference document talking about this.

There are a lot:
  http://tools.ietf.org/html/rfc3265
  http://tools.ietf.org/html/rfc3856
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pascal Maugeri | 1 Apr 2008 15:55
Picon

Re: Can NOTIFY replace PUBLISH ?

Very interesting this peer-to-peer presence mode ! I did not see this
configuration option.

Of course all clients should be in the same mode I guess ?

Gracias Iñaki
-pascal

On Tue, Apr 1, 2008 at 3:27 PM, Iñaki Baz Castillo <ibc <at> in.ilimit.es> wrote:

> El Tuesday 01 April 2008 13:09:17 Pascal Maugeri escribió:
> > Hi
> >
> > I've seen that my VoIP client X-Lite is sending NOTIFY request to
> publish
> > changes in its availability. I was expecting to see PUBLISH request
> instead
> > of NOTIFY ...
> >
> > Is it so that one could use NOTIFY instead of PUBLISH request ?
>
> No, PUBLISH is to inform a presence server about our state.
> NOTIFY is what a presence server sends to a subscriber to notify the state
> of
> a subscribed user.
>
> XLite allos two way for presence:
>
> - Client to Client: In this way (the default one !!!!) XLite is a presence
> client and PRESENCE SERVER (so it manages also NOTIFY's as presence
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iñaki Baz Castillo | 1 Apr 2008 16:17
Picon

Re: Can NOTIFY replace PUBLISH ?

El Tuesday 01 April 2008 13:55:21 Pascal Maugeri escribió:
> Very interesting this peer-to-peer presence mode ! I did not see this
> configuration option.
>
> Of course all clients should be in the same mode I guess ?

Right.

--

-- 
Iñaki Baz Castillo
ibc <at> in.ilimit.es
Permalink | Reply | 0 comments |
headers
Robert Sparks | 1 Apr 2008 17:02
Favicon

Re: Why "Content-Length" is just mandatory in TCP? (in UDP if there isn't it assumes 0 bytes)

3261 says you SHOULD include the Content-Length on UDP. That's only  
not a MUST because
there was some deployed 2543 stuff at the time that 3261 went out.

3261 does not say a missing Content-Length means a length of 0. It says
"If the message
    has no Content-Length header field, the message body is assumed to
    end at the end of the transport packet.
" (see section 18.3, page 147).

Can you point to where the text led you to believe it should be  
considered 0?

RjS

On Mar 28, 2008, at 6:04 PM, Iñaki Baz Castillo wrote:

> Hi, AFAIK reading RFC 3261, using UDP the header Content-Length is not
> mandatory and if it doesn't appear it's considered 0.
>
> But using TCP Content-Length is mandatory. I understand that in TCP  
> the same
> connection can handle lost of messages while in UDP a message fills  
> exactly
> one UDP datagram.
>
> Why content length is not set to zero if Content-Length doesn't  
> exist in a TCP
> SIP message?
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iñaki Baz Castillo | 1 Apr 2008 17:02
Picon

Re: Why "Content-Length" is just mandatory in TCP? (in UDP if there isn't it assumes 0 bytes)

El Tuesday 01 April 2008 15:02:26 Robert Sparks escribió:
> 3261 says you SHOULD include the Content-Length on UDP. That's only
> not a MUST because
> there was some deployed 2543 stuff at the time that 3261 went out.

I haven't read anywhere that it SHOULD include Content-Length in UDP request:
6231 says:

 18.3 Framing
   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, they MUST be
   discarded.  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, the
   element SHOULD generate a 400 (Bad Request) response.  If the message
   has no Content-Length header field, the message body is assumed to
   end at the end of the transport packet.

Maybe it appears in other place as SHOULD?

> 3261 does not say a missing Content-Length means a length of 0. It says
> "If the message
>     has no Content-Length header field, the message body is assumed to
>     end at the end of the transport packet.
> " (see section 18.3, page 147).

Yes, it was an understanding failure of mine. Thanks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank W. Miller | 1 Apr 2008 17:55

Re: Why SIP abnf is so permissive???


I've been following this discussion for a bit.  I agree that the grammar is
probably overly permissive but it is what it is.  Just for fun, I decided to
contribute a bit here.  In my implementation, I run the following little
preprocessor bit over all incoming messages.  The idea is to try to put the
message in a little bit more "normal" form prior to parsing.  This code is
part of the Asterisk implementation as well when the "pendantic" option is
turned on.  It does a single pass over the message and collapses it
"in-place" in the provided buffer.  It can probably be improved so I'm
interested in any and all comments.  No license on this, use it as you
will...

#include <ctype.h>
#include <stdlib.h>

int
lws2sws(char *msgbuf, int len)
{
	int h = 0, t = 0;
	int lws = 0;

	if (msgbuf == NULL)
		return (-1);

	for (; h < len;) {
		/* Eliminate all CRs */
		if (msgbuf[h] == '\r') {
			h++;
			continue;
		}
(Continue reading)

Permalink | Reply | 10 comments |
headers
M. Ranganathan | 1 Apr 2008 18:56
Picon
Gravatar

Re: Why SIP abnf is so permissive???

On Tue, Apr 1, 2008 at 11:55 AM, Frank W. Miller <fwmiller <at> cornfed.com> wrote:
>
>
>  I've been following this discussion for a bit.  I agree that the grammar is
>  probably overly permissive but it is what it is.  Just for fun, I decided to
>  contribute a bit here.  In my implementation, I run the following little
>  preprocessor bit over all incoming messages.  The idea is to try to put the
>  message in a little bit more "normal" form prior to parsing.  This code is
>  part of the Asterisk implementation as well when the "pendantic" option is
>  turned on.  It does a single pass over the message and collapses it
>  "in-place" in the provided buffer.  It can probably be improved so I'm
>  interested in any and all comments.  No license on this, use it as you
>  will...
>
>

I think line folding was not a terribly good idea. It complicates the
parser and costs some processing overhead. As for the other stuff
people complain about ( too many spaces and tabs and what not) - they
are trivial to deal with. Yes you can produce terrible looking legal
messages but any sensible implementation would not emit such messages.

The problem is that a legal implementation *Could* emit such messages
so we cannot use hindsight and tighten up the grammar.

Oh incidentally, you can produce awfully formatted legal c++ syntax
too but nobody would suggest we tighten up c++ grammar and make it
more like python for reasons of readability. What is done is done.

Ranga
(Continue reading)

Permalink | Reply | 0 comments |

Gmane