Subject: [Sip] OUTBOUND: How far does a request go?

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 2 Mar 2006 14:24:57 +0100

Hi,

One thing, which I haven't seen being discussed in the "Outbound and
STUN Keep Alive" thread:

Assuming we DO use a SIP method to keep the NAT binding open, the
questions is whether the request should be terminated by an edge proxy
"on the other side" (from a UA perspective) of the NAT, or if the
request should go all the way to the registrar (scenario shown in
chapter 4.3 of the draft).

In IMS, the edge proxy would be the P-CSCF, while the S-CSCF would be
the registrar. I am not sure one would like to require the P-CSCF to
forward the NAT keep-alive requests towards the S-CSCF, because it would
only cause unecessary extra traffic in the IMS network. So, for this
reason methods like OPTIONS cannot be used, because OPTIONS WILL be
forwarded by a P-CSCF. So, either the edge proxy must know that it can
terminate certain requests, OR the requests must be addressed to the
edge proxy itself (instead of the registrar).

And, IF we assume there is no proxy between the UA and the NAT, the
double CRLF "proxy problem" would not be an issue, since no proxy would
be supposed to forward the double CRLF. Of course, there may still exist
other issues with the double CRLF mechanism. A STUN request would also
be terminated by the edge proxy on the other side, I assume.

And, if there IS a proxy between the UA and the NAT, I guess that proxy
would have to send the double CRLFs. I don't really see a difference
whether whatever-we-come-up-with has to be implemented in the UAs, or in
the proxy between the UA and the NAT...

Regards,

Christer
_______________________________________________
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: Thu, 2 Mar 2006 11:56:33 -0600

On Mar 2, 2006, at 7:24 AM, Christer Holmberg ((JO/LMF)) wrote:

> One thing, which I haven't seen being discussed in the "Outbound  
> and STUN Keep Alive" thread:
>
> questions is whether the request should be terminated by an edge  
> proxy "on the other side" (from a UA perspective) of the NAT, or if  
> the request should go all the way to the registrar (scenario shown  
> in chapter 4.3 of the draft).
>
> In IMS, the edge proxy would be the P-CSCF, while the S-CSCF would  
> be the registrar. I am not sure one would like to require the P- 
> CSCF to forward the NAT keep-alive requests towards the S-CSCF,  
> because it would only cause unecessary extra traffic in the IMS  
> network. So, for this reason methods like OPTIONS cannot be used,  
> because OPTIONS WILL be forwarded by a P-CSCF. So, either the edge  
> proxy must know that it can terminate certain requests, OR the  
> requests must be addressed to the edge proxy itself (instead of the  
> registrar).
>
> double CRLF "proxy problem" would not be an issue, since no proxy  
> would be supposed to forward the double CRLF. Of course, there may  
> still exist other issues with the double CRLF mechanism. A STUN  
> request would also be terminated by the edge proxy on the other  
> side, I assume.
>
> And, if there IS a proxy between the UA and the NAT, I guess that  
> proxy would have to send the double CRLFs. I don't really see a  
> difference whether whatever-we-come-up-with has to be implemented  
> in the UAs, or in the proxy between the UA and the NAT...

If we get into the use case of "there is a NAT between the edge proxy  
and the registrar", then we have a problem if the edge proxy  
terminates the keepalive.

I currently believe that this is a separate case, and that edge  
proxies may well need to do continuity checking to their upstream  
proxies and perhaps do something like "outbound" along with  
connection reuse, but people have raised the case in the context of  
the current draft (which touches on it, I believe).

--
Dean