Subject: RE: [Sipping] ack bug in basic call flows?

From: "Hearty, John" <[email-masked]>
Date: Thu, 12 Dec 2002 16:46:36 -0700

I'm a little troubled by this example.  Does User A know through configuration that Proxy 1 is an RFC3261 compliant proxy, and thus is OK with getting a Route header with itself at the top of the list for this initial request?  Otherwise, if Proxy 1 was an RFC2543 compliant proxy, it would not expect to see itself in the top Route header, and might do the dumb thing, popping the Route, putting it in the req uri and sending an Invite to itself then detecting a loop.  Alternately if it was an RFC2543 proxy and followed this text in section 6.29 it might just kill the call then and there:

Unless this would cause a loop, any client MUST send any
   subsequent requests for this call leg to the first Request-URI in the
   Route request header field and remove that entry.

John Hearty
Level3

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 3:15 PM
> To: [email-masked]
> Cc: Alan Johnston; [email-masked]
> Subject: Re: [Sipping] ack bug in basic call flows?
> 
> 
> hi,
> 
> I think preloaded routes should be loose routes. This allows 
> them to be 
> shorter (hostname only).  I think there is some specific language in 
> 3261 recommending a loose source route, but i don't have time to find 
> it right now.
> 
> thanks,
> -rohan
> 
> 
> 
> On Thursday, December 12, 2002, at 12:15 PM, 
> [email-masked] wrote:
> 
> > Alan Johnston writes:
> >
> >> As to why the Route header is a lr, I'm not certain - I suppose it 
> >> could be
> >> strict router.
> >
> > exactly this was my point.  rfc3216 text doesn't say if pre-loaded 
> > route
> > set which results from configuration of outbound proxy 
> should or should
> > not have lr parameter in it.
> >
> > i would say that makes more sense in that case to use strict route
> > rather than loose route, because the outbound proxy usually 
> has to be
> > the very first hop.
> >
> > in that case invite in call flow example 3.2 would look like this:
> >
> >    F1 INVITE A -> Proxy 1
> >
> >    INVITE sip:sip:ss1.atlanta.com SIP/2.0
> >    Via: SIP/2.0/TCP client.atlanta.com:5060;branch=z9hG4bK74b43
> >    Max-Forwards: 70
> >    Route: <sip:[email-masked]>
> >    From: BigGuy <sip:[email-masked]>;tag=9fxced76sl
> >    To: LittleGuy <sip:[email-masked]>
> >    Call-ID: [email-masked]
> >    CSeq: 1 INVITE
> >    Contact: <sip:[email-masked];transport=tcp>
> >    Content-Type: application/sdp
> >    Content-Length: 143
> >
> > unless someone has better arguments in favor of lr usage, i suggest 
> > that
> > initial requests with outbound proxy are changed from lr to 
> strict.  at
> > minimum the issue should be mentioned in the text, because the rfc
> > doesn't say anything about it and guidance would thus be needed.
> >
> > -- juha
> >
> >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Fri, 13 Dec 2002 08:23:14 +0200

Hearty, John writes:

   > I'm a little troubled by this example.  Does User A know through
  configuration that Proxy 1 is an RFC3261 compliant proxy, and thus is OK
  with getting a Route header with itself at the top of the list for this
  initial request?  Otherwise, if Proxy 1 was an RFC2543 compliant proxy,
  it would not expect to see itself in the top Route header, and might do
  the dumb thing, popping the Route, putting it in the req uri and sending
  an Invite to itself then detecting a loop.  Alternately if it was an
  RFC2543 proxy and followed this text in section 6.29 it might just kill
  the call then and there:

yes, and i didn't start this discussion just for fun, since we have
encountered exactly the above proxy behaviors when we made kphone 3261
compliant.  our solution was to add a command line parameter -s to
kphone, which causes it to use strict preloaded route with old proxies.

-- juha

---

From: Alan Johnston <[email-masked]>
Date: Fri, 13 Dec 2002 11:17:18 -0600

OK - I see the problem.

A default outbound proxy (which is what we are talking about) is always 
provisioned in a UA, although it could be learned through DHCP.  A UA 
should never need to know if it its default outbound proxy is a strict or 
loose router before sending an INVITE.

Right now, this is configured by proxy address (literal or hostname) and 
port number.  A better way to do this in the future is to provision a 
preloaded Route header which just contains a URI - this URI is set by the 
owner of the proxy.

If a UA is taking configuration information of proxy address and port 
number and constructing a lr Route header - this is bad mistake and will 
cause the interoperability failures described.  If a UA is provisioned with 
a preloaded Route header, it just puts that in the request - the lr 
parameter should already be there.  These two configuration methods should 
never be mixed.

Thanks,
Alan.

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 13 Dec 2002 12:12:40 -0800

On Friday, December 13, 2002, at 09:17 AM, Alan Johnston wrote:

> OK - I see the problem.
>
> A default outbound proxy (which is what we are talking about) is 
> always provisioned in a UA, although it could be learned through DHCP.

yes

> A UA should never need to know if it its default outbound proxy is a 
> strict or loose router before sending an INVITE.

I disagree.  This is in-fact very useful.  If I am a deaf user and want 
to invoke a transcoder using a loose source-route, I need to know if my 
outbound proxy supports loose routes too.

> Right now, this is configured by proxy address (literal or hostname) 
> and port number.  A better way to do this in the future is to 
> provision a preloaded Route header which just contains a URI - this 
> URI is set by the owner of the proxy.

yes, we should be provisioning URIs, not hostnames.

> number and constructing a lr Route header - this is bad mistake and 
> will cause the interoperability failures described.  If a UA is 
> provisioned with a preloaded Route header, it just puts that in the 
> request - the lr parameter should already be there.  These two 
> configuration methods should never be mixed.

well, we shouldn't prohibit a UA from trying to discover if a hostname 
it obtained is a loose routing SIP proxy. I can easily do loose-route 
discovery with a single request.

OPTIONS sip:[email-masked] SIP/2.0
Via: SIP/2.0/TCP 10.1.1.1:5060;rport
Route: <sip:outbound-proxy.example.com;lr>
To: <sip:[email-masked]>
From: <sip:[email-masked]>;tag=038237
Call-ID: 8748djjh2hi9iv92
CSeq: 1 OPTIONS
Max-Forwards: 70
Content-Length: 0

thanks,
-rohan