Subject: RE: [Sip] Outbound and STUN Keep Alive

From: "Brian Stucker" <[email-masked]>
Date: Thu, 16 Feb 2006 13:53:55 -0600

How can you send a 200 OK without parsing out the Via header fields?
How do you get the cseq without parsing that out?

-- Don't. Send the message back where it came from using the transport information in the packet and reuse the existing information in the request to form a valid response. You only need to add information to the end of the packet (in the form of a message body or header) to report what you saw from the UA in terms of their observed network address.

Very fast. Of course the UA gets to eat it's own dog food if it sends something bad in the request.

Regards,
Brian

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Wednesday, February 15, 2006 11:00 PM
To: Stucker, Brian [RICH1:B620:EXCH]
Cc: Audet, Francois [SC100:9T51:EXCH]; Cullen Jennings; [email-masked];
[email-masked]
Subject: Re: [Sip] Outbound and STUN Keep Alive

On Feb 15, 2006, at 10:10 PM, Brian Stucker wrote:

> Dean, et. al-
>
> Keep in mind one thing in your calculations... Parsing a MESSAGE  
> that is short (which may or may not be a message that needs further  
> processing) cannot be separated from "service" traffic as easily as  
> PING. Once I've parsed the request type I immediately know that I'm  
> dealing with a special case and can shunt processing over to a  
> separate chunk of code that can ignore much of the message.
>

This implementation modified the SIP UA for immediate handling of the  
MESSAGE request. It wasn't being shunted off to an application via  
the api -- the UA was immediately doing a 200-and-discard sequence.

> For instance, here would be a very simple way of parsing a PING:
>
> 1. Is the request type of the message "PING". If so, then shunt...
> 2. In the shunt parser take the original packet the PING came in on  
> and do the following:
> Replace the top of the buffer from "PING sip:xxxyyyzzz... SIP/2.0"  
> to "SIP/2.0 200". Pad the remainder with white space until you hit  
> the CRLF that terminates the request URI.
> 3. Append the correct header information to bottom of the packet to  
> identify the source of the request.
> 4. Send the packet back from whence it came.
>
> (Potentially) no data that needs to be copied and nothing other  
> than the first five characters of the message needs to be parsed.
>

How can you send a 200 OK without parsing out the Via header fields?

How do you get the cseq without parsing that out?

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Thomas Froment <[email-masked]>
Date: Fri, 17 Feb 2006 15:55:14 +0100

>Very fast. Of course the UA gets to eat it's own dog food if it sends something bad in the request.
If you don't look at Via header to answer a SIP request, and just send a 
"packet" back to the source IP Address/port, you are not doing SIP anymore,
you are doing a "hack". In this case, this is no more "clean" than 
double CR/LF or STUN.
Just to insist a last time on this topic: the most important point for 
me is *consistency* with other parts of sip-outbound draft, as Chris 
mentionned: "It is already specified for UDP in the Outbound draft", so 
why not use the same thing for TCP?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 Feb 2006 11:57:03 -0500

Actually, having a special code path that processes this SIP PING in a 
fundamentally different way is worse, IMHO. You are not only basically 
muxing a separate protocol on the same port anyway, you are breaking SIP 
by applying non-standard processing to it. I think you stand a much 
worse chance of interop failures with an implementation that processes 
SIP in a non-standard way. A client might send a PING, assuming it gets 
processed correctly, and then gets surprised when its basically being 
treated like a STUN request formatted as a sip mesage. How about we just 
send that stun request in the first place.

-Jonathan R.

Thomas Froment wrote:

>> -- Don't. Send the message back where it came from using the transport 
>> information in the packet and reuse the existing information in the 
>> request to form a valid response. You only need to add information to 
>> the end of the packet (in the form of a message body or header) to 
>> report what you saw from the UA in terms of their observed network 
>> address.
>>

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 17 Feb 2006 11:58:11 -0500

> If you don't look at Via header to answer a SIP request, 
> and just send a "packet" back to the source IP Address/port, 
> you are not doing SIP anymore, you are doing a "hack". 

How is it a hack to define a new SIP request which by definition requires
rport added to Via (or similar mechanism to request source only) and
Max-Forwards is 0 (or something similar mechanism to avoid it being
proxied)?

---

From: Thomas Froment <[email-masked]>
Date: Fri, 17 Feb 2006 18:14:47 +0100

>Max-Forwards is 0 (or something similar mechanism to avoid it being
rport does  not modify the way you handle the request, from RFC 3261 
point of view, you still create a Server Transaction
to answer and to handle retransmissions (parsing via and using branch 
parameter  + sent-by of Via as transaction ID)...
If I understood well, your suggestion was to completely skip these steps 
and just answer to the transport source port/ip... thus,
that's why I say this is no more a SIP response...

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 17 Feb 2006 12:50:43 -0500

> > How is it a hack to define a new SIP request which 
> > by definition requires rport added to Via (or similar 
> > mechanism to request source only) and Max-Forwards 
> > is 0 (or something similar mechanism to avoid it 
> > being proxied)?
> >  
> >
> rport does not modify the way you handle the request,
> from RFC 3261 point of view, you still create a 
> Server Transaction to answer and to handle 
> retransmissions (parsing via and using branch 
> If I understood well, your suggestion was to 
> completely skip these steps and just answer to 
> the transport source port/ip... thus,

RFC 3261 does not limit how vendors optimize their stacks.  And
draft-ietf-sip-guidelines does not preclude extensions which do not require
full parsing and analysis of a received request and response.  Thus if
vendor doesn't want to optimize their stack for the SIP extension, they
don't have to do so.

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 17 Feb 2006 16:00:27 -0500

> Actually, having a special code path that processes 
> this SIP PING in a fundamentally different way is 
> worse, IMHO. You are not only basically muxing a 
> separate protocol on the same port anyway, you are 
> breaking SIP by applying non-standard processing to it.

How is it not non standard?  Vendors currently make optimizations to their
stacks.  The potential new request just allows for some extra optimization.
Nobody is actually required to make the optimization.

> A client might send a PING, 
> assuming it gets processed correctly, and then gets 
> surprised when its basically being treated like 
> a STUN request formatted as a sip message. How 
> about we just send that stun request in the first place.

STUN has more of a capacity hit than echoing CRLFs over connection oriented
protocols.  That is why I currently prefer STUN be limited to UDP.

And for UDP, many access devices are currently flooding the network with
REGISTERs and/or OPTIONS.  And STUN is potentially better than a new
optimized SIP message; however I'm not sure how soon or how many devices
would implement it.  

Thus until STUN (if chosen) and echoing CRLFs (if chosen) are widely
supported and deployed, a new easily optimized SIP message might be
beneficial.

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 17 Feb 2006 16:20:28 -0500

Sorry about the repost... I intend to ask "How is it non standard?" :)

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brett Tate
> Sent: Friday, February 17, 2006 4:00 PM
> To: 'Jonathan Rosenberg'
> Cc: [email-masked]
> Subject: RE: [Sip] Outbound and STUN Keep Alive
> 
> 
> How is it non standard?  Vendors currently make 
> optimizations to their stacks.  The potential new request 
> just allows for some extra optimization. Nobody is actually 
> required to make the optimization.
> 
> 
> STUN has more of a capacity hit than echoing CRLFs over 
> connection oriented protocols.  That is why I currently 
> prefer STUN be limited to UDP.
> 
> And for UDP, many access devices are currently flooding the 
> network with REGISTERs and/or OPTIONS.  And STUN is 
> potentially better than a new optimized SIP message; however 
> I'm not sure how soon or how many devices would implement it.  
> 
> Thus until STUN (if chosen) and echoing CRLFs (if chosen) are 
> widely supported and deployed, a new easily optimized SIP 
> message might be beneficial.
> 
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>