This
isa repost. Sorry about the typo in the Subject line.
Folks,
I wonder if the definitions of Spiral and Loop needs to be updated.
I am speaking within the context of using SIP in the 3G/UMTS architecture:
S-CSCF or Serving call session control function is essentially a SIP proxy + more.
A S-CSCF , can send an initial INVITE to a SIP application server (AS) for application
processing. This can be done by loose-routing the request by including
a set of one more route headers to the initial INVITE.
If the AS is working as a proxy, it can manipulate the INVITE and send it
right back to the S-CSCF. If the AS happened to be a loose router, it will
not hammer the R-URI of the INVITE and instead will follow the route set as
it sees it.
The INVITE that comes back to the S-CSCF must not be thought of as being in
a loop. It's route-set and Via headers, will be different and so the S-CSCF can
distinguish it from the initially received INVITE. It will also fail the loop detection
test as defined in section 16.6, step 8, 3rd paragraph (since the test includes
hashing on the top-most Via).
imho, an INVITE arriving at an proxy more than once has to fall into
one of two buckets: Loop or Spiral. Currently I see the gap between the
two caused due to R-URI being the same because of loose routing.
What does the cognoscenti think of this? Should not the definitions of 'loop'
and 'Spiral' be updated in Section 6?
Thanks,
Ganesh
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Folks,
I wonder if the definitions of Spiral and Loop needs to be updated.
I am speaking within the context of using SIP in the 3G/UMTS architecture:
S-CSCF or Serving call session control function is essentially a SIP proxy + more.
A S-CSCF , can send an initial INVITE to a SIP application server (AS) for application
processing. This can be done by loose-routing the request by including
a set of one more route headers to the initial INVITE.
If the AS is working as a proxy, it can manipulate the INVITE and send it
right back to the S-CSCF. If the AS happened to be a loose router, it will
not hammer the R-URI of the INVITE and instead will follow the route set as
it sees it.
The INVITE that comes back to the S-CSCF must not be thought of as being in
a loop. It's route-set and Via headers, will be different and so the S-CSCF can
distinguish it from the initially received INVITE. It will also fail the loop detection
test as defined in section 16.6, step 8, 3rd paragraph (since the test includes
hashing on the top-most Via).
imho, an INVITE arriving at an proxy more than once has to fall into
one of two buckets: Loop or Spiral. Currently I see the gap between the
two caused due to R-URI being the same because of loose routing.
What does the cognoscenti think of this? Should not the definitions of 'loop'
and 'Spiral' be updated in Section 6?
Thanks,
Ganesh
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
