Service-route overriding proxy
I don't think so. Because th P-CSCF address will be mostly assigned by
DHCP Option. Because when you're are moving with your device, you move
from one area to another one covered by annother GGSN, which mean you'll
have to contact a new P-CSCF, this without invalidating your registration.
The Registrar (S-CSCF) know where to send back the requests only because
it is listed in the Route/Record-Route from every request. So the P-CSCF
Address is not asserted in the Service-Route in the 200 OK following a
successful registration.
Olivier B.
Benny Prijono a écrit :
Roland Klabunde wrote:
Hi Benny,
Hmm. Not sure. My montiorings:
- No specification of service-route in config
- Register OK, server returns service route pointing to scscf:6060
- Invite is blocked by the registrar with error "Bad request - not following
indicated service route". The request has been sent to pcscf:5060
- Specification of service-route in config
- Register as above
- Invite is now sent to scscf:6060 (as specified in service route). This
ends up in no response.
Shouldn't the Ua send the Invite to pcscf:5060, providing the received
service route somewhere in the INVITE header in order to let the pcscf know,
where to route the request?
Frankly I'm not sure. I thought that if PCSCF wants to stay in the
path of subsequent requests, it should have been added in the S-R
list by the registrar. That's what I concluded from (briefly)
looking at the examples in RFC 3608. Or is this a wrong interpretation?
-benny
As far as I can remember there was no ;lr in the service route. What would
that change (besides the fact that I can't control the IMS platform)?
Regards
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
--
Olivier Beytrison
Telecommunication Engineer
Mobile: +41 (0)78 619 73 53
Mail: olivier@heliosnet.org
GPG: 0x4FB83528 http://pgp.mit.edu/
Frankly I'm not sure. I thought that if PCSCF wants to stay in the
path of subsequent requests, it should have been added in the S-R
list by the registrar. That's what I concluded from (briefly)
looking at the examples in RFC 3608. Or is this a wrong interpretation?
Damn'd there is a very good IMS bible, in there a chapter, which in details
explains the Service-Route handling... Martin, my colleague, came over this
afternoon and showed me the passage... Unfortunately I let him pass with the
book :)
I'll try to get the book again.
Kind regards to all
Olivier Beytrison wrote:
I don't think so. Because th P-CSCF address will be mostly assigned by
DHCP Option. Because when you're are moving with your device, you move
from one area to another one covered by annother GGSN, which mean you'll
have to contact a new P-CSCF, this without invalidating your registration.
If P-CSCF is assigned by DHCP, then how can you support multiple IMS
accounts then? Will you have multiple (DHCP) interfaces?
One of the use case of --outbound config is exactly for this
purpose, to specify local proxy that is discovered by DHCP. Since
DHCP normally applies for the whole "machine", then it affects the
route set of all accounts on the machine. So I thought you can use
--outbound to specify your P-CSCF.
The Registrar (S-CSCF) know where to send back the requests only because
it is listed in the Route/Record-Route from every request. So the P-CSCF
Address is not asserted in the Service-Route in the 200 OK following a
successful registration.
I still don't quite understand how S-CSCF is able to find the new
location of the client if the client moves to a new address without
doing re-registration.
-benny
Olivier B.
RFC 3608:
Simply put, the registrar generates a service route for the
registering UA and returns it in the response to each successful
REGISTER request. This service route has the form of a Route header
field that the registering UA may use to send requests through the
service proxy selected by the registrar. The UA would use this route
by inserting it as a preloaded Route header field in requests
originated by the UA intended for routing through the service proxy
Does that clarify the things?
Regards
----- Original Message -----
From: "Benny Prijono" bennylp@pjsip.org
To: "pjsip embedded/DSP SIP discussion" pjsip@lists.pjsip.org
Sent: Tuesday, October 30, 2007 6:16 PM
Subject: Re: [pjsip] Service-route overriding proxy
Roland Klabunde wrote:
Hi Benny,
Hmm. Not sure. My montiorings:
- No specification of service-route in config
- Register OK, server returns service route pointing to scscf:6060
- Invite is blocked by the registrar with error "Bad request - not
following
indicated service route". The request has been sent to pcscf:5060
- Specification of service-route in config
- Register as above
- Invite is now sent to scscf:6060 (as specified in service route). This
ends up in no response.
Shouldn't the Ua send the Invite to pcscf:5060, providing the received
service route somewhere in the INVITE header in order to let the pcscf
know,
where to route the request?
Frankly I'm not sure. I thought that if PCSCF wants to stay in the
path of subsequent requests, it should have been added in the S-R
list by the registrar. That's what I concluded from (briefly)
looking at the examples in RFC 3608. Or is this a wrong interpretation?
-benny
As far as I can remember there was no ;lr in the service route. What
would
that change (besides the fact that I can't control the IMS platform)?
Regards
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Olivier Beytrison schrieb:
I don't think so. Because th P-CSCF address will be mostly assigned by
DHCP Option. Because when you're are moving with your device, you move
from one area to another one covered by annother GGSN, which mean you'll
have to contact a new P-CSCF, this without invalidating your registration.
The Registrar (S-CSCF) know where to send back the requests only because
it is listed in the Route/Record-Route from every request. So the P-CSCF
Address is not asserted in the Service-Route in the 200 OK following a
successful registration.
In the 3G book from Gonzalo Camarillo, the Service Route only includes
the S-CSCF (no P and no I).
Nevertheless I think Benny is right: without reREGISTRATION after
changing the P-CSCF the client can not receive incoming calls (still
routed to old P-CSCF using the old path).
klaus
Klaus Darilion wrote:
Olivier Beytrison schrieb:
I don't think so. Because th P-CSCF address will be mostly assigned by
DHCP Option. Because when you're are moving with your device, you move
from one area to another one covered by annother GGSN, which mean you'll
have to contact a new P-CSCF, this without invalidating your registration.
In the 3G book from Gonzalo Camarillo, the Service Route only includes
the S-CSCF (no P and no I).
Thanks for joining the discussion, Klaus. I think I must have
misunderstood RFC 3608 Section 6.1, which I thought says that the
Service-Route headers replace the whole route set configured in the UA.
So as a confirmation, is it correct to append Service-Route headers
into existing route set?
-benny
Nevertheless I think Benny is right: without reREGISTRATION after
changing the P-CSCF the client can not receive incoming calls (still
routed to old P-CSCF using the old path).
klaus
let me quote the book "The IMS IP Multimedia Concepts and Services" from
Wiley
Page 180 reguarding the 200 OK returned from a successful Registration
""
The UE, when receiving the 200 (OK) response, will store the entries in
the Service-Route header. Whenever the UE sends out any initial
requestion other than a REGISTER message, it will :
- include the addresses that were received in the Service-Route header
within a Route header of the initial requests; and - include the P-CSCF address as the topmost Route entry in the initial
request.
""
should clear your doubts :)
Regards,
Olivier
Benny Prijono a écrit :
Klaus Darilion wrote:
Olivier Beytrison schrieb:
I don't think so. Because th P-CSCF address will be mostly assigned by
DHCP Option. Because when you're are moving with your device, you move
from one area to another one covered by annother GGSN, which mean you'll
have to contact a new P-CSCF, this without invalidating your registration.
In the 3G book from Gonzalo Camarillo, the Service Route only includes
the S-CSCF (no P and no I).
Thanks for joining the discussion, Klaus. I think I must have
misunderstood RFC 3608 Section 6.1, which I thought says that the
Service-Route headers replace the whole route set configured in the UA.
So as a confirmation, is it correct to append Service-Route headers
into existing route set?
-benny
Nevertheless I think Benny is right: without reREGISTRATION after
changing the P-CSCF the client can not receive incoming calls (still
routed to old P-CSCF using the old path).
klaus
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
--
Olivier Beytrison
Telecommunication Engineer
Mobile: +41 (0)78 619 73 53
Mail: olivier@heliosnet.org
GPG: 0x4FB83528 http://pgp.mit.edu/
Okay, thanks for the info.
So is appending Service-Route to existing/preconfigured route set
the best approach? Any potential pitfalls with this? (I can't think
of any).
-benny
Olivier Beytrison wrote:
let me quote the book "The IMS IP Multimedia Concepts and Services" from
Wiley
Page 180 reguarding the 200 OK returned from a successful Registration
""
The UE, when receiving the 200 (OK) response, will store the entries in
the Service-Route header. Whenever the UE sends out any initial
requestion other than a REGISTER message, it will :
- include the addresses that were received in the Service-Route header
within a Route header of the initial requests; and - include the P-CSCF address as the topmost Route entry in the initial
request.
""
should clear your doubts :)
Regards,
Olivier
Benny Prijono a écrit :
Klaus Darilion wrote:
Olivier Beytrison schrieb:
I don't think so. Because th P-CSCF address will be mostly assigned by
DHCP Option. Because when you're are moving with your device, you move
from one area to another one covered by annother GGSN, which mean you'll
have to contact a new P-CSCF, this without invalidating your registration.
In the 3G book from Gonzalo Camarillo, the Service Route only includes
the S-CSCF (no P and no I).
Thanks for joining the discussion, Klaus. I think I must have
misunderstood RFC 3608 Section 6.1, which I thought says that the
Service-Route headers replace the whole route set configured in the UA.
So as a confirmation, is it correct to append Service-Route headers
into existing route set?
-benny
Nevertheless I think Benny is right: without reREGISTRATION after
changing the P-CSCF the client can not receive incoming calls (still
routed to old P-CSCF using the old path).
klaus
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
--
Benny Prijono
http://www.pjsip.org
After having discussed this point with some people deeply implied into
the IMS Development, they definitely think that's the way an UA should
handle the Service-Route.
As for myself, I don't see any caveat to this (I would rather see a lot
of advantages :))
I'm looking forward to the upcoming revisions
Regards,
Olivier B.
Benny Prijono a écrit :
Okay, thanks for the info.
So is appending Service-Route to existing/preconfigured route set
the best approach? Any potential pitfalls with this? (I can't think
of any).
-benny
Olivier Beytrison wrote:
let me quote the book "The IMS IP Multimedia Concepts and Services" from
Wiley
Page 180 reguarding the 200 OK returned from a successful Registration
""
The UE, when receiving the 200 (OK) response, will store the entries in
the Service-Route header. Whenever the UE sends out any initial
requestion other than a REGISTER message, it will :
- include the addresses that were received in the Service-Route header
within a Route header of the initial requests; and - include the P-CSCF address as the topmost Route entry in the initial
request.
""
should clear your doubts :)
Regards,
Olivier
Benny Prijono a écrit :
Klaus Darilion wrote:
Olivier Beytrison schrieb:
I don't think so. Because th P-CSCF address will be mostly assigned by
DHCP Option. Because when you're are moving with your device, you move
from one area to another one covered by annother GGSN, which mean you'll
have to contact a new P-CSCF, this without invalidating your registration.
In the 3G book from Gonzalo Camarillo, the Service Route only includes
the S-CSCF (no P and no I).
Thanks for joining the discussion, Klaus. I think I must have
misunderstood RFC 3608 Section 6.1, which I thought says that the
Service-Route headers replace the whole route set configured in the UA.
So as a confirmation, is it correct to append Service-Route headers
into existing route set?
-benny
Nevertheless I think Benny is right: without reREGISTRATION after
changing the P-CSCF the client can not receive incoming calls (still
routed to old P-CSCF using the old path).
klaus
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
--
Olivier Beytrison
Telecommunication Engineer
Mobile: +41 (0)78 619 73 53
Mail: olivier@heliosnet.org
GPG: 0x4FB83528 http://pgp.mit.edu/
Benny Prijono schrieb:
Klaus Darilion wrote:
Olivier Beytrison schrieb:
I don't think so. Because th P-CSCF address will be mostly assigned by
DHCP Option. Because when you're are moving with your device, you move
from one area to another one covered by annother GGSN, which mean you'll
have to contact a new P-CSCF, this without invalidating your registration.
In the 3G book from Gonzalo Camarillo, the Service Route only includes
the S-CSCF (no P and no I).
Thanks for joining the discussion, Klaus. I think I must have
misunderstood RFC 3608 Section 6.1, which I thought says that the
Service-Route headers replace the whole route set configured in the UA.
So as a confirmation, is it correct to append Service-Route headers
into existing route set?
not sure - depends on how the existing route set is retrieved. Of course
it makes sense to always add a local defined outboundproxy (which maybe
for example a SIP-firewall in an enterprise or the PCSCF in IMS).
Maybe it would be useful to allow the --outboundproxy not only per UA
but also per SIP AoR.
regards
klaus
-benny
Nevertheless I think Benny is right: without reREGISTRATION after
changing the P-CSCF the client can not receive incoming calls (still
routed to old P-CSCF using the old path).
klaus
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org