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

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 17 Feb 2006 14:51:08 -0600

If client gets the response it is expecting, there is no issue. What
else it is expecting on the PING, pl
Clarify. Server is free to optimize. 

If client does some non-standard thing to PING, it's problem of the
client.

If we fix this in SIP, we can optimize the Keep alive traffic too. If
chatty IM session is going on there is
no need to send keep alive. There will be some SIP traffic induced from
session timers during the media only sessions. 
To be more precise, if there is no SIP traffic for a configured
interval, then send keep alive. 

To achive this, with STUN we need more co-operation between STUN and SIP
protocol application modules.

Thx
Samir

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Friday, February 17, 2006 8:57 AM
To: Thomas Froment
Cc: [email-masked]; Stucker, Brian [RICH1:B620:EXCH]
Subject: Re: [Sip] Outbound and STUN Keep Alive

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:

> Brian Stucker wrote:
> 
>> 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.
>>  
>>
> 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?
> 
> 
> 
> 
> _______________________________________________
> 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
> 

-- 
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

_______________________________________________
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

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Fri, 17 Feb 2006 15:42:13 -0600

> Clarify. Server is free to optimize.

And what if some future extension uses a Proxy-Require or such to  
enforce some other extension behavior, but we don't process the new  
Proxy-Require because we're not parsing the whole SIP message?

Breaks the SIP feature-negotiation model.

Danger, Will Robinson!

--
Dean

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 20 Feb 2006 10:59:06 +0100

> Breaks the SIP feature-negotiation model.

How future proof does the mechanism need to be? I don't see any 
extension to such SIP method in the near future.

Hisham

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 20 Feb 2006 14:27:44 -0500

> Breaks the SIP feature-negotiation model.

Agreed.  However the ECHOSRC request I mentioned is a 1 hop single purpose
request indicating that the headers do not need to be parsed (beyond
potentially content-length).  Thus the request is not intend to be extended.
And ECHODEFAULT could be similarly defined to request response delivery to
default port.  And ECHOVIA could be similarly defined but require full
processing on first Via entry.  

I envision it to be something like the following.  However this is an
extreme example trying to ensure request not proxied.  Thus if the working
group is overly concerned about some of these headers being echoed back,
some could obviously be removed.  Ip-addresses for From, To, and request-uri
could be sent instead of invalid.  And devices which don't support ECHOSRC
can return their favorite response based upon what they dislike first: 501,
405, 483, 420, 403, 603, 401, 407, etcetera.

>ECHOSRC sip:invalid. SIP/2.0
>Via:SIP/2.0/tcp ip-address;branch=z9hG4bKunique
>f:sip:invalid.;tag=unique   
>t:sip:invalid.
>i:unique
>CSeq:1 ECHOSRC
>Require:echo
>Proxy-Require:echo
>Max-Forwards:0
>l:0

Concerning security, devices would likely also want to validate the CSeq
method name.  Otherwise, it could make the device vulnerable to spoofing
interference with other transactions.