Subject: [Sip] Re: Outbound: TCP and SigComp

From: Rohan Mahy <[email-masked]>
Date: Sat, 1 Dec 2007 09:24:23 -0800

Hi Adam,

I believe this comment has been adressed in outbound-11 section 4.4.1:

> If sending over a SigComp [25] compressed data stream, the CRLF  
> keepalives are sent inside the compressed stream.

thanks,
-rohan

On Jul 19, 2007, at 4:15 PM, Adam Roach wrote:

> With the move to CRLF for keepalive in outbound, the language  
> discussing STUN handling with SigComp in TCP is also gone. This  
> makes sense, since TCP no longer uses STUN.
>
> However, there was no equivalent language added for how to handle  
> the CRLF keepalives in conjunction with SigComp.
>
> As with the earlier STUN mechanism, you can't just send the CRLF  
> stuff down the TCP connection -- it needs to be wrapped in SigComp.  
> Of course, we could employ the same mechanism originally proposed  
> for STUN (the well-known shim), which would be the 13-byte SigComp  
> shim, plus 2 bytes (CRLF) or 4 bytes (double CRLF).
>
> Alternately, we can shave this down a _little_ bit by using  
> bytecodes specifically designed to output just the CRLFs we need;  
> for a double-CRLF, it would look like:
>
>    at (128)
>    OUTPUT (crlf, 4)
>    JUMP(end)
>
>    :crlf byte(13,10,13,10)
>
>    :end
>    END-MESSAGE (0,0,0,0,0,0,0)
>
> Which translates to the following 14 bytes: f8 00 b1 22 a0 86 04 16  
> 06 0d 0a 0d 0a 23
>
>
> (Yes, I realize this is 14 bytes instead of the 17 bytes you get  
> with the shim, so it might not be worth using custom code).
>
> For a single CRLF, such code would end up looking like this:
>
>    at (64)
>    :crlf pad(2)
>
>    at (128)
>    LOAD (crlf, 3338)
>    OUTPUT (crlf, 2)
>    END-MESSAGE (0,0,0,0,0,0,0)
>
> Which translates to the following 11 bytes: f8 00 81 0e 86 ad 0a 22  
> 86 02 23.
>
> In practice, we're probably best off just normatively saying that  
> the CRLF characters are sent inside SigComp, and that the mechanism  
> for representing them is a matter to be handled by the SigComp  
> compressor at the sending end. We can point out the shim, and we  
> can include the foregoing purpose-built SigComp messages, but there  
> may be architectural complications to using either of them, so the  
> ultimate requirement is simply to send something that produces  
> "CRLF" as its output when it is sent.
>
> /a

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Sat, 1 Dec 2007 12:59:06 -0800

Hi Aki,

My comments inline...

On Aug 6, 2007, at 4:16 PM, Aki Niemi wrote:
> Here are my WGLC comments to sip-outbound-10. There may be  
> duplicates as
> I've only been following others' comments on the surface.
>
> ---
>
> #1 First, the title says:
>
> Managing Client Initiated Connections in the Session Initiation  
> Protocol
>                                  (SIP)
>
> yet, the draft is really about managing registrations, with  
> failover and
> reliability. For example, it is not at all clear how one would go  
> about
> implementing these techniques in, say, subscriptions (this is the  
> issue
> Markus brought up recently with the config-framework)

In outbound-11 I think I have addressed this issue. The UAC can  
include an 'ob' parameter in a dialog-forming request and expect the  
first hop proxy to record route appropriately.  This should allow the  
sip config package subscription to work.

> #2 URI parameters are confusing.
>
> o First, I don't understand why the keepalive params are needed at  
> all.
> It's simple, really: if the UAC opens a TCP flow, it needs to use  
> CRLF.
> If it opens a UDP flow, it needs to use STUN. Or am I missing  
> something?

we merged the keep-stun and keep-crlf into a simple 'keep' parameter.
this 'keep' parameter just allows the UAC to know if it will get a  
pong in response to its pings.

> (In fact, I would like to see TCP-keepalives removed completely, as  
> that
> just hurts interop.)
removed

> o Justification for 'timed-keepalives'
>
> Why does the UA need to know beforehand that it needs to use the  
> default
> interval keepalive? Could this not be returned in the 200 OK instead?
it probably could, but it is not clear where it would go in the 200 OK.

> All in all, I don't see the reason that these parameters need to be
> pre-configured to the UA as the draft suggests. Seems they are either
> self-evident (based on transport), or something the registrar/edge- 
> proxy
> could return in a header field or parameter at register-time. Much
> cleaner IMHO.
what we have may be ugly, but it will work and we appear to have  
consensus on it.

> o In 3.2. example message:
>
> REGISTER sip:example.com;keep-crlf SIP/2.0
>
> Why does this parameter need to be in the R-URI?

the parameter does not need to be there.  It could instead be in the  
topmost Route header for example.

> o In 4.3. says:
>
>    The UAC MUST also include an "ob" parameter in the
>    Contact URI if, and only if, the UAC is sending the request over a
>    flow for which the Registrar applied outbound processing.
>
> Isn't 'ob' only inserted by edge-proxies, and to Path? Furthermore,  
> how
> can the UA know that "the Registrar applied outbound processing" to a
> flow that is just about to be formed?

ob is used for two things:
- inserted in Path by the first edge proxy
- added to Contact by UA to request record-routing

> o In 5.3 says:
>
>    The Edge Proxy can use
>    the presence of the "ob" parameter in the UAC's Contact URI to
>    determine if it should add a flow token.
>
> Hmm. I thought it was the reg-id.

The edge proxy uses the presence of the reg-id in a Contact in a  
REGISTER request to add a Path header with a flow token, and the  
presence of the ob parameter in a Contact in a non-REGISTER request  
to add a Record-Route header with a flow token.

> #3 Implementation strategy
>
> How is it intended that outbound support be added to a typical single
> registrar/proxy deployment today? The spec intentionally leaves
> configuration of a proxy-set open, but somehow assumes that one exists
> in order to use outbound. Couldn't the UA just attempt a REGISTER via
> the default NAPTR/SRV and just include reg-id and instance-ID? This
> option should be made the default in the absence of a specific a  
> priori
> configuration in Section 4.2/4.3.

This should just work, but the single UA/proxy would need to return a  
Path header, otherwise the UA would have no way of discovering  
support for keepalive responses.

> #4 Keepalive timer values
>
> Like I've said in the past that 2 mins for TCP is way too low.  
> Sure, the
> UA can extend it, unless of course the proxy mandates it with
> timed-keepalive param. And of course the proxy wants high reliability,
> which means the UA is hosed probably more often than it would like  
> to ;)

> My question is: where did this 2 minutes come from? Is it based on  
> some
> hard data, like empirical evidence or user experience studies?

No.  It was pulled out of thin air.

> If not,
> how about 14 minutes instead? Much better on the battery and should
> still play nice with the NATs.

There was some expectation that the UA would be willing to lose 2  
minutes of phone calls, but 14 minutes would be a lot of time to be  
off the air.  Certainly, the UA can use something short (like 2  
minutes) for one flow, and 14 minutes for any additional flows  
without many ill effects.

> #5 Retry timer calculation formula
>
> In 4.5:
>
>    wait-time = min( max-time, (base-time * (2 ^ consecutive- 
> failures)))
>
>    These times MAY be configurable in the UA.  The three times are:
>    o  max-time with a default of 1800 seconds
>    o  base-time-all-fail with a default of 30 seconds
>    o  base-time-not-failed with a default of 90 seconds
>
> But there are only two unknowns pertaining to time in the equation
> (there is no base-time-all-fail, or base-time-not-failed -- just
> base-time that apparently is 30 sec...).

I made this more clear in -11.  The base time is either 30 secs or 90  
secs.

> #6 Definition of a ping or a pong
>
> It should be explained in the spec that a ping is double CRLF, or any
> other traffic. And same goes for a pong. I.e., the UA should only
> consider a flow dead if it receives no CRLF nor any other traffic  
> within
> 10 seconds of sending the ping.

this does not work.  receiving some other traffic does not count as a  
pong since it could be very stale data.

> #7 Very minor things:
>
> o The justification for choosing STUN as the UDP keepalive  
> mechanism is
> a little misleading. It was *claimed* that STUN would be less of a  
> load
> to proxies than a SIP OPTIONS (or similar). However, this was never
> proven in practice. There were also people saying that parsing SIP is
> not the bottleneck -- network or memory I/O is, and on that front,  
> STUN
> and SIP are equal. If anything, a SIP+STUN parser might actually have
> worse performance. Just for the record -- I've no interest to revisit
> the decision -- just getting the facts right ;)
Hear, hear!  I toned this rhetoric down a bit.

> o In 3.3
>
> The UA is configured with multiple outbound proxy registration URIs.
>    These URIs are configured into the UA through whatever the normal
>    mechanism is to configure the proxy or registrar address in the UA.
>
> The registrar address is not supposed to be configured. It is learned
> from the AoR, the name behind the '@' sign. ;)
yeah.

thanks,
-rohan

> That's all
>
> Cheers,
> Aki
>
> ext DRAGE, Keith (Keith) wrote:
>> A reminder of the ongoing WGLC on the above document
>>
>> This WGLC period runs through IETF and hopefully close August 6,  
>> 2007.
>>
>> That gives you about a week after the end of IETF - please  
>> schedule some time for doing this.
>>
>> Regards
>>
>> Keith
>>
>>
>>> -----Original Message-----
>>> From: Dean Willis [mailto:[email-masked]]
>>> Sent: Thursday, July 12, 2007 7:14 PM
>>> To: Dean Willis
>>> Cc: [email-masked]; Cullen Jennings; DRAGE, Keith (Keith)
>>> Subject: Correction: WGLC for draft-ietf-sip-outbound
>>>
>>> Dean Willis wrote:
>>>> I'd like to start a long working group last call for:
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-09.txt
>>>>
>>> My error. This should have referred to
>>> draft-ietf-sip-outbound-10, not -09. It was busy working its
>>> way through the posting system and I grabbed a pointer to the
>>> wrong one.
>>>
>>> Sorry about that, folks.
>>>
>>> --
>>> Dean
>>>
>>>
>>
>>

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 2 Dec 2007 15:06:42 -0800

Hi Adam,

I believe outbound-11 now correctly uses option-tags.

thanks,
-rohan

On Jul 19, 2007, at 5:05 PM, Adam Roach wrote:

> At the risk of further bloodying the corpse of this poor horse, I  
> still think the usage of feature tags in outbound is way, way off  
> in terms of the semantics described in 3261.
>
> Reviewing the way this is defined to work in SIP:
>
> 3261:8.1.1.9:
>>    If the UAC supports extensions to SIP that can be applied by the
>>    server to the response, the UAC SHOULD include a Supported header
>>    field in the request listing the option tags (Section 19.2) for  
>> those
>>    extensions.
>
> 3261:8.2.4:
>
>>    A UAS that wishes to apply some extension when generating the
>>    response MUST NOT do so unless support for that extension is
>>    indicated in the Supported header field in the request.  If the
>>    desired extension is not supported, the server SHOULD rely only on
>>    baseline SIP and any other extensions supported by the client.
>> ...
>>    Any extensions applied to a non-421 response MUST be listed in a
>>    Require header field included in the response.  Of course, the  
>> server
>>    MUST NOT apply extensions not listed in the Supported header  
>> field in
>>    the request.  As a result of this, the Require header field in a
>>    response will only ever contain option tags defined in standards-
>>    track RFCs.
>
> There are five normative statements in the text I quote above. The  
> mechanism described in the outbound draft actually manages to  
> violate _all_ _five_ of them.
>
> The registrar infers *both* support for outbound *and* a request to  
> apply the outbound extension by the presence of the "reg-id"  
> Contact header field parameter. In particular, the client is  
> apparently NOT supposed to send a "Supported: outbound" header  
> field. This appears to contravene the normative statement in  
> 8.1.1.9 cited above.
>
> The registrar indicates that outbound procedures are being applied  
> by including a "Supported" header field in the REGISTER response.  
> (In 3261, "Supported" in a _response_ indicates that an extension  
> _can_ _be_ supported in a future request, NOT that it is being  
> applied to the current one -- sections 11 and 13.3.1.4 both talk  
> about Supported usage in responses.)
>
> In other words, the registrar (acting as a UAS) is applying an  
> extension when generating a response without that extension being  
> indicated in the "Supported" header field in the request. Again,  
> this directly contravenes two normative statements from section  
> 8.2.4 (cited above).
>
> The registrar is further applying an extension to a non-421  
> response that is not listed in a "Require" header field, in  
> violation of the remaining normative statement in the portion of  
> section 8.2.4 cited above.
>
> Why are we doing this so very, very wrong? It's almost as if we've  
> gone out of our way to violate both the spirit AND the law of  
> feature tag handling in as many ways as possible. Most annoyingly,  
> we get exactly the desired behavior if we just do things the way  
> they're described in 3261. To wit:
>
>    * If a client supports outbound, it includes "Supported: outbound"
>      in all REGISTER requests, regardless of whether the specific
>      request makes use of that extension.
>
>    * The client adds a "reg-id" header field parameter to any Contacts
>      to which outbound processing is to apply.
>
>    * The registrar includes "Require: outbound" in any REGISTER
>      requests to which outbound behavior is being applied.
>
>    * The registrar is free to include "Supported: outbound" in any
>      responses it generates -- and it means exactly what 3261 intends
>      it to mean: that outbound is *supported*, but is not being  
> applied
>      to the response in question.
>
> /a

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 2 Dec 2007 18:55:59 -0800

Hi Jeroen,

In outbound-11, the UAC includes the 'ob' parameter in its Contact in  
dialog-forming requests if it wants the first-hop to Record-Route  
with a flow token. This language is flexible enough that it allows an  
implementation to use a GRUU in its contact instead (once it has  
one), to implement outbound without GRUU, and to send an initial  
SUBSCRIBE for the SIP config event package before registration.

I believe this addresses your comment.

thanks,
-rohan

On Jul 20, 2007, at 11:45 AM, Jeroen van Bemmel wrote:

> Rohan,
>
> The flag is needed, but you could make it a header parameter rather  
> than a URI parameter (both for Contact and for Path).
>
> There is no need for it to appear in the request URI of mid-dialog  
> requests. The EP can use its own convention to encode the flag, due  
> to things like GRUU it cannot rely on the 'ob' parameter being in  
> the request URI anyway.
>
> Regards,
> Jeroen
>
> Rohan Mahy wrote:
>> On Jul 20, 2007, at 9:06 AM, Rohan Mahy wrote:
>>
>>> Hi Adam,
>>>
>>> What can I say but "You're right".  Unless there is some
>>> fundamental objection, I will make this change pronto to my working
>>> copy.
>>>
>>> I believe this also means I can remove the 'ob' parameter from the
>>> UAC's Contact header.
>>
>> On further thought, I realized that the 'ob' parameter is still
>> needed, since it reflects whether the UAC is sending over a flow for
>> which out bound processing is being applied, as opposed to merely
>> indicating the UAC is capable of requesting outbound.
>>
>> thanks,
>> -rohan
>>

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 2 Dec 2007 18:55:54 -0800

Hi Jeroen,

thanks,
-rohan

---

From: Aki Niemi <[email-masked]>
Date: Mon, 03 Dec 2007 01:41:22 -0800

Inline.

> pong in response to its pings.

Huh? Sending the pong is mandatory.

> it probably could, but it is not clear where it would go in the 200 OK.

How about Flow-Expires: 120

> what we have may be ugly, but it will work and we appear to have  

I remember some very wise advice on these sorts of things: a spec is
ready only when there are no non-critical features left to remove. 

I think this is definitely one such feature. More below.

> topmost Route header for example.

You mean could, SHOULD, or MUST?

</snip>

> support for keepalive responses.

Again, what purpose does the keep parameter then server?

> off the air. 

We don't have that today. In fact, today we have a one hour
re-registration interval, and I don't see a lot of people complaining.

> Certainly, the UA can use something short (like 2  

2 minutes is too short. It drains the battery. Do you think having an
additional flow in addition to the 2-minute flow will improve the
situation?

Cheers,
Aki

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 3 Dec 2007 14:44:40 -0800

Hi Aki,

Don't shoot the messenger  ;-)

I think most of our disconnect here is based on the ability to do  
keepalives outside of outbound.

We had consensus to make the document so someone could implement STUN  
keepalives over UDP that does not implement outbound.   This  
motivated the keep-stun URI parameter, later merged into the keep URI  
parameter.

Since the correct keepalive responses are required by the first hop  
when doing outbound, the UAC *could* infer the ability to send  
keepalive pings and receive pongs based on the a successful outbound  
registration working over the same flow.

We could get rid of the keep parameter for outbound registration and  
only use it in non-outbound keepalive uses (and move the definition  
to section 8), but we would need to get the consensus of the WG to do  
that.

More brief comments inline...

> Huh? Sending the pong is mandatory.

if the implementation supports outbound. (see above)

> How about Flow-Expires: 120

I like it, but we need consensus to switch to that.

> You mean could, SHOULD, or MUST?

whether the parameter is there or not is a by product of where it  
appears (in which URIs).  depending on where the URI came from , it  
gets copied to various places.  outbound does not change those rules.

> Again, what purpose does the keep parameter then server?

again, we would need to agree to assume that an outbound registration  
is "good-enough".  This is certainly safe for any server that  
correctly implements the spec.

> additional flow in addition to the 2-minute flow will improve the

I'm not the one you need to convince here. ;-)
thanks,
-rohan